Guest Post originally published on the Cycloid DevOps Framework Blog by Niamh Lynch, content manager at Cycloid
If you’ve recently moved into the world of DevOps, or are thinking of it, you’ll soon come into contact with infrastructure as code. It’s a mainstay of good DevOps practice, but it can be hard to get your head around if you’re not familiar with infrastructures in the first place.
We recently had reason to get back to TerraCognita basics with one of our collaborators. The result of that educational exercise was actually a really good intro to infrastructure as code, so we decided to republish it here today (with some edits) to help out any of you who might need some education or refreshment in the world of infra-as-code.
TL;DR
We’re explaining infrastructure as code and the concepts that surround it. It’s aimed at people with little or no experience in tech infrastructures.
What happened before infra-as-code?
Before the era of cloud computing, people managed infrastructures (the technical makeup of their business, app, or website) by making changes via the command line or other interface. If you wanted to add or change something, you pointed, clicked, and made the change (aka manually modifying an infrastructure).
In recent years, lots of computing has moved away from the physical server room to “the cloud”. That’s brought a few major changes – modern infrastructures tend to be much bigger and more complex, their makeup changes more often, and we stop and start them much more frequently. That means you’d have to log in and make changes by hand hundreds of times a day, which just isn’t practical – it doesn’t scale and it takes too long.
Solving the problem – infra-as-code
To try and overcome this problem, infrastructure-as-code was created. It’s not a programming language – it’s more of a mindset or technique. In basic terms, it’s a set of instructions that tells your cloud provider how to set up and maintain your infrastructures without your involvement. It ensures that infrastructures are created and modified exactly to your specifications, each and every time.
Life without infra-as-code
Ideally, you or your company has created IAC for all of your infrastructures from day one, but that often doesn’t happen. If you’ve been around for a while, there are probably some manually created infrastructures hanging around somewhere.
This is a problem, because without infra-as-code your infrastructures aren’t reproducible. If they’re not reproducible, you can’t scale or grow, because it’s just not practical to write instructions for thousands of servers individually.
Another problem – without infra-as-code, there’s no written statement of what your infrastructure looks like. You know how you first set it up (hopefully, unless the person who set it up forgets, or moves on), but you don’t know how it looks now or how it has changed.
This reduces visibility (a key component of DevOps) and makes it really hard to apply policies (because the things you’re writing the rules for might have changed). Policies are sets of rules designed to apply to servers at scale. They make your infrastructure more secure, which is also a major part of DevOps and development in general.
Life with infra as code
Although infra-as-code is by far the preferable approach, it’s not completely without issue. Writing infra-as-code manually is time-consuming and – although valuable – not as valuable as other jobs devs and ops might be doing. It also runs a high risk of error (and by nature, it reproduces, so if there’s a mistake in your code, the mistake will scale too!). Maintaining up-to-date infra-as-code and/or migrating to the latest version manually can also be awkward and time-consuming.
You’ll also have to take care that everyone in-house is comfortable and au fait with IaC. If it’s something you’ve introduced, but other employees aren’t on board, they can make changes without using it, and break everything as a result.
Basically, infra-as-code is best practice and one of those tasks that developers know they should do, but for various reasons, haven’t. Sometimes it’s managers who are unconvinced of the importance, or sometimes life just seems too busy.
So where does Terraform come into it?
Once you start to find out more about infrastructure as code, you’ll start hearing about Terraform. Terraform is a type of infrastructure-as-code created by a company called Hashicorp. It’s not the only one – all the major cloud providers have their own IaC. Google offers Google Cloud Deployment Manager, AWS makes CloudFormation, and Microsoft’s Azure makes Azure Resource Manager.
Terraform gets all the love, however, because it’s open-source and platform agnostic, which means that once you learn it, you can use it in conjunction with any of the cloud providers or even write a custom plugin, to use it anywhere you like. If you learn one of the other proprietary tools, however, it only works on that platform and can’t be used on the others.
Summing up
So, there you have it. Infrastructure as code is a descriptive technique that allows developers and ops people to create one set of instructions that will be automatically set up and maintained by the cloud provider they relate to. Infra-as-code is pretty essential if you’re dealing with a sprawling, complex modern infrastructure – it’s too time-consuming to interact with the cloud provider manually. Infra-as-code is often written in Terraform, which is an open-source, platform-agnostic IaC tool, but there are others. Infra-as-code is a pillar of DevOps best practice and an all-around good idea, and now when the subject comes up in work, you can be sure you know exactly what you’re talking about!
See more about TerraCognita.