Something funny happens when a software category like “Infrastructure as Code” becomes standard practice– people start to think the players in that category fixed everything. All the things.

Cloud systems are easy now because Terraform and Kubernetes solved them, right? No doubt, they made more things possible and big things easier to do. However, many “simple tasks” are still very labor-intensive and require lots of mental juggling. As I discussed in a previous post about IaC just being a faster horse because it still functions only on the configuration level, we need a new frame of reference for cloud system management.

Let’s explore a real-world example to see how Torque makes a "simple task" of adding a new database truly simple, fast, and easy to do. Honestly, it’s not a fair fight. Neither Terraform nor Kubernetes are development frameworks. They can’t stop developers from needing to touch every configuration and every deployment. Read on to see how Torque does exactly that.

Task

• Add a new PostgreSQL database to the system that will be used by three application services.
• Name it ar_db (accounts receivable DB).
• Configurations should match existing DBs in respective environments.

  Assumptions

• As a starting point, imagine a system with two dozen application services and a few databases already deployed.
• It has local development managed by Docker, i.e., DockerFiles.
• Build system might be part of a code version solution, like GitHub or GitLab. Or it could be a separate service like Travis or CircleCI.
• Deployments to the cloud are managed by Terraform and Kubernetes.
• There are four deployed environments: two development, one UAT (User Acceptance Testing) or staging, and one production.

  The Current Way with Kubernetes, Terraform, Helm, or Similar IaC Tools

  We will assume that you are an expert in Terraform, you've been with the company for some time, and you are familiar with all the systems and setups. (Otherwise, you would not be assigned such a complex task unless you are the last engineer standing, and we absolutely have to do this.)

1. First, these tools do not handle your local environment, so that is a separate effort. (2 hours)
2. Additionally, configurations of different environments happen at different times, and it might be that weeks pass between setting up staging to production environments. (1 hour - to write all tickets in the PM system to address all the different environments when the time comes)
3. Then you need to figure out which configuration is used in which environment. (15 min per each environment)
4. And then, you have to find all the related configuration code that you need to copy-paste or update. (30 min per environment)
5. You copy the code and then change it in the development environment. (15 min)
6. You double-check your code to find any mistakes. (15 min)
7. Commit the change and open a code review request. (15 min)
8. Merge the code and wait until the database is up and running. (30 min)
9. Then, you find the configuration values that you need to bring to the three services. (15 min)
10. Next, you need to figure out how and where these services are defined. (15 min)
11. Only then you change the configuration. (15 min per service)
12. Commit the change and open a code review request. (15 min)
13. Merge the code and wait until the change propagates to check if all three apps are running and everything is configured correctly. (30 min)
14. But you cannot do all environments in a single pass since different environments are deployed in different events. The difference might be from hours to weeks away. And the effort has to be coordinated with developers to make sure no breaking change is deployed. So you repeat steps 3 - 13 three more times, one round per environment. Some steps might be a bit faster if you do them immediately since it is fresh in your mind where configurations are and what needs to change. But if it is after a few weeks, you have to refresh your memories again. (Steps 3-13 are 3 hours 30 minutes each, multiplied by 3 = 10 hours 30 minutes)

Total: 13 hours 30 minutes

With Torque Framework

Instead of assuming you’re an expert, we’ll say this is your first day at the job and you are not really familiar with any of the systems and setups. You barely remember what the company product is about. You are also not familiar with Torque Framework, either. The task given to you says something like:

Using Torque Framework, add torque.postgres.V1Component named ar_db (accounts receivable DB) and link it to service_1, service_2, and service_3 using torque.postgres.V1Link.

First, spend an hour learning how Torque Framework works.

Then, using the Torque Framework CLI, execute the following four commands:

• torque component create ar_db torque.postgres.V1Component (10 minutes)
• torque link create ar_db service_1 torque.postgres.V1Link (3 minutes)
• torque link create ar_db service_2 torque.postgres.V1Link (30 seconds)
• torque link create ar_db service_3 torque.postgres.V1Link (30 seconds)

Commit the code to your git repository and open a request for a code review. After the review is done, merge the code. Additional 15 minutes. (I assume you know how to use git)

Total: 1 hour 29 minutes

Next time you run the torque deployment apply command Torque Framework will use already installed definitions for Postgres, and a new DB will spin up on those particular environments. The execution will probably start with your development environment. Then, it will automatically propagate as your code propagates using your already established code automation through a CI/CD system. Set-it-and-forget-it, as they say. It will all just work when it needs to work.

Out of curiosity, since this is your first time using Torque Framework, you will wait until the development environment is deployed to see if it really did work since it feels unreal that you did so little to get the job done. You’ll start realizing just how much more power you have letting composable components do the heaving lifting for you rather than managing so many details by hand.

Time saved aside, tell me, do you feel the difference in cognitive load? How would you prefer to spend the 12 hours you reclaimed from this “simple task” now that you’re still fresh and haven’t finished your morning coffee?