Infrastructure as Code (IaC) is a fundamental concept for DevOps. We use it within our own development processes and embrace it with our customer deployments. But IaC has its limits, especially as DevOps teams grow in headcount and expand globally.
As organizations scale to accelerate innovation and drive revenue, the limitations of Infrastructure as Code become apparent for software development and DevOps teams alike. These limitations are prompting the need for a scalable solution for delivering and optimizing cloud infrastructure at scale.
This article highlights some common challenges for enterprise DevOps teams that rely on Infrastructure as Code alone.
Creating Infrastructure as Code requires cloud expertise
With Infrastructure as Code, DevOps engineers spend significant time creating scripts and building modules, which leaves less time from more strategic engineering work.
The components required for building enterprise-level infrastructure and application environments need to be complex to support modern applications. Individuals tasked with creating the infrastructure code and creating the modules not only need to be experts in cloud computing and infrastructure configuration, but they also need to understand how different tools interact to orchestrate a seamless automation sequence. And that’s before factoring in the effort required to add automated security and governance controls.
This complexity results in a massive development effort to automate development or testing environments for each software development pipeline. When scaling to support all non-production workloads supporting hundreds or thousands of applications, the creation of IaC code can be disrupt productivity substantially.
As a result, the creation of IaC files often becomes a bottleneck slowing access to the cloud infrastructure and sandbox environments supporting the CICD pipeline.
The DevOps engineers with the expertise to create infrastructure code become responsible for all IaC requests, creating delays that inhibit productivity for the software development teams who need them.
Provisioning Infrastructure as Code requires cloud expertise and security access
Beyond the creation of Infrastructure as Code modules, provisioning infrastructure can become a bottleneck as well.
Even with IaC automation platforms, infrastructure provisioning requires:
- Ensuring all infrastructure components are deployed in the correct regions and with the proper input parameters
- Understanding the correct cloud platforms, services, instance sizes, parameters, and other details to ensure reliability, security, compliance, and cloud cost efficiency
- Orchestrating the cloud environment to define dependencies among all infrastructure resources, including storage, databases, networking, and other key components needed to support the stage of the pipeline
- Reconciling differences among infrastructure components and other resources needed to run an environment, such as orchestrating resources defined via an IaC tool with configuration management resources such as Ansible
- Cloud account credentials and other secrets required for IaC security
Even with an IaC tool, such as an automation platform for infrastructure provisioning, this combination of complexity and security considerations compounds operational bottlenecks for access to Infrastructure as Code. Any attempt to expand access to provision infrastructure increases IaC security risk by further distributing credentials and secrets.
Infrastructure as Code lacks enterprise cloud governance
DevOps teams are tasked with ensuring cloud infrastructure is reliable, secure, compliant, and optimized to minimize wasted cloud costs.
The decentralized nature of cloud infrastructure makes this difficult, as misconfigurations, security risks, lapses in regulatory compliance, and wasted cloud costs can go live in the CICD pipeline before a DevOps engineer can correct them.
Infrastructure as Code was designed to accelerate the declaration and provisioning of cloud services, but does not inherently enforce governance. Even DevOps teams that have created cloud governance resources, such as Terraform Rego files defining Open Policy Agent standards, may struggle to enforce them due to the decentralized nature of Infrastructure as Code.
Enterprise software development teams need a proactive approach to ensure cloud governance across all dev, test, staging, and other environments supporting their software development pipelines.
Infrastructure as Code alone doesn’t support Day 2 operations
Infrastructure as Code tools are valuable for accelerating Day 1 operations like provisioning the environment, but what happens after that?
Day 2 operations required for day-to-day infrastructure management can take up a significant amount of time and resources for a DevOps team. This can entail everything from ensuring the state of all cloud services are reliable and secure to responding to any unexpected infrastructure change or issue such as configuration drift or infrastructure provisioning errors.
While managing the lifecycle through IaC tools is manageable at a smaller scale, it’s mostly manual. As teams grow, the ease of managing the environment lifecycle shrinks, and the consequences of an orphaned cloud could result in overspending or open security vulnerabilities.
As your teams grow in headcount and expand geographically, Day 2 operations—like performance, governance, and retiring the environment—need to be factored into automating and completing the infrastructure lifecycle.
Infrastructure as Code lacks visibility and context
DevOps and software development teams lack the visibility to understand which resources have been deployed via an IaC tool or who was responsible for the configuration or deployment of a cloud environment.
This makes it difficult to investigate an infrastructure change or de-bug a cloud environment. As a result, DevOps teams often need to dig through lines of infrastructure code and logs to determine the cause of any provisioning errors or configuration drift, holding up the CICD pipeline as a result.
Enterprise software development organizations typically have visibility into their application performance and code. Maintaining productivity, security, and governance requires equal visibility into infrastructure code and IaC usage across the CICD pipeline.