This is the second part of my blog series Tales from the DevOps trenches. The first part “from on-premises to Azure Cloud” can be found here.

For someone interested in DevOps and Infrastructure-as-code, and possibly as anxious on whether you can handle the cloud monster as I was, here’s a word of encouragement: a server is still a server, network is a network, and working with certificates might in fact be a slightly smaller pain in the ass than they used to be (the jury is still out on what one, but hope lies eternal). That is to say, in essence, the cloud is just a data center that someone else operates and your control over things is an illusion built upon automation that some very smart people have done. It’s such a good illusion, in most cases, it works like a real thing, so I guess we can just call it magic that’s operated (mostly and in the case of Azure) with code instead of ritual sacrifices.

In other words, a lot of the knowledge you have around traditional on-premises environments is either usable as-is or at least gives you a good head-start on understanding how things work. Take the mentioned certificates; if you know how to operate the IIS and Windows server in a traditional environment and can set up certificates there, you’ll be in awe of how easy it is to do the same with Azure App Service. And when things go south as they tend to do, you’ll find out that problem-solving in the cloud is not that different from problem-solving in traditional environments – with experience you just know what to search terms a bit better than others. Fundamentals are still similar, if not exactly the same.

With this in mind, I found Azure’s Resource Manager and the ARM templates used with it rather easy to understand, though it did require more than one cycle of trying and failing to get to the point where I’m comfortable enough to use them. I’ve recently dabbled with Terraform and Bicep and find them easier to use after having done my time with ARM. For a programmer, it’s probably the other way around, and I’d suggest going straight to Bicep or Terraform (In that order because more souls for the mas… Microsoft). For DevOps- and Infra-guy, understanding ARM is quite valuable though.

If you are mostly a DevOps-guy and have dabbled with YAML-based pipelines in Azure DevOps, here’s something with which I struggled: I was accustomed to the build-once-deploy-many -paradigm that it was hard to wrap my head around the concept of just having a single pipeline or just how you orchestrate the stages YAML pipelines, as there really is no straight alternative for artifact filtering. You can create similar logic in YAML pipelines with conditionals, but the process lacks the clarity of the visual editor.

For the uninitiated, artifact filtering is the way you logically branch your release definition pipeline based on the version control (that is, git repo) branching, should you not have the luxury of going in a straight line from the main branch (see what I did there? It’s awesome to be progressive) to production. The end product is not really that different and you often end up doing release isolation and not really promoting the same build artifact through different environments. Sure, it’s pipeline artifacts instead of build artifacts and you consume the build pipeline as a resource in your YAML-based release pipeline, but apples, oranges, fruits.

I also had a hard time doing the environment-specific configuration in some other way than replacing tokens, having done so since 2015 (see: Release Management extension in the first part. I still feel all warm inside when someone tokenizes their ARM templates), which I suspect to be more fringe technique than I thought. The environment-specific configuration files and environment variables, at least in App Services, seems to rule the day, and work well enough.

What I’m honestly the most surprised about, though, is that with all this talk about DevOps and IaC, surprisingly few teams still end up being what the DevOps-guidebooks call T-shaped teams. While team members have different specific skill sets, everyone knows something about everything and is able to at least perform basic routines of, say, testing and deployment.

What still ends up happening is that there is a fleeting moment when a member of the League of Extraordinary Unicorns sweeps by and sets up your pipelines, infra, test automation, kanban board, and what-have-you, and is then gone like bat out of hell. I think we have it better than most, and we still have a long way to go to get rid of person-shaped bottlenecks. The logical continuation on that path is the dreaded out- and off-shored centers, which lie at the end of the path paved with resource management, cost-effectiveness, and control.

We’ve had that for the last 30+ years. Snap out of it, people.

Check out our DevOps offerings here.