Introduction

In my previous DevX article, The Magic of Kubestack, I quoted the following:

The best teams use frameworks to develop better applications faster. Using a framework makes it possible to skip the boilerplate, and focus on what matters.

But why do you still write infrastructure as code from scratch to automate your Kubernetes platform?

Kubestack is the Terraform framework that we always dreamed of to define and maintain custom platforms stacks.

I was excited about Kubestack being a framework for infrastructure. After all, I use frameworks every day to build software, so this must be a good thing. In the days that followed publishing that article, I thought more and more about this claim. I started convincing myself that I already had frameworks, such as Terraform, for automating infrastructure.

That's a framework, right? No. No, it isn't.

The more I pondered this, the more aware I became of the many ways that frameworks made my life easier as a software engineer. Inversely, I noticed how the tools I used for infrastructure lacked many of the same benefits.

The experience gap between software frameworks and infrastructure tools became very clear.

Frameworks Versus Tools

What I have come to realize is that the frameworks I use help combine, abstract, or otherwise automate the use of any number of tools for me.

For example, I can't remember the last time I had to manually open a file, set its read-write permissions, remember to append, etc. to write logs to disk. Similarly, I haven't had to manage network devices, send/receive buffers, or the metrics for my applications. My frameworks take care of all those things for me, without me even noticing for the most part.

But, when using Terraform to provision infrastructure, I do have to explicitly create and configure each resource. Even if that resource is so generic that I don't have to provide any custom configuration values.

For example, to create a managed database in my cloud environment with Terraform, I had to first create;

encryption keys,
security groups,
subnets & subnet groups,
permission policies,
scaling policies,
logging and metrics policies, and more!

Most of those did not need configuration, they simply needed to exist. I wish I could have just said "Dear Terraform, I need a new Database please." and Terraform could take care of all the boilerplate itself.

See the difference here?

Software frameworks provide many benefits that could be useful for provisioning infrastructure. These are the things that make infrastructure frameworks like Kubestack so very exciting.

Applying Frameworks to Infrastructure

I have identified the following 8 benefits of using software frameworks. Each can also apply to infrastructure frameworks.

1 - Going Fast & Keeping Up

As mentioned in the quote above; frameworks help developers move fast. They do so by taking care of basic tasks, or boilerplate, that is common with any project. If developers can ignore the tedious parts of writing software, they can move faster with solving real-world problems with software.

This premise also holds for infrastructure. Frameworks still help by removing the tedium of common tasks. Further, considering the entire DevOps lifecycle, the real power of infrastructure frameworks becomes more obvious. If software development is fast with frameworks, it is only a matter of time until infrastructure falls behind without one. Which in turn, slows down software development until the infrastructure can catch up.

By adding an infrastructure framework that provides the same speed benefits as software frameworks, the entire development cycle will iterate quicker overall.

2 - Best Practices Codified

With software frameworks, we interact with the interfaces provided to us. Many of the best frameworks even only offer a single way of doing things. If those interfaces promote clean code, our project will trend towards clean as well.

We call these opinionated frameworks. Many of the best frameworks I have worked with have had very strong opinions. While these generally have a steeper learning curve, the long-term benefits to your codebase are clear.

The argument for infrastructure frameworks here is the same. Using an opinionated infrastructure framework ensures that provisioning follows best practices and happens the same way every time.

3 - Component Abstraction

This point is like the previous one. Frameworks provide a level of abstraction so uses do not need to know what is happening under the hood.

For software this is great because we don't have to worry about how to do things like;

interacting with the filesystem,
sending and receiving packets over a network,
logging or collecting metrics,
encrypting sensitive information, or
how we communicate with other services (database, authentication, etc.)

Infrastructure can enjoy similar abstractions by using configs that are agnostic towards;

interacting with a specific cloud provider,
configuring routes or communication between services,
hooking up monitoring and alerting,
applying roles and security groups to resources, or
enforcing company policies, etc.

4 - Component Reusability

By abstracting software or infrastructure components we can reuse them. This not only reduces duplicated efforts but also helps maintain the internal consistency of the project.

Sometimes we can also share these components to lessen the load in other projects as well.

5 - Purpose Built & Battle Tested

Individuals and teams that build frameworks do so for a specific reason. Their sole focus when building these frameworks is to make it solve specific needs.

When using these frameworks we only have to think about the business logic. We do not need to understand the interworking of the framework as well. We can trust that the framework is going to be better suited, more thoroughly tested, and more mature than any home-grown solution.

The same goes for provisioning infrastructure. By relying on a battle-tested framework we can focus more on the business needs of the infrastructure and ensure it evolves accordingly.

6 - A Framework Never Forgets

Every time you do the same task with a framework, you get the same result. The same cannot be said about relying on your own mind.

