Why Terraform Concurrency Matters

One of the main benefits of using Terraform is the speed at which engineers can develop code and deploy it. A single module can be used to make changes across thousands of resources impacting hundreds of applications. The problem is that Terraform is only as fast as the system it is running on.

This slows down how fast resources get delivered, and it wears on developers too. Picture yourself pushing changes during a maintenance window or an incident, under pressure to move fast. The last thing you want is to sit and wait because the system deploying your Terraform has hit its concurrency limit.

This is why concurrency-based pricing models (used by some alternatives) are a poor fit for IaC platforms. They sell fixed parallel run slots, so there's no number that works. Buy too few and engineers queue during releases and incidents. Buy too many and you pay for capacity that sits idle. Worse, the model caps your throughput during outage response, the moment you can least afford it. Usage-based, per-run pricing charges only for runs that actually executed. That's why Scalr does not charge for concurrency.

How Scalr Previously Handled Concurrency

Every Scalr account automatically gets five concurrent runs when subscribing to a paid plan in Scalr. While we would love to give everyone unlimited run concurrency, we have to have controls in place to avoid abuse of the system, which is one of our core principles. The concurrency limits included the runs executing on self-hosted agents, which really couldn't have abused the core of Scalr.io.

Since self-hosted agents don't actually put that core at risk, applying the same limit to them didn't make much sense. So we changed how concurrency works for self-hosted agents.

How Scalr Now Handles Concurrency

We decoupled the concurrency applied on the scalr.io runners with that of the self-hosted agents. Each agent can have a maximum of 5 concurrent runs at a time and our customers are in full control of how many agents they deploy.

For example, if you have 5 concurrent runs on the Scalr.io runners and you deploy 5 agents, you now have 30 concurrent runs at no extra cost.

What was the result:

While we knew that this would have a positive impact on the developer experience, we didn't expect how drastic it would be. Across our entire user base we saw the following happen:

• The number of agents deployed went up by 114%.
• The average wait time from when a run was triggered to the actual execution went from 39 seconds to 0 seconds.

Looking deeper into one of the most impacted customers, a large hardware retail store:

1. This customer had 15 concurrent runs before we made the change. With 10 agents deployed across their account, they instantly went from 15 concurrent runs to 65 when the limits were removed.
2. In the 20 days leading up to the release of this feature, they had an average wait time of 5 minutes and 48 seconds across 3,670 runs. This is a total delay of 355 hours.
3. Since removing the concurrency limits from the agents, the customer has had an average wait time of 0.14 milliseconds across 3,330 runs. Their wait time has gone from 355 hours, to essentially 0.
4. This same result is seen over and over by many of our customers, greatly improving the overall developer experience.

Compared to the competition

Scalr is a drop-in replacement for Terraform Cloud, please see the difference below in how the Scalr offering compares to TFC:

Comparison of Terraform Cloud & Scalr's Agent & Concurrency Availability by Plan

When customers control their own concurrency, they ship faster and their developers spend less time waiting. There's no good reason to let a concurrency limit hold up your releases. Sign up for Scalr and try it for yourself.

Disclaimer: All information was accurate as of April 10th, 2024, based on publicly available information