Read our newest book, Fundamentals of DevOps and Software Delivery, for free!

5 Lessons Learned From Writing Over 300,000 Lines of Infrastructure Code

Headshot of Yevgeniy Brikman

Yevgeniy Brikman

NOV 21, 2018 | 6 min read
Featured Image of 5 Lessons Learned From Writing Over 300,000 Lines of Infrastructure Code
This October, I gave a talk at HashiConf 2018 where I shared 5 key lessons we learned at Gruntwork while creating and maintaining a library of over 300,000 lines of infrastructure code that’s used in production by hundreds of companies. In this blog post, I’ll share with you the video and slides from the talk, as well as a condensed, written version of the 5 key lessons.

https://youtu.be/RTEgE2lcyk4
https://www.slideshare.net/brikis98/lessons-learned-from-writing-over-300000-lines-of-infrastructure-code-120597849

Although the industry is full of cutting-edge buzzwords—Kubernetes, microservices, service meshes, immutable infrastructure, big data, data lakes, etc—the reality is that when you’re knee deep in building infrastructure, it doesn’t feel cutting edge.To me, DevOps feels more like this:

#thisisdevops

#thisisdevops

#thisisdevops

#thisisdevops

Building production-grade infrastructure is hard. And stressful. And time consuming. Very time consuming.Here’s roughly how long you should expect your next infrastructure project to take, based on empirical data we’ve gathered while working with hundreds of different companies:

DevOps projects always take way longer than you expect. Always. Why is that?Well, the first reason is Yak Shaving, as perfectly illustrated in this clip from Malcolm in the Middle:https://giphy.com/gifs/ckBZc4aXqxz23NfhPi?utm_source=iframe&utm_medium=embed&utm_campaign=Embeds&utm_term=https%3A%2F%2Fcdn.embedly.com%2FThe second reason is that building production-grade infrastructure (as in, the type of infrastructure you’d bet your company on) involves a thousand little details. The vast majority of developers don’t know what those details are, so when you’re estimating a project, you usually forget about number of critical—and time consuming—details.To avoid this issue, every time you go to work on a new piece of infrastructure, go through the following checklist:
Not every single piece of infrastructure needs every single item on the list, but you should consciously and explicitly document which items you’ve implemented, which ones you’ve decided to skip, and why.

As of 2018, here are the primary tools we use at Gruntwork to build and manage infrastructure:
  • 1.Terraform: We use Terraform to provision all the basic infrastructure, including networking, load balancers, databases, users, permissions, and all of our servers.
  • 2.Packer: We use Packer to define and build the virtual machine images we run on top of our servers.
  • 3.Docker: Some of our servers form clusters where we run applications as Docker containers. The main Docker cluster tools we use are Kubernetes, ECS, and Fargate.
Now, all of these tools are useful, but that’s not the real lesson here. The real lesson is that tools, by themselves, are not enough. You also need to change your team’s behavior.In particular, the best tools in the world will not help your team one bit if your team isn’t bought into using those tools or if your team doesn’t have enough time to learn use those tools. Therefore, the key takeaway is that using infrastructure as code is an investment: there’s an up-front cost to get going, but if you invest wisely, you’ll earn big dividends over the long-term.

Infrastructure as code newbies often define all of their infrastructure for all of their environments (dev, stage, prod, etc) in a single file or single set of files that are deployed as a unit. This is a Bad Idea.Here are just a few of the downsides:
  • 1.Slow: If all your infrastructure is defined in one place, running any command will take a long time. We’ve seen companies where terraform plan takes 5–6 minutes to run!
  • 2.Insecure: If all your infrastructure is managed together, then to change anything you need permissions to access everything. That means that almost every user has to be an admin, which is another Bad Idea.
  • 3.Risky: If all your eggs are in one basket, then a mistake anywhere could break everything. You might be making a minor change to a frontend app in dev, but due to a typo or running the wrong command, you delete the production DB.
  • 4.Hard to understand: The more code you have in one place, the harder it is for any one person to understand it all. But if it’s all bundled together, the parts you don’t understand could hurt you.
  • 5.Hard to test: Testing infrastructure code is hard; testing a large amount of infrastructure code is nearly impossible. We’ll come back to this point later.
  • 6.Hard to review: The output of commands such as terraform plan becomes useless, as no one bothers to look through thousands of lines of plan output. Moreover, code reviews become useless:
