5 reasons why frameworks make sense for infrastructure as code

In this post I hope to provide a few reasons why frameworks make sense for infrastructure as code, Having tried out Kubestack this got me thinking, Should more of these frameworks exist? And do they provide the same value as a traditional web framework like Flask, Express.js, or Ruby on Rails. Now you might be thinking don't tools like Terraform, Ansible, Chef already exists?

Well yes, but these technologies themselves are just tools and not necessarily Frameworks.

Back to basics

So what exactly is a framework in the context of software development? A quick google search would give you an array of answers, here are two answers/analogies I really like.

From djangostars.com

A web framework is a software tool that provides a way to build and run web applications. As a result, you don’t need to write code on your own and waste time looking for possible miscalculations and bugs.

From Hashnode

When selecting a web framework for a project there a few things one has to consider.

• Speed of development
• Maintainability
• Eliminate repetitive code
• Community support / documentation
• Reduce risk

How is any of this related to infrastructure as code?

To understand how this relates to infrastructure it's worth taking a look at a typical scenario where you choose a framework. Say you only want to accept post requests on /login in your app if you were to implement this from scratch you'd find that it is far from ideal in most cases and could potentially have its own flaws, Whereas virtually every modern web framework ships with it's own routing solution, saving you overhead that comes with implementing this from scratch.

As I mentioned earlier the premise for this article was my experience with kubestack, for the remainder of this article I would be making several references to it. But first a little bit on Kubestack.

Kubestack is an infrastructure automation framework built on top of terraform. Kubestack's primary aim is not to reinvent the wheel but foster rapid development using when using terraform.

From kubestack.com

Kubestack is the open-source Terraform framework for teams that want to automate infrastructure, not reinvent automation.

Now the same could be said about building infrastructure, if you were to spin up a Kubernetes cluster using terraform, there is a generic process of obtaining some boilerplate and customizing it to suit your needs. Now this isn't exactly a problem, however in a scenario where you have to create more than one cluster you may find yourself repeating this process once again and this is where my point about eliminating repetitive code comes in. Move over to something like Kubestack and this boilerplate is generated for you, this would be the equivalent of running Django-admin startproject xyz if you are familiar with Django. Obviously, this isn't convincing enough so let's do a side-by-side comparison of some reasons to use a regular web development framework and see if they could apply to infrastructure.

Side-by-Side comparison

For this section I would be looking at the following points:

• Speed of development
• Maintainability
• Reducing repetitive code
• Community support
• Reduce risk

Here I'll discuss how each of these points also applies to infrastructure as code.

Speed of development

In general speed of development is the time it takes to get an idea from your head into a working application, the tooling/frameworks you use can increase or hinder your development speed.

When creating a Kubernetes cluster a few things are relatively constant across each cloud e.g( picking node size/count, region ), at this point you already start to see how a framework could speed up development by abstracting these components whilst leaving room for you to customize as you please.

This is something Kubestack provides out of the box but I won't go into detail in this article. See here for more info.

Maintainability

Being able to write code quickly isn't always worth the effort if your app becomes a nightmare to maintain. Maintainability in software development refers to the process of writing code that is easy to understand, fix and extend.

"Good programmers write code that humans can understand." - Martin Fowler

I've seen a fair amount of projects become a nightmare from a lack of structure. Frameworks like Django or Ruby on Rails provide a nice scaffold to build your projects on top of, they also import relevant modules you are bound to use at some point. This is not to say that frameworks magically make all your problems go away but in general I think it provides a good stepping stone to making your app maintainable.

This directly transfers over to infrastructure as code to a certain extent, when starting a new project using something like Terraform for instance, it's hard to predict how large it would grow and this could potentially how you structure your modules, having a structure with relevant information pre-filled would significantly increase development. Going back to the inheritance model Kubestack adopts the chances that you misconfigure a module or copy-paste wrongly are significantly reduced.

Ansible actually does better in this regard with ansible-galaxy , helping you generate a rather sensible folder structure for your playbooks. Learn more about ansible-galaxy here.

Reducing repetitive code

reducing repetitive processes is at the core of both infrastructure as code and using software development frameworks, but in trying to automate I often find the process a bit repetitive and error-prone, having to use the same piece of code here every so often, Once again frameworks quickly reduce the amount of effort spent doing small things like this. Many frameworks ensure developers follow DRY principles. Terraform uses HCL for configuration , which by itself can become repetitive very quckily, classic example would be when provision more than one of the same resource

You might find your self copy-pasiting code or doing some weird stuff to get around this, whereas when using Kubestack your configuration follows an inheritance model which helps keep your configuration DRY this means you define once and simply inherit in any child module you wish

to make use of it in.

Community support /Documentation

This is perhaps one of the biggest advantages of using a framework, for every error you run into while using a framework there is a good chance a fellow user has experienced such and if for some reason they haven't this could be an opportunity to get involved with the project if you so choose. I can't imagine learning how to use Flask without the thousands of StackOverflow posts and issues on GitHub. No doubt a healthy community fosters the growth of any language or framework and I think the same holds true for infrastructure as code if the were more people using IAC tools with a framework approach at a lot more questions would be asked and ultimately leading to growth.

Reducing risk

When using IAC tools it's vital that your code is tested properly as the slightest of misconfigurations tends to have a significant impact on your infrastructure, when using a framework things are less likely to break as most features undergo a certain level of testing before it can be accepted, move over to IAC world and most of the testing is left to you, a typical example would be an incident that happened at Spotify, more details on that here. One common problem terraform users often encounter is what I am calling "state drift"(because I don't know what it's called), where your terraform state and code do not match leading to some undesirable results which was the case with Spotify. Going back to Kubestack, when using it, the remote state is automatically set up for you, which means you can focus on developing your infrastructure rather than worrying about your state files. This can be thought of like how Django provides a simple interface for setting up connections for different types of databases. Of all the points so far this is the most critical part, bad infrastructure directly affects end-users.

So what's the point of this article?

This article is not to advertise the use of frameworks in every project in fact avoid using them for as long as it makes sense, this is rather a subtle call to action and to hopefully convince about the benefits it could provide, i think it's time the DevOps tooling evolved in the framework direction.

If you'd like to learn more about Kubestack you can check that out over here.