How to build software 60% faster and 80% cheaper

Ask any established software delivery team about what’s slowing them down, and one topic that is bound to come up is “environments”. Whether there are too few of them, or they are vastly different from each other, environment-related issues tend to be the #1 cause for unexpected bottlenecks in the software delivery lifecycle of modern web applications. It is also a fact that for many teams, more than half of the total cloud spend is on testing environments. In this post we’ll present a way to overcome these challenges, and enable your software team to deliver better software, faster.

The first design principle for environments

Before we discuss on-demand environments, it’s important to understand a key principle for robust environment design in modern web applications:

Environments should be alike but share nothing.

The less differences there are between the development, testing, and production environments for your application, the more confident you will be that any testing conducted in lower stage environments will uncover any unexpected behaviour before your application reaches production.

By sharing nothing, we mean that environments should be isolated from each other. This includes databases, hosting environments, and where practical, any 3rd party dependencies. In AWS, the best practice is to host environments on separate AWS accounts. This ensures that any ongoing testing on a development or UAT environment does not affect other environments - and most importantly, the production environment.

Introduction to on-demand environments

Instead of a static list of environments, our recommendation is to build an approach for on-demand environments. In this model, testing environments are created automatically when they are required, and destroyed automatically when no longer needed.

The best benefit of on-demand environments is that your software delivery team is no longer blocked by a static number of environments to test their changes. On-demand environments can be spun up in minutes for every feature branch, enabling your team to test each change individually before combining them in an integration environment. In our experience this can provide up to a 60% reduction in time-to-market for new features.

The second-best benefit is cost savings: instead of running a high number of traditional testing environments - sometimes dozens or even hundreds - with on-demand environments, you only run the environments that are actively used. For most teams this brings immediate cost savings: if your traditional testing environments are running 24/7, it’s possible that they are actually sitting idle for 80% of the time.

How to get started

The key prerequisite for on-demand environments is environment automation with Infrastructure as Code. To enable environments to be created automatically, there can be no manual steps involved in the setup and provisioning of them. Typical tools for implementing the automation are Terraform and a configuration management tool such as Ansible.

Once the on-demand environment setup is in place, and hooked up to your application pipelines, you will need to think about data. For any testing to be effective, the data in the testing environment must be reflective of production data. In our experience, the best approach here is to build an ETL pipeline to provide an anonymised data dump that is reflective of production data, but can be used in testing environments with less data protection considerations. This is especially important for split-geography delivery teams where the data may need to be stored in a certain region, but the vast majority of development happens elsewhere with an offshore or nearshore team.

Releaseworks DevOps & cloud engineers are experts in implementing on-demand environment automation for all technology stacks. Reach out today for a no-commitment discussion to understand how we can help you.