What is infrastructure as code and why should you use it?

Infrastructure of code is just the process of writing down what makes a particular machine unique, in a way that both computers and humans can understand. (When I say infrastructure here, this is most often the servers that make up and support a given application or service.)

Depending on what configuration management software you choose to help you with this, you might be using Ruby, Python, or even Bash.

Does it run an http server? Does it have an increased number of file descriptors? What config files need to be in place for it to operate?

This resultant code can be run to recreate a machine or if it was changed incorrectly, even bring it back inline with how it should be if changes were made manually.

Having the definition be code allows you to do some things like:

How does this differ from documentation? The code is human readable, but also machine runnable, so servers can be recreated/updated as needed where as with docs, there are separate steps, update the machine (by hand?) and then update the docs.

With infrastructure as code, defining/updating the state that you want is the same thing as documenting it.

Infrastructure as code is not the same as documentation. Just having the definition of a server codified and recreatable is not a replacement for documentation, but it allows you to focus on your docs on different things.

Instead of having to go through and write everything down all over again about what’s on the server, you can write about why that server does what it does and how it relates to other infrastructure or applications.

For example instead of having to say Server X is a CentOS server that runs Application Y and has ruby version 2.2.3 and is firewalled with such and such iptables rules. You can instead focus on docs like server X is a server for Application Y and is critical for it to continue running. If you need to know what’s on the box and its version, see the code.

Complementary Process Diagnostic

With 30 minutes spent looking over your existing pipeline or process, we can diagnose the root cause(s) of slow releases or bugs. After 30 minutes on the phone or Skype with me, you will:

  1. Understand why your existing process may be allowing bugs to reach production and slow you down
  2. Learn ways you can increase the speed that features reach customers
  3. Have a list of ideas for improving your release process

We’ll have to move fast, of course, to get through all this in 30 minutes but don’t worry, I’ll keep us on track. To receive your meeting agenda and scheduling instructions, enter your email address below and click the button.