My take on terraform

Disclaimer - don't shoot the pianist

it's been some time since I wanted to write this post. For those that are going to read it, I need to say that a) I hate the term DevOPs as a way to label engineers b) I'm a software developer, so I am the type of guy who really enjoys high-level languages like Java/ Kotlin etc and has been following DevOps principles per occasion or workplace, but being honest I did not have a solid Ops/Admin background. In other words, not all shops out there do or encourage DevOps as a engineering culture, so it really depends if you re going to experience it or not.

It is evident though, that through time in many companies, the typical developer stereotype is changing, a developer is asked to engage more often with then overall release life cycle of software rather than limiting himself/herself to only writing the code and then delegating to others to configure, ship, deploy and maintain software in production.

IMHO there is no better person to bring the code alive and take care of it, from the person who wrote it and knows it's strengths and weaknesses. So please don't shoot the pianist in case you don't agree with my views or my perception of things.

My experience with Terraform

I started seriously working with terraform 2 years ago. At first, it was like oh ok I don't know what I am doing, I don't understand what is going on. Then I progressed on copy-paste-ing this template run it and see what is happening, then I was like OK I am going to copy paste someone else's thing modify it a bit and support it. Now I am able to follow through all the templates, modules and in general kind of find my way around most of the production deployments.

So definitely there is a learning curve, if you happen to work in a place that Terraform is being adopted the higher the chances are that you are going to step up your game once you seriously invest some time. it's not rocket science, after all from a user's perspective, it's some simple notation, where you express how you want your cloud infrastructure to look like. Example, terraform please create for me a VM, some networking, a load balancer, some access right on the VM and please initialize them. Boom!

Having already lots of day to day experience with kubernetes and being very confident with Kubernetes deployment descriptors and tools like Helm, Terraform feels familiar in it's core. I would argue that terraform is very easy to use , the only thing you need is a couple of good resources, some reading and your personal cloud account (e.g. AWS). It is not a corporate-only tool, neither requires some magic heavy infrastructure.

Just a command line utility and a couple of API keys to access your cloud.

Books and resources

Through this ongoing journey, I used the following resources :

1. Terraform Up And Running
2. A comprehensive guide to Terraform by the GruntWork guys , here.
3. The Terraform book
4. The official Terraform documentation but is better if you start with one of the books and then take over the official documentation (IMHO). At least this is what I did.
5. Terraform videos / short courses on Plurarsight.

I would highly suggest you start with Terraform Up and Running and them move to The Terraform Book'. I kind of did it the opposite way, which I think it was wrong, so I high recommend you go through the above resources with that order.

So what is Terraform? (for newbies)

it's a utility you can download on your machine (I used brew) or use it as a docker container, which will enable you to change and shape your cloud infrastructure. This utility is fed with a set of files (deployment descriptors) where you will describe what things you want to run and instantiate on your cloud (e.g. AWS or google cloud). E.g spin vms, databases, s3 buckets, etc.

Terraform will read these files and translate them to actual API calls to the cloud provider, will also do the dirty job instantiating the resources for you with the correct order and save the state, meaning save somewhere what is already deployed so that next time that you run it can check what is already deployed and perform an more fine grained update ( like a diff).

Some might argue, why you want to do that, since you can login to the console of your cloud provider and eventually perform all these actions. Well for sure you can do that but

• Manual changes to your cloud infrastructure especially as it gets bigger and complex are error prone
• Manual means - manual labor - which means that you need to do the same things all over again - where you could just automate and script them.
• Every time you do a change you need to make sure that you don't break or alter something else, and we all know how complex the settings are in many cloud providers.
• You don't have continuous deployment semantics. Repeatable builds and configuration.
• Support more than one users, that try to mutate the state, e.g. development teams or organizations.

Should I invest time learning terraform as a skill?

Definitely yes if you ask me. As I said my background is not Ops so mastering the details of different cloud providers proves to be a full time job for many people. In my mind whatever tool or technology helps to reduce this learning curve is a good thing. Terraform abstracts in a way your interaction with the cloud provider. It does not abstract the cloud provider, meaning that if I write some terraform for AWS, and I want to do more or less the same things for Google cloud, you will end up writing something a bit different, since cloud providers are different. But at least you will have a common way of interacting with the different clouds, and you will develop skills on how to quickly leverage and re-use all your terraform resources. Instead of becoming a master on the AWS cloud console, and the google Cloud console, you will be a master on writing template files that instruct terraform to perform stuff for you.

Terraform is not only about AWS

Since AWS holds a large portion of the market ( 50/60%) meaning is the no1 cloud of choise for individuals and companies, many people assume that Terraform is somewhat AWS specific, which is of course not true. Terraform has this thing called providers, which is actually an abstraction for many clouds or services. So yes the most commonly used is AWS, but you will find an extensive list of different services that can be terraformed. Lately I am spending lots of time with the Fastly Provider, fastly being a CDN!

If you know terraform you don't become a cloud expert! A small trap.

Well it is not a trap of Terraform, but no matter if you master the way terraform works, and you quickly find yourself terraforming all the things, using its powerful template engine and all the nice utilities and resources, you must really know what you are doing.

In plain words, if you are good at terrraform does not mean that suddenly you became an AWS or Google Cloud expert! Becoming an expert on the different clouds, is a full time job and requires time and effort. That's why we have AWS experts, Google cloud experts etc. Maybe more modern clouds, e.g. the Google cloud abstract more things compared to traditional (older clouds) like AWS, but still at some point you are going to end up, searching or having to master the details.

I have to admit my journey on mastering thenAWS cloud is still on going, and I feel I have a long way, but this is part of the process I guess!