Infrastructure as Code: What Is It, and Why Should My Engineers Care?

For decades, managing a server or two was a full-time job. System administrators would carefully curate their critical systems and ensure the business ran smoothly by their continued function. The last 10 years have revolutionized the way businesses manage their critical infrastructure. No longer are servers something kept in a dark, cold room in the basement. Today, cloud providers like Google or Amazon manage critical business infrastructure for thousands of customers in massive data warehouses.

This shift has changed the way that engineers manage infrastructure. Gone are the days of the system administrator responsible for one or two servers. Today’s engineers may need a dozen or a hundred servers to accomplish critical business goals. This shift in scale also shifts the way that engineers ensure correct configuration of their systems. You might’ve heard about new ways of managing environments like DevOps, or Site Reliability Engineering. Infrastructure as code is core to the concept of these new environment management techniques and all manner of employees are taking advantage.

What Is Infrastructure as Code?

Infrastructure as code (IaC from here on in) is a means by which engineers define the computer systems their code needs to run. Most commonly, these engineers utilize a framework like Chef or Ansible or Puppet to define their infrastructure. The tool used isn’t important in this case because they all work similarly. Each allows an engineer to define a computer system or network of computer systems necessary to run and support their code.

A common use case example for IaC libraries is managing web applications, but IaC is useful for all sorts of applications. Many applications today are quite complicated and require a load balancer, one or more web servers, database servers, and queue processing systems. A systems administrator spends hours provisioning and managing these interlocking systems. IaC reduces that time window to mere minutes and usually happens automatically! Engineers define the basic building blocks necessary for their application, and the IaC framework does the work to shape the environment correctly. The framework does this by provisioning virtual servers, installing software packages, creating users or starting code processes.

How IaC Works

How each library creates the correct environment varies depending on the library. Some operate in what’s known as a declarative structure: they define what systems should exist and what libraries to install. Others work in what’s known as an imperative structure. Instead of defining what should exist, they instead seek to define how to configure the environment to an acceptable state. We’ll dive into the specific pros and cons of each approach later, but an easy way to imagine the difference is to consider a television remote control and a thermostat. The remote control is imperative: it gives a series of commands which change the state of your TV. The thermostat is declarative. When you use it, you don’t communicate an increase or decrease in temperature, but rather what the temperature should be.

The most important thing to understand is that IaC is deterministic. Given the same environment definition, every engineer will wind up with the same system.

Test Infrastructure Like You Test Code

You might ask “Why adopt IaC philosophies?” The bottom line is simple: you’ll create a culture that generates better software, and you’ll save money. Developer time is expensive! You want to put that time to good use and you lose money every time you have a configuration issue that causes a developer or multiple developers to get stuck. These problems also make developers unhappy—most don’t enjoy tinkering with broken servers. Developers rightfully dread the moment they deploy a commit only to find that “something isn’t working right”. Figuring out what went wrong usually means they’re going to have a bad day. You want those developers to avoid those kinds of days because when they do, they write better software.

Getting a new test environment is expensive and difficult in a world where architecture is designed and maintained by humans. It can take days or weeks, which means a lot of wasted time for developers and they likely won’t test their code as well as they should. They lose the context of what they’re working on and take more time to remember how to debug their code. This is a problem that IaC is designed to solve. An effective IaC system means that your developers or administrators can spin up a new environment to test some code in minutes.

Why Testing Infrastructure Is Good for Your Business

This unlocks the powerful ability to test your infrastructure just like you test your code. Mature code bases contain many unit and integration tests, to verify that the code’s logic is correct. Those tests also protect against logical regressions, where new changes cause old things to break. IaC unlocks that same ability with your infrastructure, too. Your administrators never need to worry that the web server won’t be able to connect to the database. Why? Because they can take a few minutes to automatically build a new instance of the product and confirm it works to specifications. What’s more, they can create automatic scripts to run those tests. Now, every time a developer checks in some new code, a few minutes of cheap CPU time somewhere in a cloud provider’s data center confirms that code will work as expected when it goes live.

This eliminates the bad news that “something isn’t working right.” Instead, you’ll be able to deploy with confidence that your systems will work as expected. Your developers and administrators will experience less stress, and your customers will be happier with fewer bugs and more frequent features. Happier developers and happier customers mean better business.

Version Control Your Infrastructure

Imagine that a critical client has come forward and they want to run an old version of your software. They’ve offered your company a lot of money and your boss has told you that your team needs to keep them happy. In a systems administration world, this request means answering a wide range of configuration questions. Did that server run ruby 2.2 or 2.3? Was the server using Postgres 9.1 or 9.2? What about that critical bug you fixed by updating the version of your core framework? Did that fix require updating some other software packages along the way? Answering those questions is going to be a tedious game of trial and error and the time taken is going to eat into your profits from this customer.

A company that embraces IaC has their system definition files right alongside their product code. Reverting to an old version for a favored client is no more difficult than finding the correct version control commit and spinning up a new deployment using the included configuration. You’re confident that every release works correctly, because you’ve been testing them along the way. That confidence saves you time, and that time pays you back with better software delivered more quickly.

How Version Controlling Your Infrastructure Works

Version controlling your infrastructure is pretty simple and very similar to version controlling your code. Hopefully, your developers are already familiar with a version control system. If they’re not, now’s a good time to learn about that. Once you have a good version control system in place, checking in new infrastructure is the same as checking in new code, because your infrastructure is code. Your code includes the necessary information to build the servers that run it, and that’s true every step of the way.

The important part is that you’re checking in those changes in alongside the features they support and not separately. A feature’s infrastructure requirements should be a part of a feature’s branch or merge request. You’ll often need to deploy code for testing or business verification and having infrastructure defined with the code it supports makes that easy. When you split feature code from infrastructure definitions, you’re right back to the panic-causing problem. You don’t know how to make old versions work and figuring it out takes time. Do things the right way and make sure you define the infrastructure it needs to run correctly.

