I’ve witnessed the inception of the DevOps movement. The “Phoenix Project” was our bedside book. It was early 2010 and we talked about lean management, work in progress, and of course tooling.
Fast-forward more than a decade, and many things have changed. While lean management, work in progress (WIP), and other concepts still exist, the one constant survivor is tooling—lots of it. But is DevOps dead? That remains an open question.

One thing I am certain of tooling alone cannot address all the questions that DevOps raised at its inception.

Let’s delve into Infrastructure as Code (IaC), an essential element in the DevOps tool. It lets you define your cloud infrastructure in a declarative way, using simple scripts. You end up with a unique source of truth, stored most of the time in a source control system. This way you can deploy your application infrastructure automatically, manage updates; add or remove resources, and redeploy to recover your application if someone accidentally deleted something.

You can use Terraform to support multiple Cloud providers, ARM template or Bicep in Azure, Cloud formation in AWS, and so many others. A simple code editor is enough to start working with these tools, while a good code editor will be more useful. It can help to speed up your application as you can code with Infrastructure as Code any requirements needed for your application. Your application needs a cache service now, add it to the code for your cloud deployment. If you want to scale out the application, just add an extra VM to the code.
So, what happens? Complex to say but there are two major elements to take into consideration. The first one is Cloud computing is more and more complex, and the infrastructure required for modern-day applications is much larger than before. Think about Kubernetes, you will need to deploy your AKS in the cloud, but you will need to manage the security access, and connection to databases, registry, network, and many other resources. Compared to ten years ago, when the same kind of application only required a bunch of VMs. So, the Infrastructure as code becomes more and more complex, and difficult to write and maintain. You need to be skilled in Terraform, Bicep, or Cloud Formation to achieve the promise of a full declarative solution.

At the same time, and it is the second element, the pool of experts in cloud and infrastructure as code does not scale out as it was needed. Developer teams prefer to focus on their code and not learn a new language. As few IaC experts are available, the situation is inextricable. There is the idea of a DevOps expert to help developer teams with this kind of work. But is it the solution? Teams will have to wait for these experts to be available, present what they need, wait for the solution, and if there is a change they need to wait again. It is an anti-DevOps pattern, where works stay in progress.

What can be the solution? There are a few possibilities. The first one is modularity. When each team in a company uses Infrastructure as Code on their own, you end up with a limitless number of standards to deploy the same things. Imagine, if there are twelve teams with several projects using Azure Kubernetes Service, not only they will reinvent the wheel every time, but each project will have a different implementation. And it’s not only about services like AKS, it includes, basic services like VNET to the most complex ones.

The key is modularity. If a team needs to deploy a resource, they must find the corresponding piece of IaC code in a trusted location. This code is maintained by a special team, managing updates and following best practices.

Bicep lets you create modules and share from a central location, using Azure Container Registry or Template Spec. The team only needs to reference access to these locations and use the modules.
Recently, Microsoft went a step further in modularity for Infrastructure as Code, they took the initiative to launch Azure Verified Modules. It is an official initiative supported by Microsoft and you can use it using Bicep and Terraform.

But before discussing modularity, we may need to talk about what is provided to developer teams. In the cloud, there is the concept of a Landing Zone. To be short is a pre-configured AWS account or Azure subscription where teams should find everything, they need to deploy their workloads.

But to be effective a Landing Zone must include many things, connectivity, governance, and essential tools to deploy their workloads. In my past years as a Consultant, I rarely saw a well-designed Landing Zone, and sometimes no landing zone at all. Most of the time the Landing Zone is the other expression for connectivity. We need to review the concept of Landing Zones and deliver, using Infrastructure as Code, a properly defined Landing Zone giving strong guardrails. This way you can accelerate developers' experience using Infrastructure as Code as Code.

Infrastructure as Code is still a great tool when it comes to deploying resources to a Cloud provider. But two forces work against it, the growing complexity of infrastructure and the scarcity of skilled people to create and maintain the code needed for this infrastructure. Solutions exist but it is clear that the DevOps concept is out of breath. Maybe it is time to explore new concepts like Platform engineering,