BoltOps Tooling and Software Design Philosophy

Software is often times more of an art form than it is a science. This is one of the reasons software tends to vary substantially between tools and developers. By following guidelines and design patterns though it can help keep the code consistent and clean. This allows the code to be understandable between engineers and them to move between tools efficiently. In this post, I’ll talk about what some of the best practices and software design patterns followed in the BoltOps tools.

The convention over configuration concept was popularized by DHH of Rails. He described Rails as a framework where you do not painfully have to set up 100 configurations variables just to get started. Things worked out of the box because of a starting set of conventions. This pattern is one of the greatest benefits of using Rails. The BoltOps tools follow the conventions over configuration pattern and things work out of the box quickly.

You will see that the conventions are not just baked into the tools but are found throughout the entire system; all the way to EC2 instances tags, ECS service names, Security Group are names, etc. This simplifies the tooling interfaces and makes life dramatically easier because the commands become concise and memorable. At the same time, the naming conventions guide you to keep your AWS account organized. Lastly, the tools provide the ability to override the conventions when necessary. This results in you getting the best of both worlds: the ease of use via conventions and the ability to customized if required.

Let’s walk through a few examples of the convention over configuration pattern found in the tools.

By convention, since the template and param file is the same as the stack name, the command can be shortened down to:

Both commands are equivalent and work just as well. The shorter command is easier on the eyes and saves your precious finger energy. If you need to override the convention, you can easily with the — template and — param options.

It will register an ECS task definition with the name hi-web-prod and then deploy that newly registered task definition to an ECS service with the same name: hi-web-prod.

This common sense naming scheme and helps you keep things well organized. And just like in the lono example, you are able to easily override the naming convention if required. Here’s an example of how to override the task definition:

I find it fascinating that many people promote cloud agnostic tools and center their debate around agnosticism as a core reason to as to why the tool is the better fit. What seems to be missing in the debate is that fact that while you won’t be locked into a cloud provider (in theory) you’ll be locked into the tool itself. This is not a much better position to be in either.

While the advantage touted about agnostic tools is multi-cloud support, the reality is that each cloud works differently. An agnostic interface typically results in the lowest common denominator interface being exposed at the common level. Sadly, this sometimes results in getting the worse of each cloud world and you are limited by the tool.

The BoltOps tools are designed to be a lightweight layer on top of the powerful plumbing of AWS. This is done for several reasons.

It is easier to understand the underlying resources that the tool is managing. Both Lono and ufo expose the raw template as part of the usage. This puts you a lot closer to the ground level and helps you understand the nuts and bolts of what is going on. The understanding helps you change and customize things down the road.

It is easier to update and maintain the tool when AWS updates their offering. There is simply less surface area to maintain. For example, the tools do not provide a GUI. Instead, the GUI is handled by the AWS Console. Why rebuild the AWS Console when you can simply tag your resources properly? Let AWS do the hard work. When AWS updates the Console with latest and greatest updates, there is pretty much nothing to change on your side.

It is easier to replace the tool for something that might be a better fit. Whether that’s something you’d rather build in-house or a new tool that BoltOps builds that is a better fit than the original one, it is easy to do. Since the tool itself is lightweight it is not much work to entirely replace.

Ultimately, the decision to be lightweight leads to these tools having no “tool lock-in”. You should use the tool if it’s a great fit for what you’re trying to achieve. If not, it is not an overwhelming amount of work to switch it out for another tool that works better for you!

This “Batteries included but removable” expression is from the Docker project. This means that the tools have already made some default choices for you to make it easier to use. However, you can override the default choices if needed.

This makes it easier to get started with the tool.

The software design philosophies with the BoltOps tools mean that they can be completely and quickly removed and you’ll still be perfectly fine. The tools are optional convenience tools. You do not have to use them. This gives flexibility and power back to you as engineers.

The tools are consciously kept simple. It is often better to build another tool for the specific product rather than try to make the same tool be the “god” tool and one cure-all for anything and everything. This is especially true given how fast AWS innovates and changes. By the time you are done with the tool, AWS has already come out with a new service that your tool does not support.

Often times your time is better invested in working on other specific tools than adding features to the same generic tool. This does not mean you should never write tools with reusable software abstractions. Design patterns are incredibly useful. Ultimately, it depends and is about what you are trying to get done.

Related posts:

Are you planning on getting engaged? If so, you’ll have to consider what kind of engagement ring you will get. This is because there are many myths about engagement rings out there. Engagement rings…

Today is all about mem­ory of food. Between my mom’s fam­ily cook­book, the new artist-friend I am con­vers­ing about food with, and the fact the last few weeks have been spent with a stom­ach bug I…

Get empowerment and trust yourself that you do a good job!