Building the Cloudification KPI Application – Part 2
This is our second and last blog post about the Cloudification KPI application, where we discuss how we managed and displayed the data we collected in part 1.
Being part of the cloud core team at SEB, this is a question I hear fairly often and it doesn't come as a surprise. Why so? Because SEB is on a journey to use more and more of the resources Google Cloud offers and we are very focused on using Infrastructure as Code (IaC) for setting up and maintaining it all. And when we onboard teams and developers to Google Cloud, we tell them that they preferably should use Terraform as their framework of choice regarding IaC. Understandably, they wonder why this is the case because developers normally use a wide range of tools, languages and frameworks and now they should do the majority of their work using only one? So why do we recommend that they use Terraform and does it have to be like that?
The great thing about IaC is that you can have your setup version-controlled, traceable, easily shared and audited. You can also add the safety layer of the 4-eyes principle via the use of merge/pull requests. This is not only great for safety reasons, but will also help with knowledge-sharing, encouraging smaller code changes and making it easier to discover issues early. So there are a lot of good things to take advantage of here.
However, when using IaC there are a few more things to think about too, like for example:
- You will run the code via a CI/CD pipeline so you want it to be idempotent, meaning it could be triggered over and over and still show a green, successful pipeline.
- You want to not only create but to update and destroy your infrastructure when needed.
- You want to find configuration drift where your infrastructure is diverging from the expected state that you want it to have.
- You want the IaC framework to be actively updated and maintained and it certainly needs to support most of the services that Google Cloud offers and have new services added continuously.
Why Terraform?
This is where we have found Terraform to be a great fit and let's show you why. The first important aspect is that it has the concept of memory via a state file. This makes it able to keep track of what has been done before; your expected state. Terraform then checks the actual state of those resources to see if it matches the expected state and here it can find configuration drift. It will display the changes induced by your code changes along with the ones made outside Terraform. Finally, it checks the codebase to get the new desired state and then calculates what it needs to do to get there.
These calculations will then end up in the plan file where one can view the changes that Terraform wants to execute based on the gathered information. You can choose to have a manual control step or even apply the changes automatically. This is up to you, but the possibility to see and double-check the changes in advance is a powerful thing. Here we can see that Terraform not only can create but also update and destroy resources that are under its control.
When applying the changes, we can see the output and verify the success — or failure — in performing the changes. These changes are then added to the state file containing your expected state.
So if you now run a new pipeline without doing any code changes, and assuming that there has been no configuration drift, then the plan file should show you that there are no changes to perform which is just what we want. That's sweet, right!?
Finally, is the framework actively updated and maintained? Google are themselves a part of the Terraform Community that is maintaining many of the providers used for configuring resources and services. And the Google and Google-Beta providers are coming with new updates continuously so we have seen good progress there so far.
Then back to the question at hand, do you have to use Terraform? The answer I normally give is "No, you don't have to" because the demand put on teams working in Google Cloud is to use IaC, not exactly how to achieve that. As described above, Terraform has a lot going for it but if a team wants it done in another way that still covers the demand then of course, go ahead. And please share it with the rest of us so we can get inspired and learn something new!
For reading more about Terraform and the Google provider see:
