I think DevOps and some of the assorted terminology appeared as a blip on my personal radar around 2010 stumbling upon Heroku in University of Helsinki Computer Science classes as I was exploring my own personal midlife crisis as a student alongside work- and family life. I was familiar with a lot of the concepts like version control, package repositories and build systems, but a deployment from build straight into cloud-based app service was still a wondrous thing.

On the work-front, I had already switched to Microsoft-ecosystem and getting familiar with Team Foundation Server and what was then (and still is) lovingly as change management. Things changed around 2014 after Microsoft had acquired InCycles Release Management and shipped it as an extension to TFS, as my colleague returned wide-eyed from Techdays and we installed the said extension next day. I definitely remember that pivotal lightbulb- moment happening in early 2015 when writing a seminar paper on “Continuous Experimentation in Microsoft Ecosystem”, as things really clicked. Some of the material I read is still very relevant, like Continuous Delivery by Humble and Farley and Climbing the “Stairway to Heaven” (by Olsson, Alahyari, and Bosch), which still quite accurately describes the stages that a more traditional software development company might go through.

Even after dabbling with Heroku and it’s promise of glorious future, I did my day work the hard way in traditional environments, where one usually should stick to talking about release automation rather than DevOps or even Continuous Deployment. At least in Public Sector domain where I worked, change management still rules the day (or week, or however long you’ll wait for those tickets to go through). Still, we did evolve alongside TFS and ended up with finally building pipelines that deployed the gazillion software packages we produced all the way to production with Azure DevOps Server 2019. Even now, over two years since going into production, I’m kind of proud of the glorious, mad deployment environment we created.

Having said that, I’d been fairly sure for several years that my personal end-of-the-road for on-premises environments was long overdue. We waited for the yaml-pipelines and artifact filters for release defintions for a few years more than the cloud-based colleagues, and when we had them, others were already experimenting with multi-staged pipelines. My own pet peeve was reserved for the lack of programmatically creating infrastructure. While there were plenty of technical solutions available, from PowerShell DSC through Ansible to other tools and container-based solutions (yes, I’m looking at your shiny kube-cluster and the lonely wizard operating it), the investment to actually take them into use in more security elevated environment wasn’t really an option.

So, as the new decade loomed in future, I started to look for some new opportunities, and looked them from near and far. From non-technical -perspective, there are many factors when choosing your next place of work, but from my rather focused DevOps- and Infrastructure as Code -point-of-view, I narrowed them down to three:

1. I wanted to focus on Azure.
2. I wanted to focus on (Azure) DevOps.
3. I wanted an environment in which the environments and pipelines are owned by the development team.

The first two are personal choices and having done Azure DevOps -certification (and living in the Microsoft la-la-land for the past 10 years), they were quite easy for me to make. But the third one might require more explaining: the thing that finally made me choose smaller and more agile (not in the process-sense as such, but guess that comes in the same package) environment was that with the larger enterprises and their customers, there is still that feeling of ITSM that looms over everything.

Now, having done my time in the change management department, I’m all in for things like traceability, but what really puts me off is the notion that some Application Management team somewhere owns production environments and has outsourced the technical know-how if infra and pipelines to some center of excellence or another. I’m sure a working setup for this exists somewhere and that some systems even require such, but most of the time, it ends up with slow ticket-punching and hunt for the extraordinary unicorn who knows both yaml and json.

I can certainly see how one can read Microsoft’s Cloud Adoption Framework and come out thinking that it’s a good idea to have a centralized control of cloud environments. If you have lived and breathed ITSM and ITIL for decades, it takes some and then some un-learning to understand the motivations behind insert your favourite devopsy buzzword here. For someone used to have all the control, it’s hard to learn to have just the right amount of control.

And so, in Fall of 2020, after lenghty consideration, I landed on my current job with a leap of faith and hopes that all those boxes were ticked. So far, so good.