How to Remove IaC Bottlenecks (DevOps)

In the dynamic world of cloud computing, Infrastructure as Code (IaC) emerged as an approach to streamline infrastructure provisioning. IaC promised to simplify and speed up the deployment process, ensure consistency and reduce human error by enabling the automation of infrastructure setup through configuration code. It was hailed as a game-changer, allowing developers and operations teams to work together more efficiently.

IaC was great 🙂! Until it wasn’t 🙁. As IaC adoption grew, so did the associated challenges. The very tool designed to remove bottlenecks started to introduce its own set of complexities. This blog talks about some of the ways IaC can become a bottleneck. We will explore innovative strategies such as Infrastructure from Code, to overcome these hurdles.

Five Common IaC Bottlenecks

With every technological advancement, there are new complications, and IaC is no exception to that. As IaC use spreads and continues to be implemented at scale, new bottlenecks arise, such as:

1. Communicating About Requirements

Bottle Neck Stock photos by Vecteezy

Let’s consider a very normal scenario. You and your team have spent a lot of time crafting templates for cloud components the engineering team might need, all so that they don’t have to come to you for IaC for every deployment. But fairly regularly, a team will want to use a component you don’t have a template for, either because it’s a new offering or just never been needed before. Now you enter a back-and-forth fact-finding process where the DevOps team is trying to get context on what it is about the developers app that requires this component. The  developers have a lot of context on why they want or need the component, and they are frustrated that it takes time and effort to come up to speed. Meanwhile, the DevOps team is frustrated that the developers keep cutting corners and leaving out information. This frustrating process can take weeks, depending on the rules of your organization and the complexity of the app or cloud component under discussion.

When we add miscommunication or lack of clarity into the mix, there can be even more significant delays and rework. This friction can happen because developers ship IaC configurations that DevOps needs to rework, or because developers have to come to DevOps with lots of questions because they can’t create complete IaC on their own. Ultimately, the deployed infrastructure might not meet the app’s needs, causing further complications.

2. Inefficient IaC Creation

Developers are primarily focused on coding applications, not on infrastructure management. Conversely, DevOps and platform engineers specialize in infrastructure, including IaC. This disparity in expertise can lead to inefficiencies when non-experts take to writing IaC. Once non-experts start writing IaC, you introduce a back-and-forth between people who don’t know what they don’t know and people who do know but don’t have a lot of extra time. The inexperienced developers ask what they think they need to know, and the DevOps team answers the question they were asked, but doesn’t know to answer the secondary question. This is an inefficient collaboration between developers and DevOps, because developers don’t know what to ask to get what they need and DevOps doesn’t know what developers need and can’t guide the questions in the first place. Wasn’t IaC supposed to save us from this in the first place? This particular misalignment often results in suboptimal infrastructure configurations that require extensive rework and lots of frustration on both sides.

3. Security Unknowns

Bottle Neck Stock photos by Vecteezy

Secure configuration is essential when it comes to IaC. However, development teams might not be aware of every necessary security configuration. They may rely on outdated templates or miss critical security measures, leading to vulnerabilities. The lack of comprehensive security knowledge among developers can slow down deployment and necessitate additional audits and corrections by security teams. And if they do deploy with a misconfiguration, that’s going to be pricey to fix.

4. If Everyone Owns It, No One Owns it

In the era of “you build it, you own it”, who exactly is in charge of making sure that infrastructure is staying up to date? When a patch is needed, who updates it and are they doing it directly in a UI or by updating the IaC. In incidents, it’s very easy for a developer or incident manager to update the offending cloud component outside of IaC, only to have that change reverted the next time the IaC is pushed. 

As modules, libraries, and other resources have new versions come out, who makes sure the IaC is updated? Do developers always go to find the newest template version, or do they use the same one until it breaks or someone scolds them into updating? Ownership of IaC updates can be damaging for a business when execution bottlenecks emerge. DevOps teams need to know infrastructure is maintained and have a good way to enforce it at IaC creation - not after the fact. 

5. Frustration

I know I’m talking about bottlenecks overall, but bottlenecks themselves lead to soooo much frustration. Whether that is because the developer can’t get a feature deployed, a DevOps person is stuck auditing IaC, or the security team keeps getting pulled away from other jobs. Every time you hit a bottleneck, people get annoyed and productivity goes way down.  

Platform engineers, DevOps, SREs turn to IaC to provide scalable infrastructure solutions, but when faced with these bottlenecks, it is unlikely to benefit the way organizations expect, and it can sometimes feel like it’s doing more harm than good. But don’t worry, there are ways to help get around these bottlenecks!

IaC Alternatives (aka Bottleneck Mitigation)

How do you get around these bottlenecks? There are a number of options that platform teams are investigating, and we’ll talk through some of them here.

Templates

Templates are a big way platform teams try to get around the back-and-forth of IaC creation with development teams.

Templates however come with their limitations (Lauren Rother addresses those in this blog). Lauren writes: 

“Templates often still require end users to go out and find information that they don’t understand and that they are then copying and pasting in. Templates require a version control strategy and system that everyone is familiar with and using regularly. Without this strategy or system, you have template sprawl where users just keep copying the same template they used the first time and never upgrading to the newer version.”

For templates to solve the problem, you need a very robust template library and a very disciplined engineering team who always pull the latest.

Infrastructure from code for scalable cloud infrastructure

Another option for speeding up IaC creation and deployment is Infrastructure from Code. Infrastructure from Code is the ability to generate code based on the application source code with all the default standards applied that a platform team/DevOps and security team requires. Instead of relying on developers to manually write IaC that needs to be audited by the infrastructure team, the infrastructure team can set standards at the organization level and then have developers generate the IaC from those standards.

Because this is auto-generated, you remove a lot of the bottlenecks.  

1. Requirement Standards Set: The DevOps/platform engineering and security teams set the standards for the organization. Requirements are inherently aligned with the application code. This eliminates the miscommunication between stakeholders and developers, ensuring that the infrastructure meets the application's needs right from the start.
2. IaC Generated: Infrastructure from Code allows developers to focus on what they do best: writing application code. The infrastructure code is automatically generated based on the source code and includes predefined standards set by DevOps and platform engineers. This reduces the need for developers to become infrastructure experts and minimizes the inefficiencies in collaboration between development and operations teams.  
3. Security Known: Security standards are applied by default with infrastructure from code. Since the generated IaC includes organizational standards, security teams can rest assured that the necessary configurations are in place. This reduces the need for extensive security audits and mitigates the risk of misconfigurations.
4. Maintainability: Updates and patches are applied when IaC is generated so everytime a new version is deployed, you are not introducing out of date templates. This ensures that all infrastructure configurations are up-to-date and compliant with organizational standards. This reduces the burden on individual teams and prevents the emergence of bottlenecks related to outdated infrastructure. 
5. Streamlined: With Infrastructure from Code, all bottlenecks are removed so you have less frustration amongst teams. Businesses get better productivity - think faster time to market! 

IaC is a one-size fits all approach to provisioning whereas Infrastructure from Code is application-centric. Infrastructure is requested for that application based on what is needed for it to run. 

By automating infrastructure generation based on application code and predefined standards, Infrastructure from Code streamlines the provisioning process and deployment, ensures security and compliance, and enhances maintainability. This results in a more efficient, productive, and harmonious workflow across development, operations, and security teams.

As platform engineering teams continue to evolve and seek more efficient ways to manage their cloud infrastructure, Infrastructure from Code stands out. Embracing this approach can help businesses overcome the limitations of traditional IaC and unlock new levels of agility and innovation.