Avoiding the Seven Sins of Infrastructure as Code

Posted by Igor Mameshin on Jul 30, 2020 10:00:00 AM
Find me on:

Let’s look at the “seven sins of infrastructure as code” that most commonly occur within organizations, so that it is possible to recognize and avoid them.

It can be easy to take for granted the agility that the cloud has brought to software development and DevOps. But, it was just a few years ago that Amazon Web Services (AWS) introduced us to the concept of the cloud as a programmable entity where we could provision and manage infrastructure via APIs and software scripts. Now, we regularly use these scripts—known as infrastructure as code—to rapidly and efficiently create data centers in the cloud. Examples of tools that can be used to manage infrastructure as code include Terraform, CloudFormation and Helm.

Seven Sins of Infrastructure as Code-2

Significantly, because important design decisions are expressed as infrastructure as code, this knowledge is no longer hidden somewhere in somebody's mind. We can all review the scripts and understand the nuances of how servers, networks, storage, security and other resources have been deployed.

However, realizing the benefits of infrastructure as code for agile software development and delivery isn’t easy. It often takes more time to write infrastructure as code than performing certain tasks manually. As a result, DevOps teams often take shortcuts to get up and running faster. In doing so, they set themselves up for security breaches, higher costs, and unanticipated complexity down the line.  

Let’s look at the “seven sins of infrastructure as code” that most commonly occur within organizations, so that it is possible to recognize and avoid them.

Sin #1: Security Shortcuts

The number one sin is failing to implement proper security because it takes a lot of time and knowledge to do so. For example, DevOps engineers may not require certificates based on the SSL/TLS protocol for all microservices, or they may not apply proper identity and access management (IAM) roles to cloud resources. Such omissions can leave organizations susceptible to attackers, who can pretty much do anything once they get access to the system.

Compliance as code can help address the challenge. This category of software applies an infrastructure as code approach to automate the implementation, verification and monitoring of compliance status as related to security, data protection, and various budgetary restrictions. Various security scanning and penetration testing tools can be inserted into a DevOps pipeline, so that scanning the environment for security becomes part of the regular deployment process in bringing versions into production.

Sin #2: Not Implementing End-to-End Automation 

Too often, DevOps engineers will cherry pick what they decide to automate as part of their cloud infrastructure deployment—automating the easier processes while continuing to operate more difficult steps manually. These manual steps then become the weak links.  

Think about the times when an airline system has gone down because of a failed system upgrade, preventing travelers from booking a ticket. Most often, such failures are caused by some improperly executed manual process in the upgrade that takes the technical team up to a  day to resolve. These are good examples of how failing to implement end-to-end automation can lead to unhappy customers and lost revenues. 

Sin #3: Insufficient Automated Testing

Developers recognize the value of automated testing for their applications, but many DevOps engineers forget to apply similar testing to their infrastructure as code. However, like apps, infrastructure as code continues to evolve, and those changes can lead to bugs that break the code. For this reason, it’s critical to apply automated testing to both applications and infrastructure as code to ensure that infrastructure configurations will run properly.

Sin #4: Ignoring Cost Optimization Best Practices

We’ve seen real-world instances where a deployment could cost either $1,000 or $100,000 per month, depending on how the cloud infrastructure is managed. Optimization may take the form of right-sizing resources, taking advantage of spot instances, identifying idle resources, or running across multiple cloud platforms, to name a few.

Yet, in the rush to get a project off the ground, some DevOps engineers forget to implement cost optimization in their infrastructure as code. Certainly, it will take more time to incorporate cost optimization best practices, but the monthly savings in cloud costs will provide a rapid return on this investment.

Sin #5: Creating Cloud Junk

It is very easy to create new infrastructure but not so easy to delete it. This often leaves organizations with orphan resources in the cloud that are no longer needed. And enterprises  are paying cloud providers for this “cloud junk” still running unused on their platforms. For this reason, DevOps engineers need to ensure that they are automatically un-deploying unused resources as part of their infrastructure code.

Sin #6: Hard-Coding Parameter Values

Hard-coding is the practice of embedding environment-specific properties, or parameter values, directly into the source code for DevOps automation. A sample of this anti-pattern is when administrator credentials are hard-coded into infrastructure-as-code scripts, making it possible for attackers to use those credentials and hack into the deployment infrastructure. Hard-coded values also result in environment-specific errors, making repeatable and automated deployments difficult to achieve.

Sin #7: Monolithic Scripts

Sometimes, DevOps engineers will combine many tasks into one large, monolithic automation script. If they need a similar script, they will copy and paste the original script, and overwrite a few parameters. This approach leads to infrastructure as code that becomes too complex to maintain and extend.  A better approach is to break down infrastructure code into separate modules or stacks, and then combine them in an automated fashion at deployment time. There are several benefits to this approach. First, DevOps engineers have greater control over who has access to different parts of their infrastructure code. Second, this allows teams to reuse work in future projects. Third, it helps DevOps teams to maintain and test modules.

Avoiding the Seven Sins with Agile Stacks
Enterprises can invest in properly writing infrastructure as code that avoids the seven sins outlined here. However, that pulls valuable resources away from investing in the development of the business applications that drive their growth and profitability. 

Agile Stacks frees organizations from the costs and risks of writing infrastructure as code by providing full-stack automation templates to enable the proper automation, security and consistency of deployments. Having invested extensively in the development of infrastructure as code that applies best practices, Agile Stacks lets enterprises deploy cloud infrastructure in an automated, standardized and consistent way. And, with the reusable, composable stack templates provided by Agile Stacks, DevOps engineers can get up and running within a week instead of taking six or more months to write their own infrastructure as code. 

As a result, organizations can bring robust, secure applications to market faster, while making  cost-effective use of cloud infrastructure to maximize both their revenues and bottom line.

Book a Demonstration

Topics: Container, DevOps, Infrastructure Automation, Kubernetes, IaC, infrastructure as code, cloud infrastructure

Subscribe Here!

Recent Posts

Posts by Tag

See all

RSS Feed