English | EN 
In ancient times, Dev and Ops existed. Dev would write applications. Hand them over to Ops to deploy on the company servers, often managed by that same Ops. In some cases, Dev and Ops were working together on the same server*. Because application deployment instructions were not documented properly and time was running out.
Managers were forcing Ops into this coexistence. Ops reluctantly gave developers access. Admin access, because it would not work with anything less of course. Not all developers liked this kind of work. But at some point, an application had to move from ‘works on my machine’ into the realm of actual users.
I have fond memories of those times. It brought Dev and Ops closer together and usually was the beginning of a mutual understanding. Ops could see the application as more than ‘yet another package’. At the same time, Dev gained insight into the challenges of managing an application in various environments.
It taught me that an application is not ‘done’ until it can be installed. Via an automated, repeatable process. We must secure it, monitor it, and do everything needed in order to manage an application in operation.
*Depending on the maturity of the (IT) organization as a whole and the specific team(member)s in particular.
Cloud-native applications
Fast forward to here and now: today developers are creating many applications ‘cloud-native’.
Cloud-native architecture and technologies are an approach to designing, constructing, and operating workloads that are built in the cloud and take full advantage of the cloud computing model.
What is Cloud Native? | Microsoft Docs
While we certainly have other options than cloud-native for our applications (more on that in a later blog), let’s assume for now that we are building one. Perhaps a nice front-end supported by a clever backend and maybe a database. And like any application, our application needs infrastructure to run on. IaaS or PaaS. This is when Dev and Ops meet again.
Democratizing infrastructure
DevOps, Cloud. In many cases, people just mean cloud infrastructure and CI/CD, but it is so much more than that. DevOps is a mindset, and not a function. Modern teams incorporate this mindset, while still allowing people to do what they like. And what they are good at. Coding, pipelines, infrastructure, applications, the boundaries are blurring. And with cloud and cloud-native applications, Dev and Ops need to work together like never before.
Modern cloud environments are usually set up with what’s called a ‘landing zone’ and ‘workloads’ that run in it.
An Azure landing zone is the output of a multi-subscription Azure environment that accounts for scale, security governance, networking, and identity.
Microsoft, What is an Azure landing zone? – Cloud Adoption Framework | Microsoft Docs
Typically, the Ops team takes care of the landing zone and the infrastructure in it. But for workloads (applications), I recommend developers to take care of their own infrastructure. Requesting anything else than ‘traditional’ cloud infrastructure from Ops just does not make sense. Especially using PaaS services for applications makes developers also ‘do cloud’ now.
So, after Ops has delivered a landing zone (using something like Terraform), they set up the Infrastructure as Code pipelines for the workload as well. They add networking and any important shared infrastructure like Key Vaults, Log Analytics, and storage. After that, developers get Contributor permissions to the Dev environment. Or before that, if the landing zone is not ready yet 😉
Let’s get started!
Now in this environment (probably one or more Resource Groups in Azure):
- Create all the resources you need. Tip: Make sure you don’t apply the naming convention you agreed on.
- Develop your application using these resources. Since this is a cloud-native application, ‘take full advantage of the cloud computing model’.
- Configure your resources as needed.
- Find out if you need other resources. Like a Service Bus instead of a Storage Queue, or the other way around.
- Create these other resources, and change the application where needed. Tip: destroy anything not needed anymore, keep your environment clean and avoid unnecessary costs.
- Repeat steps 2 to 5 when needed.
Pro-Tip: If you really want to improve your game as a developer, I highly recommend learning something like Terraform (or Pulumi). Even if you run it from your dev machine straight against the cloud, it really helps understand the relations between resources and their required set up. It makes your life easier if destroying and re-creating of resources is part of your work. Never forget how to exactly reproduce your resources with the same configuration every time and do it fast!
At some point, you are satisfied with your setup. It is working nicely. Now kindly ask your cloud infra coworker to implement your resources into the IaC pipeline. They can copy/reverse engineer your resources (or use the infrastructure code you created for yourself) and apply the right naming. Also, make sure you discuss any permissions and security set up with them. Make sure your resources are safe and compliant.
Afterward, the pipeline can deploy to further environments. And you can replace your experimental resources with the provisioned ones.
It’s a DevOps world
This way of working combines maximum flexibility with the predictability of Infrastructure as Code. It reduces the impact of having to go back to your cloud infra coworker and ask for (minor) changes. I have been both a developer and a cloud infra engineer in the past years. I can confirm that for both roles it is quite convenient to work this way. Dev and Ops, happy together 🙂
ps. As a bonus, you can try to treat any virtual machines you need as part of your solution as containers, making them stateless and integrating them with Key Vault and Application Insights for example. Using Packer you can create images that can be used for your servers. Have Ops provide you with a properly prepared base image and start from there.
