How much do the environments cost?
Oct 31, 2016
When I talk to people about environment management I’m surprised by the number of people who don’t understand how much they cost. In a large organization it isn’t immediately obvious just how much a particular environment costs. It isn’t like people announce how much a VM costs every time someone spins one up to support a QA test. People using these environments: the developers developing code and the QA testers checking features are almost never thinking about the fact that a large staging environment has a hefty price tag.
If you are an environment manager dealing with a 3rd party cloud provider such as Amazon or Rackspace the costs are known, but at a large organization with a private cloud you are often dealing with a central IT department that manages infrastructure and costs are captured as a chargeback to a business unit. In the latter scenario it can be a challenge to understand exactly how much an environment costs.
In this blog post, I present a simple model of the costs of various environments. How much does your company spend on production environments vs. the environments designed to support development? Before I present the model, let’s review the ideas discussed in a previous post: what are the minimum requirements for environments in a large project?
Minimum Requirements for Complex Software Projects
At a minimum, a complex software project requires between 4 and 5 separate environments, and given the continuous nature of software delivery all of these environments are required across all phases of the project. As a project matures your developers will be constantly developing software which is then delivered to QA and subsequently deployed to production. This baseline of 4-5 environments is what allows your organization to deliver and qualify software without having to stop and repurpose environments to cater to each individual phase of the software development lifecycle.
These requirements increase for a software project that involves multiple teams working on multiple releases in parallel, and with evolving approaches to production deployments there are often multiple production environments. In summary, you’ll need to plan for between 9-11 environments if you anticipate managing multiple releases in parallel.
Environments can get expensive... quickly.
Let’s take the example of a website that follows a common architecture. This project consists of web servers sitting in front of a number of application servers that query both a relational database and a NoSQL database. We’ll throw in a memory-based cache which is used to take some load off of the application servers. This is a relatively common architecture across technology platforms from more enterprise-ready systems like Java and .NET to newer approaches like Node.js.
The following diagram presents a simplified model of the resource requirements and costs associated with different kinds of environments. In these models we’ve ignored the costs of software licenses and support and focused on infrastructure costs.
As you can see in this model, the costs of environments can add up very quickly.
Development Environments: A large software project can have one or more of these environments configured to support different teams on a project. A development environment rarely needs redundancy and developers can simplify deployment by consolidated releases to fewer VMs. In this model a development environment only needs one VM of each type and can skip the caching layer.
Staging Environments: The closer an environment is to production the more it needs to resemble production. In this model we have a staging environment that includes all VM types in an architecture. As Staging environments are designed to model production this environment also requires a redundancy so that as QA qualifies a system for production any quality issues related to clustering can be identified.
Production Environments: The system presented in the model shown above models a website that is designed to support millions of complex interactions per hour and which is deployed across several data centers. While not all projects require this level of redundancy, some do. As you can see in the model the cost of a production network can dominate the infrastructure budget.
What about QA and Production Patch Environments? QA environments fall in between development environments and staging environments. Some QA environments require redundancy as systems move closer to a production release, but most QA environments can look more like Development environments. Production patch environments are a step below staging environments, but they are essential for mission-critical software applications. We assign a cost of $40k/year to each.
Accounting for All Environments Cost
Taking the model shown above, here are some simplifications that will help us model the costs of environments for a complex software project.
Development Environments = $25k / year
QA Environments = $40k / year
Staging Environments = $100k / year
Production Environments = $1.5m / year
Production Patch Environment = $40k / year
Back to our model of an organization releasing software in parallel. Assume that a project supports four development teams working on two parallel releases. Each team requires a dedicated development environment and each release train requires dedicated QA and Staging infrastructure.
Development Environments: 4
QA Environments: 2
Staging Environments: 2
Production Environment: 1
Production Patch Environment: 1
This organization would be spending $1.5 million per year on a production network and $420,000 per year on all other environments combined.
Environment Cost: It All Adds Up
This simple model illustrates the fact that the cost of non-production environments can be a significant factor in your IT budget. If you don’t plan appropriately and model your environment requirements and allocation needs in advance with Plutora you’ll end up surprising the business with six-figure budget requests.In the next post, I’m going to write about some of the factors that drive these costs higher. One such factor which can easily be avoided with Plutora is unclaimed environments. In this model, we have 10 environments, but when an organization manages 30-40 environments it is very common that entire departments are allocated environments that are forgotten or abandoned for months or years.
Download our free eBook
Mastering Software Delivery with Value Stream Management
Discover how to optimize your software delivery with our comprehensive eBook on Value Stream Management (VSM). Learn how top organizations streamline pipelines, enhance quality, and accelerate delivery.