Streamline Your Change Control

We’ve focused a lot on how IaC makes the lives of your technical people better, and IaC succeeds at that. IaC also improves the lives of people in the non-technical part of your business. Companies develop extensive processes to manage the state of the software they ship. You can’t let your software stagnate, but it’s hard to make sure what you deliver to your customers is correct. It’s difficult to balance those priorities, and it’s common to spend a lot of time and money on it. Changing how you think about infrastructure isn't going to remove all that difficult work, but software delivery management solutions like Plutora can make it a lot easier to get right.

IaC makes your change control processes simpler because non-technical people see changes when they happen. Just like we can use automated testing to ensure our architecture works, we can easily set up new systems to manually test code as well. Does your project manager need to see some new feature? It’ll take a few minutes to spin up a test server. Now they can log in and walk through the change first hand. Feedback gets to your development teams more quickly and more clearly and this means that they push fixes more rapidly. The same process works for change control during the sign-off and release phases. Does some stakeholder need to verify a bug fix? It’s simple to set up a new system for them to log on and check for themselves. They’ll be able to see with their own eyes that it’s working, and approve the change with confidence.

Define a Unique Source of Truth

Most knowledge employees get better at their job over time. This is a good thing for your company! For system administrators, though, this improvement can be a double-edged sword. A system administrator who gets better at their job becomes more efficient at building and maintaining systems. The way that they set up their first web server won’t be the way that they set up their tenth, because their experience has been a good teacher. That’s a good thing, until you need a new version of that first server and they can’t remember how they built it. That problem grows worse when what’s running on that server might not be exactly what’s checked into your version control.

Tweaking code to make sure it works on an odd system is very common. It might be as simple as a config file which has been tweaked without being checked into version control. It could be that someone included some binary files on the server that don’t exist at all in your version control. In the worst cases, someone might’ve modified running code and doesn’t remember doing it. Whatever the circumstance, your customers have expectations about how your software behaves and they’ll be upset when their expectations aren’t met.

How IaC Fixes These Problems

When you adopt IaC, you choose to work to eliminate these issues. We’ve talked about the ways that IaC means better and more frequent testing. More frequent testing means those “little tweaks” float to the surface. Why? Because your automated tests will fail! Your administrators will document those tweaks and check them into source code. In the same way, configuration issues are easily identified when administrators need to change systems manually. You can identify those pain points and devote resources to fixing them.

The nice part of IaC is that once you eliminate these problems they’re unlikely to come back. This is because with IaC doing things the right way is easier than doing things the wrong way. Checking a new configuration into source control is easier than manually tweaking a configuration on each server. Writing a new install script is easier than logging onto the server to install something. As a manager, you’ll be confident in your software and infrastructure. Your employees will have an easier time building systems that work. The business wins and your employees appreciate their job more.

Approach IaC the Right Way

Previously, we noted that there are two major approaches to IaC. I can’t tell you which way is going to be right for your business. We can dive into the major differences between them and shine some light on areas where they excel and somewhere they don’t.

Imperative IaC

Imperative IaC systems define the “how” of systems configuration, like the remote control from our earlier example. This is the simpler form of IaC to get running. Basic installation scripts are the earliest form of IaC for most companies. The first step is that an administrator writes a script to install some bit of software on a server instead of logging in and doing it themselves. Over time, engineers combine these scripts to create a full system configuration script. This simplifies manual systems administration. Simpler systems administration means more predictable and consistent builds, which is one of the goals of IaC.

Imperative IaC has the benefit of being very simple to set up and easier for management to understand. Many companies already maintain a number of “build scripts” to configure their systems so they are only a few steps from imperative IaC. The trade-off for this simplicity is that Imperative IaC often requires more manual work from your administrators to keep those scripts up to date and can be more prone to unexpected breakage. Updates to installed software can break existing scripts and declarative IaC means your administrators are stuck fixing them.

Declarative IaC

Declarative IaC systems define the “what” of systems configuration, like a thermostat, as we explained previously. This is the more complicated form of IaC, but is also more powerful. When choosing a declarative option, administrators don’t define the steps to set up a server. Instead, they provide a list of requirements and third-party software does the work of installing the necessary software. These requirements can be as simple as a list of software packages or as complicated as an entire web of interdependent servers. It’s likely that your software developers already use a simple system for declarative IaC in the form of package management. Node Package Manager and NuGet are two common forms of declarative IaC utilized by companies worldwide.

Declarative IaC tends to be more robust than imperative IaC. Declarative IaC installations require less manual modification of scripts because external software manages the installation process. Automated programs like Chef or Puppet manage the process of resolving system dependencies. Administrators don’t usually face as many problems with upgrading software, because the software manages software interdependency for them. The trade off for this extra level of resiliency is complexity. It’s simpler to hire someone who can write installation scripts. Administrators experienced with declarative IaC systems tend to specialize in specific programs, which means they can be more difficult to source and more expensive to hire.

Listen to Your Employees on IaC

Now is a good time to listen to employees pushing for IaC. Your software will never be less complex than it is today and there are a variety of mature tools available to help your implementation succeed. IaC might not be the right decision for your company, but it’s worth giving your employees a chance to lay out their thoughts and formulate a plan. IaC often improves the lives of technical employees and boosts the quality of software they produce. A new IaC implementation can be a big commitment and that’s risky. The payoff for that risk is more effective employees, happier customers, and more confidence for you. Even if you don’t switch to using infrastructure as code, hearing out your employees might expose other problems in your process. Talking about IaC is an opportunity to improve your business, and there’s no better time than the present.