You Can Match How Many Deployments Amazon Does in a Day

Wonder how many deployments Amazon does in a day? In November 2014, Dr. Werner Vogels reported that Amazon achieves 50M deployments a year across their dev, test, and production environments. That's 136k deployments per day or about 1.6 per second. His article describes the systems they created to automate deployment across their infrastructure. That is only one aspect of reaching that astronomical position. You also need a lot of engineers to reach that level of productivity.

So, Amazon does 50M a year. When will your team achieve 1M deployments in their environments? 1M deployments may be difficult to believe if your team practices a monthly deployment or a quarterly deployment to your production environment. A team deploying to production every month will reach 10^6 deployments in a little over 83,333 years. A team deploying to production quarterly needs 250,000 years to reach 1M deployments.

I don't know how many engineers work at Amazon. But, we can speculate about how they get to 50M.

First, we can try to bring 50M down to a more human scale. Let's just assume they have 50K engineers for the sake of this example ¹. This would be about 1,000 deployments per engineer per year. That's still a lot of deployments per engineer (about 4 per day assuming 240 work days per year).

Perhaps, on average, each engineer is able to complete 2 software changes per week that are deployed to production. Each change is deployed to a dev environment a few times, maybe a test environment once or twice, and mostly just once to production. These will be small changes - probably any one change is not something observable by a customer. That's less than 100 software changes per engineer per year. The number of deployments is magnified by the amount of automation in their systems. Perhaps there are 5 to 10 deployments per change by an individual engineer at Amazon. Each engineer maybe makes 2-3 software changes per week that ship to production. Possibly updates shared libraries like the AWS SDK drive thousands of deployments too.

Is 2-3 software changes deployed to production per week something engineers on your team can achieve? Can you imagine automating 5-10 steps in your deployment process to deliver a change to production?

How long will it take different sized teams with different deployment velocities to reach 1M deployments? Consider the following table.

Across the horizontal access we have hypothetical team size. Down the vertical access we have number of changes per engineer per year. Both axis increase exponentially. The cells use the following formula to estimate the number of years it would take to reach one million deployments: $$ \frac{10^6}{commits * engineers * deployments} $$ That is, one million over the product of the number of commits, engineers, and deployments where the commits and engineers follow the axis above and number of deployments is simply 10 per commit. In a spreadsheet, basically this formula

=1000000 / ($B22 * C$2 * 10)

I belabor this point to show that for many organizations, achieving this change velocity is possible. 1M deployments is actually possible in about 10 years for organizations with more than 20 engineers making between 50 and 150 changes per engineer per year.

Teams that have higher deployment frequency learn more quickly and their changes are safer. Every change is a learning opportunity to see how it affects your environment. Changes are safer when they are smaller.

Teams that learn more are able to make more progress more quickly. This is basically the essence of what I take away from the State of Devops Reports over the last few years.

Also, a whitepaper specifically on the ROI of DevOps transformation where change velocity is addressed with respect to return on investment.

Elite technology performance, as characterized by

results in a better return on investment for the business.

Can you also achieve these results at your organization? Yes, we believe you can. We have influenced this type of change in real organizations. If you have a story or a challenge to share with us, we'd love to hear from you. Please reach out.