For some time over the last few years, engineers with a finger on the beat, would have heard the term infrastructure as code and often wondered how they go about implementing this. An educated guess would be using some form of computer descriptive language to create environment resources. Albeit sounding like a complicated process, it really isn’t.
Well in short, it is as simple as knowing the environment your applications hosted in within a cloud based environment, and using creative tools designed for it to programmatically build resources.
terraform apply… “it can be as simple as that!”
In my earlier years as a support engineer, I didn’t have much love for scripting/programming because it seemed like too much work to make things work no pun intended, when you could simply click through using the UI. And yes humble beginnings from the windows side of things.
Nowadays, we talk immutable infrastructures, building decoupled based micro services architectures that all scale on demand. Infrastructure as code is one key ingredients that makes this happen. With all the shiny new tools, acronyms and practices people throw around, hearing the name of yet another simply makes learning any of the this stuff overwhelming.
Where does one begin to get an understanding of even how to start.
To do so is relatively simple, you really only have to know your cloud offering, be it Amazon Web Services (AWS), Microsoft Azure, Google cloud or even Digital Ocean. And in turn, find the tool they use to build out infrastructures. They big boys like Azure and AWS use tools called Azure resource manager templates and AWS Cloudformation respectively to do this, but if you want something cooler some might argue, there is a template building tool called Terraform. It’s an infrastructure building tool built by a company called Hashicorp. They are outsiders of sorts with no affiliation to any cloud provider. This basically means once you know Terraform’s own descriptive language, it’s a wrap like my colleague Alex would say. And from that point on, you no longer need to learn yet another language for any other provider except learning the terraform construct of how to create resources for a given provider.
So what is Infrastructure as code?
Let’s take a sneak peak at a terraform code snippet that creates a traffic Load Balancer.
Infrastructure as code abbreviated as
Iac you may have come across in a lot of articles, is changing the way we send that infrastructure request to the change management or infrastructure team for a new server to be built for your next product launch. From a single request of asking for a server, to a request asking for some network routing changes to be applied at a security group level within a staging environment for testing before pushing it off to production.
There are toons of examples of how applying such practices makes an engineer see beyond simply building and solving technical issues to more of an individual who starts to see the implication of how infrastructure debt affects a business.
There is something interesting about asking for a beefy server that processes large amounts of data to be built by a different team to one who build’s and selects the resources themselves. It makes you think careful about the cost implication’s amongst other thing’s as it begin’s to get rather easy to build infrastructure with code.
So how do we do this?
There are various tools used to create infrastructure as code as mentioned above. In my environment, we use
Terraform to build out cross application stack’s from docker based instances, to modulerized terraform manifest’s that build resources catered to specific application stacks.
One of the other exciting things about building infrastructure using code is that, you naturally begin to start thinking about how you can automate entire processes from code deployments to managing configurational drift as talked about by the guys from arrested devops. A problem were we have too many chefs and not enough cooks. A senior developer who has access to a production server, logs in, makes a change and no body has an account of what may have changed since the last code deploy.
After the code
snippet above for the terraform manifests has been written, you then push those changes using the terraform api with credentials from your chosen cloud provider. Once that hits your cloud provider or AWS in our case, it builds an application load balancer, which typically would point to an
instance running an application on a linux, windows or a docker container.
Just with that alone, I hope you are beginning to see how powerful a tool like this could be in your toolbet. Your mindset changes to that of an engineer who now thinks along the lines of how they can start glueing together different processes in order to orchestrate the building of systems.
Start thinking about how to turn your environment into code!
Guess the key takeaway from this is that, you start thinking about how you can turn those
infrastructure requests into code. If you are on any of those mainstream cloud platforms like AWS, Azure or GoogleCloud, look at their documentation on how one goes about building
infrastructures using templates. Terraform is powerful as it not only gives you the ability to build infrastructure with these major players, you can also use it to talk to various other services like DNSMadeEasy. Whilst building your infrastructure, you could also make DNS changes. Another is Fastly, a content delivery network provider. You can interact via their api to create custom VCL’s that help you throttle traffic in many different ways. From DDos mitigation to caching static site content.
To keep this short and to the point, I’ll end this here so we do not go off topic talking about other area’s like terraform workspaces, yet another new feature recently announced to play with.
At some point very soon, i’ll write out a post on creating resources with terraform in AWS. This would further showcase why you ought to really start thinking with code. Hope this has been some way informative.
So get started [terraform apply].