Going back to my example above about logging to the disk. The Framework is not going to forget to make the file writeable or check if it needs to be appended to, it just works every time.

Continuing with the example above about provisioning a database. That task took me many hours to figure out using my tool. It was a painstaking process of applying iterative changes after realizing something was missing with each execution.

Sometime after completing that project I started working with a new team that needed to complete a very similar task. And guess what? I forgot half the steps again and went through the same iteration process all over again.

An infrastructure framework would not have forgotten those dependencies, it would have taken care of those tasks for me.

7 - Unified Team-Based Approach

Every developer has their own style, their own conventions, and their own way of writing software. This is one reason why being productive with another team member's codebase can be so difficult.

Frameworks can ease much of that toil by ensuring consistency, as we mentioned above in Best Practices Codified. This consistency provides familiarity and helps team members better grok codebases that they didn't write themselves.

Consistency with infrastructure configuration can have an even larger impact. Unfortunately, it is common for manual changes to occur on a server, or cloud provider console. These changes rarely make it back into a config file. It is also common that only one team member knows about the change because it was a fix to an issue or while on-call.

If we use a framework, to codify all infrastructure changes, that makes it easy to test and deploy, we can avoid many of these one-off situations. This way we don't have to poke around servers or consoles to check configurations. Instead, we can grep through the configuration repository or commit history.

8 - The Hive Mind

Any sufficiently popular framework will have a community of users form up around it. This creates a hive mind that provides a plethora of information. We can share experiences, issues, solutions, edge cases, pain points, and so much more.

With software or infrastructure, if you're stuck, chances are someone else has experienced the same thing.

Drawbacks of Frameworks

The benefits above make a strong case for using frameworks for both software and infrastructure. It is also true that frameworks are not always sunshine and roses. There can be drawbacks to using frameworks that we should be aware of.

1 - The Black Box

Many engineers chose this career path because they enjoy understanding how things work. This innate desire guided my early career; leading me deep into computer science and system security degrees. I enjoyed projects such as building my own Linux system from scratch and reverse engineering anything I could get my hands on. I wanted to understand the inner workings of everything I used.

I struggled with the idea of using frameworks when I started writing more code. I was afraid that if I didn't write it I wouldn't understand it. I had to learn to trust that the benefits would outweigh the drawbacks of not knowing everything. Over time I realized that frameworks implemented things better than I would since that wasn't my primary focus.

Plus, given that most frameworks are open source, I can still dig into the guts if I want. I don't do this often though. I've grown comfortable trusting the framework and focusing on building my own awesome software on top of them.

2 - Fine-Grained Control

Sometimes the component abstraction and reuse provided by opinionated frameworks aren't helpful. They can prevent you from having the control you need over low-level or unique situations. Most of the time we are fine without this level of fine-grained control. But there are definitely times we do need more control of specifics to complete our goals.

In cases like these, we are usually stuck with a workaround or discarding the framework. There is value in trying to view these outliers in the context of the framework. This helps challenge our default assumptions, designs, and ways of doing things. Sometimes the framework doesn't work out and you have to find another way. But occasionally it results in growth and a better understanding of the framework and our code.

3 - External Dependencies

With frameworks, not only are you externally dependent on the existence of that framework's code, but you also become dependent on the maintainers of said framework keeping it running and updated. Beyond that, if you experience an issue or bug that requires changes to the framework you are dependent on their ability, or willingness, to fix it.

With open-source frameworks, you can submit an issue or if you're ambitious a merge request (assuming your employer is ok with open-source contributions and the maintainer accepts them). Or, you could fork the code and fix it for yourself, but then you're stuck maintaining that fork now. You could also find a workaround until and if that issue gets resolved upstream.

I haven't found this to be much of an issue with popular or actively developed frameworks. Most maintainers are awesome and the community around the framework are fantastic resources.

4 - Impossible Integration

Not all projects are green fields. Which means adopting frameworks into our current projects. With infrastructure, critical pieces existed before and must exist after adopting a framework. It can be challenging, or even impossible, to integrate these existing pieces into a framework.

Some frameworks are modular; allowing for delegation of select responsibilities to the framework. Others are not; requiring control of everything and preventing integration with existing pieces.

In a perfect world, frameworks would be able to adopt state from external changes. I'm sure this wouldn't be foolproof either, but it seems like a good goal to keep in mind.

Conclusion

This post is the result of weeks of deep introspection about how I use software frameworks. In the end, I am very excited to see more frameworks that exist for managing infrastructure.

I opened by emphasizing the experience gap between software frameworks and infrastructure tools. I'll close by saying how excited I am to continue exploring Kubestack as a much-needed framework that aims to close this gap.

Don't forget to subscribe above if you are interested in following my exploration of Kubestack and other DevX tools.

Until next time, be kind to yourself and others, and keep learning.

CCTechWiz