Infrastructure-as-code explained: Part I

developer using computer

Confused about AWS infrastructure as code? Amazon makes it easy – as long as you know what you want…

Until recently, scale changes to your IT infrastructure were a big deal. You had to carefully work out exactly what hardware you needed, justify the cost to get it signed off and then align the networking and storage people to help you set it all up. If the change was big enough you might have had to do the upgrades overnight (or over the weekend) so you didn’t upset everyone when it took a few attempts to get it back online.

Aside from issues of cost, logistics and stress, another downside of this approach was keeping documentation up to date, and spreading knowledge. All you needed was a bit of deadline pressure for niceties like build documents and training to fall by the wayside. This may not sound like a big deal, but if you’ve ever had to respond to a major outage and found that infrastructure was totally different to what you expected to find, you’ll know how Not Fun this is.

Enter Infrastructure as code

Infrastructure as code – or scripted builds to give it it’s old-fashioned name – is not really a new thing. People have been doing scripted-builds of servers for years, although there was still a fair amount of physical messing about with cables and configuring separate network components, that meant it didn’t save as much time as it does now.

But today, infrastructure as code on the Cloud covers all infrastructure, and makes it inter-operate properly. That makes scripted builds quicker, easier, and a lot less hassle, because:

  1. It’s a single vendor platform – so there are no separate configurations or compatibility worries. It all works together, and is configured from one place.
  2. It uses software defined networking, so there’s no manual connecting of cables or devices. You specify what you need, and once ‘got right’ it’ll work again and again without relying on any physical stuff being done properly.
  3. You get to use pre-baked server images, with ‘hooks’ that link to your build scripts and configurations. Someone else has already done the hard to work to make Windows and Linux listen to the build instructions, reliably.

So now, you have the ability to configure everything in a single place. The result is faster than manually building infrastructure, and saves energy and effort. Infrastructure-as-code is also really useful for tracking the current state of a deployed infrastructure – its a single, authoritative list of the servers, networking and security you’re using, so you can stick it in a version control system and forcibly record all changes made to it.

So, infrastructure-as-code makes everything simple and automatically ensures you have an accurate representation of the live infrastructure. But, once you’ve got it in place, there’s a whole lot of other things you can do…

Added benefits of AWS infrastructure as code

  • You can track changes. The build doc IS the parent of the live infrastructure so it must be an accurate representation.
  • Test everything at ultra-low cost. If you have a working giant config file, you can use this to clone your production infrastructure, test something on it, and delete it all again, within as little as one hour. Crucially, that means that for a few quid you can test something on a clone of your entire system and so be absolutely certain of what’ll happen when you apply it to your live systems.
  • Blue-green deployments. You don’t have to upgrade applications a few servers at a time. If as above, you build a new cloned ‘everything’ at full size to deploy and test, then if it works, carry on using it; if it doesn’t, delete it all using the same scripts.
  • AB testing. Some changes do need real-world usage before you can tell if they’re successful. AB testing means you can use your IaC build scripts to easily pop-up an entire cloned production infrastructure, and run both, sending a ‘guinea pig’ subset of users to the upgraded version. This is useful if you need to test a reaction to some upgrades, before unleashing them on everyone.
  • Allow developers to run the scripts and roll out infrastructures. Using ‘mini versions’ of production can ensure they’re building and testing on things that are the same size, shape and security as production – avoiding those ‘but it worked on my laptop!’ delays. You can also make the scripts update non-AWS systems, like CMDBs, which can be useful if your developers are forgetful about generating new infrastructure all over the place.

AWS infrastructure as code isn’t just for builds and upgrades. You can use the same method to change existing infrastructure and even turn it all off, easily. And if all this talk about ‘spinning up new stacks’ is financially worrying, you can even apply permissions policies. This will restrict people’s ability to update running stacks, even if they already have permission to do it manually.

Further information

If this sounds interesting, and you’re keen to get your hands dirty and see how it works, we suggest you have a go at setting up a VPC with a few servers, using Cloudformation, and give it a go. There are plenty of working examples you can download from AWS, and use to set things up. There’s also a very comprehensive 1000 page user guide on where everything is explained.

In Part II of this series, we’ll outline the various methods of infrastructure-as-code offered by AWS.