Doing (Dev)Ops in Azure

In our game, the game of IT industry, we have three kinds of players — Developers, Ops engineers and everyone else, also called overhead. Or that’s what we took for granted before it turned out that now we’re all DevOps engineers. It almost feels as if someone came and said to us that by rebranding the positions or job roles we’re going to fix all the problems which we’ve been trying to solve for decades — “Just do DevOps (and Kubernetes), and it’ll all be fine”.

That is, of course, a humoristic exaggeration, but if you follow the trends in the industry, I think you’ll understand the feeling. A glance at LinkedIn will show you that almost every organisation out there is trying to recruit “DevOps Engineers”. Even at Schuberg Philis, our careers page shows a couple of open positions for such a position. But how does one become a DevOps engineer? Is that even possible? After all, DevOps is a culture, a way of working, not a profile. Looking at what is happening in IT, I would dare say that a DevOps engineer is the equivalent of Ops 2.0.

I consider myself an Ops guy. I started my career in IT with a Cisco CCNA course and used that as a foundation to become your typical WinTel specialist. I deployed countless Windows boxes and went trough numerous software installations. All by hand. Sometimes I had a manual, other time I was the one who had to create the manual. But over the years I developed a bit of hatred for manuals — even the ones which I considered complete somehow created snowflake systems. So I started scripting what I would have otherwise documented, and when a more in-depth explanation was needed, I used comments. I then put the script in source control and maybe even created a CI/CD pipeline. Look at me. I’ was becoming a developer! Well, no, I wasn’t. But I started to understand developers and the way they work much better. I’ve also learned a great deal from them.

It also works the other way. Concepts like Infrastructure-as-Code allow developers to create their own VMs or even entire environments, as opposed to being only able to create Jira tickets a few years ago. As a result, they have a better understanding of all those things that we Ops always rage about. Maybe they even grow a little appreciation for how we’re always focused on security.

The commoditisation of the Public Cloud enforces this phenomenon even further — it makes it easier to script everything for some of us, and allows others to experience the joy of deploying and managing infrastructure.

But as much as DevOps brings us closer, we‘re still Ops engineers and software engineers, each with a distinctive and hugely valuable perspective. We are, and I hope that we will remain different. After all, two different perspectives combined have a bigger chance of creating a quality outcome. We do have to, however, remain mindful of the differences, and focus on the most critical thing in our work — communication.

In my daily job, I’m privileged to work with customers of many different sizes and with varying levels of maturity when it comes to their DevOps culture. That exposure to sometimes opposing approaches is what made me reflect upon the advise we today give our customers when they embark on their journey to adopt Azure.

To me, a very tangible manifestation of the issues we face while going through the DevOps transformation is the Dev environment, or how differently we can look at it.

For some organisations, the Dev environment, along with all other parts of the DTA street is, in fact, a part of the production stack. DTA stands for Dev, Test, Acceptance and is sometimes also referred to as non-productive environments. But try breaking any of them and see how many angry developers or testers come running at you. You’ll soon find out how productive DTA is. We then say that DTAP is a staging model for the entire Prod environment. In such cases, the Ops team might have a dedicated Sandbox environment where they can work on infrastructure-level changes without impacting the developers’ ability to perform their tasks.

On the other side of the spectrum, we have organisations which use the Dev environment to introduce changes both on the infrastructure and the application level. Once in a while, things do break, but those teams accept this risk. If they are mature in the adoption of what we call DevOps practices, then the Mean-Time-To-Recover (MTTR) is acceptably low, so both Ops and Dev use the same set of environments to implemented changes.

Depending on where your organisation is in the journey, something similar to one of the two models which I describe above is probably very natural for you. But I’ve found myself reminded recently how big of an impact this topic has on how we design our cloud environments. When you start thinking of network isolation, the principal of least privilege or a management hierarchy for your cloud deployment, the way you use different environments matters a lot. It will, for example, impact the number of hubs you deploy in a hub-spoke topology, or how you define and assign Azure Policies.

So with that in mind, I wanted to share a few tips, which will hopefully save you some trouble:

Make sure that your teams are aligned on how different environments of your Azure landscape will be used.

Understanding what a team needs to be productive and aligning on how different team members want to work with Azure is the first step to creating a robust design.

There are multiple ways of setting up your Azure environment right.

And even more ways of doing it wrong. There isn’t, however, a single one that can be viewed as a silver bullet. The best one is the one which works best for your team(s) at a given time.

Your teams will change over time and so will the way you work with Azure have to.

Do not oppose the change. Embrace it. Set your environment up for flexibility so you can adapt quickly. Experiment, analyse, then persevere or pivot. Repeat.

Design your Azure environment in a way which gives your teams the autonomy to experiment.

High performance is achieved, among other factors, by giving teams the possibility to experiment and test new ideas independently. Azure is the perfect place for short-lived Proof-of-Concept deployments.

Set up guard rails which will protect teams from compromising security and compliance.

Use the fantastic tools which we have at our disposal, such as Azure Policy, to provide baseline security and compliance configuration at a scale.

Automate as much as possible.

So that you retain visibility and stay in control of the cloud landscape, especially when it comes to cost.

You might now want to say “Thanks for the tips, but how do we implement those recommendations in a structured manner?”. My answer to your question would be that you can achieve all of this by having a cloud landing zone. But going into the details of that exercise is a separate story for a different day.