Gartner predicts that through 2022, 75% of DevOps initiatives will fail to meet expectations due to issues around organizational learning and change.

But DevOps initiatives are important, because they enable critical capabilities to compete in the future. Without demolishing the figurative wall legacy IT built between development and operations, delivering the kind of digital experiences customers expect today will more likely fail than not.

So before we can get into how an infrastructure automation framework can help your DevOps initiative succeed, we first need to take a closer look at why so many fail.

Why do so many DevOps initiatives fail?

In the last two years at Container Solutions, I’ve worked with teams from steel to fintech and agriculture to telecommunications on various aspects of their cloud native transformations. Adopting DevOps is always a big part of that transformation. Probably the hardest thing for companies is to adapt their existing organizational structure to cross-functional DevOps teams.

Organizations need this change to happen, because digital experiences are already the new normal for a majority of consumers. This puts enormous pressure on the teams. The changes required are huge, especially from a legacy operations perspective. Almost everything changes. Team setup, workflow, responsibilities and tooling. And don’t forget it’s rarely on a green field. People in those initiatives are often asked to continue supporting the old while at the same time learning the new.

For individuals, change brings lots of uncertainty. People may not openly admit it — or worse, hide it behind outright hostility — but self-doubt is common and most certainly understandable. People wonder if they personally will be able to succeed in this new world and are afraid what this means for their careers.

And on top of the high pressure and the self-doubt, still overshadowed by the “them vs. us” mindset that legacy IT nurtured for years, people with a traditional IT-ops background are asked to work more like “them”.

Application teams and platform teams

First, getting the “them vs. us” out of the way is crucial. The way I like to think about this is, all teams are cross-functional DevOps-teams. Some just work at the application and some work at the platform layer.

But still, while application teams use Spring Boot or similar frameworks to move fast, platform teams have to build infrastructure and automation by integrating low level tooling from scratch.

This lack of tool chain maturity combined with the high pressure and need to learn new skills adds a very strong and counterproductive feeling to the mix. The feeling of being treated unfairly. It’s hard to not feel treated unfairly if you’re expected to move as fast as your application counterparts when at the same time having a dramatically less mature tool chain at your disposal.

It is as if one team is given a 3D printer to print a house and the other team is given a bunch of parts to first assemble the excavator before they can dig the hole for the foundation with it.

Application frameworks and platform frameworks?

In the past, the abstraction between applications and infrastructure was the operating system. But operating systems are a weak abstraction, which leads to application requirements leaking into the platform layer. This meant infrastructure configuration often did not have enough in common, even between application tiers, for reusable framework components to be feasible.

Containers did not improve the abstraction layer qualities of operating systems, but they still fixed this issue by allowing separate application and platform layer operating system instances.

Furthermore, Kubernetes sits right at the border of application and platform layer and provides a robust API for teams to have clear responsibilities and not interfere with each other.

This is huge. Powerful abstraction between the layers marks a paradigm-shift that — for the first time — allows platform teams to benefit from frameworks as well.

I believe that not only is now the time for such a framework but that it will also help more DevOps initiatives to succeed.

How can frameworks help your DevOps initiative succeed?

Frameworks are popular in application development, because they help teams move faster both when creating new applications and also when maintaining these applications.

Bringing the same benefit to the platform layer and removing the reason to feel unfairly treated by leveling the playing field with the application layer takes out the emotion and removes a big source of conflict.

But frameworks, based on reusable components, also allow teams to use these components without needing to fully understand their implementation. Allowing teams to make progress, even when the technology is new for them. The usage and common use-cases can be documented. This is a prime resource for teams to learn the new skills and knowledge they need to drive their company’s DevOps initiatives forward.

Last but not least, frameworks foster a user community of people working on the same challenges and available to help each other. Be it through sharing experience through blog posts and conference talks, writing guides and tutorials or being available as consultants.

Frameworks have the potential to help your DevOps initiative succeed, because they help solve two of the biggest reasons for failure.

First, the feeling of unfairness from needing to perform like the application counterpart while having a dramatically less mature tool chain at your disposal.

And second, the uncertainty whether you will be able to succeed personally. Having access to a framework gives people the trust and confidence to move forward and learn along the way.

Luckily, this is more than just theory

If you now think, this all sounds great if only such a framework would exist, I have good news for you.

I’ve been working on a framework like this for the last one and a half years. Kubestack is an open-source Terraform GitOps framework for infrastructure automation. It’s designed for teams that want to automate Kubernetes based infrastructure and not reinvent automation. Think of it this way, Kubestack is to Terraform and infrastructure automation, what Spring Boot is to Java and cloud native applications.

The framework supports all three major cloud providers and has been used as the foundation for a number of real world customer projects as part of my colleagues’ and my consulting work. It is fully documented, has a step-by-step tutorial to help users get started and even includes a local GitOps development lab. So you can test-drive Kubestack and learn more about GitOps for infrastructure automation in the comfort of your own localhost.

For questions there is a #kubestack channel on the Kubernetes community Slack and the repository on Github.