About
Whoami
I’m an automation dude and IT professional with more than 20 years experience. theAutomationDude sounds kewl and all, but my real name is Peter Östman and I live south of Stockholm - Sweden.
I got a background in traditional IT Infrastructure, architecture and security. The latter part of my career has centered around automation, cloud and devops.
Follow me on LinkedIn
The Blog
In this blog I’ll share my thoughs related to just about anything cloud, code, devops and IT in general, basically anything that comes to mind. And I’ll also share experiences, how-to guides and other good learning stuff depending on what I work with at the moment (and may still be learning myself) or have worked with in the past. I consider this profession to be a long learning journey that will never end, so feel free to contact me if you think there are better ways to do the stuff.
My Story
My IT career started off as part of my studies in Network technology, right before the millenium shift with a work placement as an onsite IT support role in a multi-national company. Worked with everything from workstation management, printers to Windows and Novell Netware servers, Network equipment and even some stuff with mainframe and AS400.
Actually you could say my career started long before that, at the age of 8 with my Commodore 64 and basic programming. A few years later the family got our first PC, I learned how to write batch-files and customized a lot in DOS. More years (and computers) went by and we got ourselves a modem, to start with I was the only user, connecting to BBS - Bulleting Board Systems, most people don’t know what that is today. Soon Internet entered the stage Sweden, and the online adventure began. DSL connections was introduced, and I built my own Gateway / Firewall / FTP server, running Redhat Linux, out of a 486 computer and some Network adapter cards I had laying around, my first home network was built.
My second job was a second work placement in my final year of studying, at a small company, working with Windows and Linux servers and workstations. That job eventually turned into a software development job, I was asked to code a new version of a number plan system for a telecom provider in Oracle Power Objects (a flavour of Visual Basic). It was a pretty hard job for an unexperience developer (who was more of a network administrator at the time). I remember how I started dreaming code after some late night coding sessions, and that detered me from pursuing a software developer career path over network and server administration. This is ironic since I love coding over that other stuff nowadays.
After my studies I was hired as a full time engineer and a couple of years later I was transfered to IBM as part of a large outsourcing deal. From there my career accelerated from onsite support to server and active directory administration, becoming the teams cluster guru and scripting guy. I tried out some project manager, solution manager and solution architect roles. I decided that line of work wasn’t my biggest interrest and pursued on the infrastructure architect path for some of years, working exclusively with enterprise customers, a changed roles a couple of times and got more into enterprise architecture, governance and coaching solution architects.
Life made big turn, wife, first kid and did my first paternity leave. I had time to reflect on where my career was going, after 9 years at IBM I felt it was time for something else. My professional passion has always been designing and building smart and useful solutions, combining theory and technical hands-on. Doing governance and politics made me feel disconnected from technology. I signed up for a new job and quit my old one.
The new job was as server administrator in a strong security posture environment. I dusted off my scripting skills again - it had always served me well before. People told me to try out Powershell, since VBScript was getting out of fashion. I started making a few scripts for security purposes, at that time I had not yet understand how to work with objects in powershell so much was being done the old-fashioned way, parsing, string operations etc. I produced scripts for server management, Active Directory, tools for the service desk, and my Powershell skills got better. Soon every task we had to solve was turned into some sort of Powershell script exercise. Powershell proved to be a stron ally when working with a lot of security and all the hassle that meant. I learned some new stuff in the IT security and ethical hacking space, but felt that the automation and coding was more interresting. Until this point I had not ever heard of DevOps, I was leaning towards changing into a developer career instead, but when I first heard of Devops (actually I didn’t realise that it wasn’t meant to be a role at first) I realised that that probably was the best option for me. I realised that I already had bits and pieces like scripting, automation, configuration management and version control, I just had to add cloud, developer practices and some other stuff to be on my way.
We had moved to larger house farther away from my work, had two more kids (twins) and to avoid traffic I commuted early in the mornings while the rest of the family was sleeping. It was a good time to pursue that loosely defined DevOps career, and I felt a strong need to get up to speed on the cloud journey happening outside.
I signed up for a new job as a senior engineer on a Windows Server team, leveraging my Powershell skills and hoping to get a foot into the clouds. I was meant to take lead on the webserver platform, when my “fluency” in Powershell was revealed, I was reassigne to take over runbook authoring and automation with SMA. I spent the next two years writing runbooks, consuming API’s, providing internal Powershell training, introducing the team to Git and TFS/Azure DevOps, built some demos for Powershell Unviversal, providing a front-end site for server automation in the on-premises datacenters and made some some API endpoints for the same use-cases. I also made some proof of concepts with Azure Automation instead of SMA, with on-prem hybrid workers and a CI/CD pipeline to sign and deploy the runbooks to Azure Automation. Automating in a large environment with technical debt and complex dependencies is a slow and cumbersome process, and doing all that stuff in a cloud was looking very attractive to me.
The work was still mainly about on-premises servers and I wanted to do all that stuff in the cloud, preferably Azure. I got news of a vacancy in the cloud adoption team, that I applied for and pretty quickly my request was granted. Before applying I didn’t even know if my role would be for AWS or Azure, I reasoned that any of the two would be a step in the right direction. It turned out the role would initially be about Azure and that’s where I am today. Hopefully I will be able to work across both clouds in the future.