Stop Thinking About Plumbing
5 minute read
What is plumbing in software?
Plumbing is software is any code related to wiring things together. This could be code that listens to queue messages. The code that listens for queue messages is plumbing code that is often written over and over again in applications. Another, form of plumbing code is code for connecting to a database. This kind of code is generally the same from one application to another, however many developers continue to write this code manually. “Plumbing” code is code that allows an application to communicate with outside systems.
Stop Plumbing
As developers we should be looking for ways to eliminate waste in our daily work. This includes ruthlessly eliminating as much low value work as possible from our lives. “Plumbing” code is low value work that we should be trying to eliminate.
Many technologies have been created to eliminate “plumbing” code from our applications. For instance:
- Rails & Django – Removed much of the plumbing required for building websites using Ruby & Python respectively
- ASP.NET & Spring(Boot) – Removed much of the plumbing for creating .NET & JVM applications that are exposed through HTTP
These technologies are hugely valuable because they allow developers to focus on their application. The software professional can think about how to expose their application to the web. The software professional thinks about the behavior of the application, not how the HTTP protocol works.
SERVERLESS WITH AZURE FUNCTIONS
Despite its status as a buzzword “serverless” technology is another way for developers to eliminate “plumbing” code from their applications. For instance, Azure Functions offers 10 pre-built ways to be triggered. Yes, most of the pre-built triggers were made for interoperability with Azure services, but the community is building triggers as well. This means if a software professional needs to write code that is triggered through HTTP, Azure EventBus, GooglePubSub, RabbitMQ, etc. they don’t need to write any code that knows how to speak any of those protocols.
Terraform is a Polyglot
If you have ever done infrastructure as code development before you are aware of technologies like CloudFormation and ARM (Azure Resource Manager) Templates. These technologies aren’t inherently bad, but I have found them hard to manage and maintain over time. The reason for this is that these technologies use json or yaml to define the infrastructure of your application. The small application linked in this article generates over 500 lines of json code for the ARM template. Not only is this >500 lines of json it also is hard to split into separate files to make it easier to manage. Yes, I’m aware of how the json could be split into files, but the way to do that is cumbersome and not easy to do when compared to an alternative infrastructure as code tool like Terraform.
Terraform is an infrastructure/configuration management tool that speaks to different clouds. The important feature that makes me like Terraform is the ease of which you can break down your infrastructure code. The feature that is often talked about with Terraform is its ability to speak to Azure, AWS, GCP, etc. using one common language (HCL). Multi-cloud support is really interest, but in reality I haven’t seen many companies leverage terraform in this way. Terraform helps me solve the maintainability issues that come with using ARM and CloudFormation templates.
HOW DOES TERRAFORM EASE “PLUMBING”?
Terraform codifies the various command-lines and services that cloud providers offer into one language so that whether you are deploying to Azure or AWS or GCP or six different clouds the language and command-line is the same. If we needed to leverage AWS and Azure for instance we would need to become familiar with CloudFormation, ARM, AWS CLI, and Azure CLI. This increases the knowledge required of each team member to be effective, which means longer ramp up times for each team member. While it may appear Terraform doesn’t help with “plumbing” it actually does. It can understand how to speak AWS, Azure, GCP, etc., but the developers only need to speak HCL (Hashicorp Configuration Language). Infrastructure is important because our applications need to run somewhere, but how that infrastructure is created is a choice. In most cases I would choose Terraform for creating my infrastructure because I don’t care to understand the specifics of Azure, AWS, GCP, etc. I prefer to speak HCL and have Terraform figure out the specifics for me.
PULUMI MAY REDUCE RAMP UP EVEN MORE THAN TERRAFORM
While Terraform is my current choice I am keeping a close watch on Pulumi. Pulumi would further reduce the ramp up time for developers. I believe it will further reduce ramp up time as developers would be able to write their infrastructure code using a real programming language. Pulumi will allow developers to create their infrastructure using C#, Python, JavaScript, and Go. I would expect more languages to be supported in the future.
Example
For anyone looking for an example that leverages some of these technologies and others you can find the source code that goes along with this rant in this GitHub repo