https://twitter.com/iamdevloper/status/397664295875805184?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E397664295875805184%7Ctwgr%5E054bd0ad4ab228324aef44871dfff1ef049c15d9%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3Dhttps3A%2F%2Ftwitter.com%2Fiamdevloper%2Fstatus%2F397664295875805184image%3Dhttps3A%2F%2Fi.embed.ly%2F1%2Fimage3Furl3Dhttps253A252F252Fabs.twimg.com252Ferrors252Flogo46x38.png26key3Da19fcc184b9711e1b4764040d3dc5c07In short, you should build your code out of small, standalone, reusable, composable modules. This is not a new or controversial insight. You’ve heard it a thousand times before, albeit in slightly different domains:

“Do one thing and do it well” —Unix Philosophy “The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.”—Clean Code

Testimonial Profile Image

Testimonial Profile Image

If your infrastructure code does not have automated tests, it’s broken. You just don’t know it yet. That said, testing infrastructure code is hard. You don’t really have “localhost” (e.g., you can’t deploy an AWS VPC on your laptop) and you don’t really have “unit tests” (e.g., you can’t isolate your Terraform code from the “outside” world as all Terraform does is talk to the outside world).Therefore, to properly test your infrastructure code, you typically have to deploy it to a real environment, run real infrastructure, validate that it does what it should, and then tear it all down (for this style of testing, see Terratest, an open source library that includes tools for testing Terraform, Packer, and Docker code, working with AWS, GCP, and Kubernetes APIs, executing shell commands locally and on remote servers over SSH, and much more). What this means is that, with infrastructure testing, you have to slightly redefine terms:
  • Unit tests deploy and test one or a small number of closely related modules from one type of infrastructure (e.g., test the modules for a single database).
  • Integration tests deploy and test multiple modules from different types of infrastructure to validate they work together correctly (e.g., test the modules of a database with the modules from a web service).
  • End-to-end (e2e) tests deploy and test your entire architecture.
Note that the diagram is a pyramid, where we have lots of unit tests, a smaller number of integration tests, and a very small number of e2e tests. Why? Because of how long each type of test takes:
Cycle time with infrastructure tests is slow, especially as you go up the pyramid, so you’ll want to catch as many bugs as you can as low in the pyramid as you can. That means you should:
  • 1.Build small, simple, standalone modules (remember Lesson 3?) and write lots of unit tests for them to build your confidence that they work properly.
  • 2.Combine these small, simple, battle-tested building blocks to create more complicated infrastructure that you test with a smaller number of integration and e2e tests tests.

Let’s now put everything in this talk together. Here’s how you’ll be building and managing infrastructure from now on:
  • 1.Go through the Production-Grade Infrastructure Checklist to make sure you’re building the right thing.
  • 2.Define your infrastructure as code using tools such as Terraform, Packer, and Docker. Make sure your team has the time to master these tools (see DevOps Resources).
  • 3.Build your code out of small, standalone, composable modules (or use the off-the-shelf modules in the Infrastructure as Code Library).
  • 4.Write automated tests for your modules using Terratest.
  • 5.Submit a pull request to get your code reviewed.
  • 6.Release a new version of your code.
  • 7.Promote that new version of your code from environment to environment.
Get your DevOps superpowers at Gruntwork.io.
Share
Grunty
Resources

Explore our latest blog

Get the most up-to-date information and trends from our DevOps community.
TerraformResouces Image

Promotion Workflows with Terraform

How to configure GitOps-driven, immutable infrastructure workflows for Terraform using Gruntwork Patcher.
avatar

Jason Griffin

October 3, 2023 7 min read
TerraformResouces Image

The Impact of the HashiCorp License Change on Gruntwork Customers

How to configure GitOps-driven, immutable infrastructure workflows for Terraform using Gruntwork Patcher.
avatar

Josh Padnick

October 3, 2023 7 min read