Applications are lifeblood of a modern business. This means that IT groups everywhere are looking for ways to develop, test, and deploy applications quicker, while reducing risk of mistakes and thus potential defects and security issues.
In this post, we’ll have a quick look at how an approach called “Infrastructure as Code” can help.
In software development, delivery pipeline automation is the key to the speed while maintaining control. As application code travels from development environment to production, it is put through a number of stages where it is tested, packaged, and deployed.
At each of these stages, software needs something to run on – infrastructure, such as servers, storage, networking and security, and so on. For application code to move through its pipeline at speed, we need to create and configure this infrastructure at a comparable pace – measured in seconds / minutes, not days or weeks.
Virtualised or cloud infrastructure has the ability to create the resources quickly, but we need a way to tell it what it is that we require. What networks, servers, security devices / services and so on, and how to interconnect and configure them for our application.
Enter the tools
There are a few tools that were developed specially to help with this task. Two that deserve special mention are AWS CloudFormation and HashiCorp’s Terraform. These tools allow you to treat your virtualised / cloud infrastructure as you would a software code. You create a definition file where you describe what compute, networking, security, and so on resources you need instantiated, and how they are to be set up. Then, when you need a copy of your environment – to develop, test or run your application in production – you run the tool against your definition template, and the tool makes it happen.
You can create any number of instances of what you’ve defined. Each such instance can then be treated as an individual “infrastructure stack” entity. You can query it to show the state of its components or destroy it all at once, irrespective of how large or complex your template is. There are cases where a single template has thousands (!) of inter-related objects forming a part of a large application environment. Try building or deleting this by hand.
You can also make changes to your existing instances as easily as modifying the original template and then executing the tool again to calculate differences and make the necessary changes.
This approach to virtualised / cloud infrastructure management is referred to as “Infrastructure as Code”, or “IaC” because your templates essentially tell “what to do” to your virtualised DC or cloud-sized “computer” that manipulates virtual machines, networks, and so on.
How does this help your business stay competitive by developing higher quality, more secure software, quicker?
- Your software pipeline is not slowed down by infrastructure builds for each stage (dev, test, pre-prod, prod). Your contiguous integration / contiguous deployment (CI/CD) system can use IaC tools to automatically create a fresh copy of environment customised for each stage, without raising tickets or bothering anyone, in minutes.
- Your infrastructure set-ups are “set in code”, which means repeatable, consistent builds time after time, with no chance of a “fat finger” issue.
- Your infrastructure templates are the ideal place for applying security policies, as appropriate to each software lifecycle stage. These templates can be co-developed or reviewed / approved by your security team, and the IaC tools will make sure the agreed controls are in place. A very good example of this is the AWS PCI DSS QuickStart.
- Your IaC templates can live under version control, which means they can be developed collaboratively, reviewed, approved, branched, merged, etc., which is the process your development team is intimately familiar and comfortable with.
- Your automation can be automated. 🙂 As in, you can automate creation of your IaC templates, for example by building a “master” copy of your infrastructure stack, querying the resulting configuration, and converting the result into a template format. Turtles all the way down! 🙂
You can also share your templates with the world, to help and get helped by others who may want to use and improve on your work.
Which one is right for me?
There are obvious differences between CloudFormation and Terraform – former is proprietary and AWS-specific, while later is both open source and cloud-agnostic, and can support mixed public and private cloud environments and services within a single template.
At the same time, AWS pushes CloudFormation (“CF”) hard, which means information and help for people using it is more readily available.
While the main benefit of IaC is with the software development process, nothing stops you from using the same approach to deploy traditional IT applications. AWS maintains an ever-growing catalog of Quick Starts, all of which are created using AWS CF. I have not seen anything similar for Terraform, and it is not very likely to appear, IMO. HashiCorp is a tool company, not a cloud provider who benefits directly from people running templated IT apps on its platform.
Want to dig a bit deeper?
For a more detailed opinion piece on CF vs. Terraform, check out this blog post.
Coming up soon..
In the next post, we’re having a look at a CF template structure, and what the bits in it do. Got a minute? Have a read! 🙂