Ephemeral Environments: A Getting Started Guide

Software development teams have traditionally used persistent staging environments for testing and safe experimentation. However, the downside of shared persistent environments has become clearer in recent years, including configuration inconsistencies and delays when used across multiple teams.

In contrast, ephemeral environments allow development teams to deploy numerous isolated, short-lived preview environments quickly. They replicate the entire production stack—from the front-end and back-end to the database, integrate with continuous delivery pipelines—and are automatically removed once they are no longer needed.

In this article, we explore the challenges and benefits of ephemeral environments, provide instructions for creating an ephemeral environment of your own, and present an environment-as-a-service solution that can save time and effort.

Summary of key concepts related to ephemeral environments

Concept	Description
The challenges of traditional environments	Traditional pre-production and staging environments require extra coordination, infrastructure, and maintenance to achieve their stated goals. Ignoring or missing this work results in inconsistent environments.
The benefits of ephemeral environments	Automated infrastructure setup, environment isolation, and ease of creation and deletion make ephemeral environments exceptionally beneficial.
How to implement an ephemeral environment	An ephemeral environment can be created easily by following a set of simple steps.
The environment-as-a-service solution	As an alternative to implementing ephemeral environments, a solution can also be purchased that saves time, provides extra features, and eliminates the trial-and-error phase of the process.

The challenges of traditional environments

Ideally, any code changes made to a codebase should be tested before they go live in a user-facing production environment. Traditionally, this has been achieved by creating multiple environments before production—such as a testing or staging environment—with the expectation that the staging environment is identical to production and well-tested before going live. However, in practice, this can take a lot of work to achieve and often be impractical for various reasons.

Infrastructure overhead

Since the staging environment should resemble the production environment as closely as possible, all infrastructure components need to be replicated for both environments as well. This translates into extra maintenance and overhead associated with frontends, backends, databases, and functioning interfaces among the components. Any infrastructure or architecture changes made to production must also be made here and can easily be forgotten or not perfectly replicated one-to-one.

There will always be a queue

With only one staging environment, every time changes are merged into a main branch; developers must wait for their “turn” before their changes are deployed to the staging environment. This can hinder the productivity and velocity of releases and sometimes even result in developers attempting to find ways around the workflow to release a new change more quickly, for example, in the case of a bug fix. These delays and possible workarounds can cause unwanted problems and result in untested changes in the long run.

Potential for “big bang” changes

In traditional workflows with staging environments, deploying changes from staging to production usually requires a separate manual step. If this step is not performed consistently after merging each branch, the staging environment can end up several commits ahead of the production environment. As a result, deploying from staging to production becomes a more extensive, riskier change because it includes multiple commits at once, increasing the chances of something breaking in production.

Higher costs

Traditional staging environments live just as long as a production environment lives, i.e., indefinitely, until a new set of changes is deployed. Longer periods without any changes mean the staging environment is still incurring costs while potentially providing no benefit to the company.

The benefits of ephemeral environments

Ephemeral environments can provide multiple advantages to organizations compared to traditional persistent environments.

Automated infrastructure

Ephemeral environments and the infrastructure that they are built upon are designed to be created and destroyed quickly. Required infrastructural elements are created on demand for each pull request and spun up based on the current production infrastructure as defined in the code without any intervention required from any DevOps or infrastructure engineers. This ensures that the environment resembles the production environment as closely as possible. Any ephemeral environment that might become corrupt, broken, or otherwise unreachable can quickly be replaced with a new one.

Complete isolation

Since every pull request will be allocated its own freshly created environment, multiple environments can be running in parallel, completely independently. This means no queue and less time that developers need to wait for their turn to deploy to a preview or test environment. Furthermore, each environment will only have changes from the single pull request running in it, meaning that manual testing can be done without any potential side effects from other new changes, and no big bang changes will be deployed to production.

Short life span

Ephemeral environments are meant to be short-lived by design, and they can be configured to exist only as long as they are needed. For example, one can be created alongside the opening of a new pull request and destroyed once the pull request has been approved and merged. This means there’s no more paying for environments that are not explicitly in use, which results in lots of cost savings in the long term.

How to implement ephemeral environments

While setting up ephemeral environments can involve an initial learning curve, their advantages typically make the time and effort invested worthwhile. In general, ephemeral environments can be implemented using the following steps:

Address prerequisites: A few different pieces of infrastructure must already exist to be able to implement ephemeral environments, so check the following:
‍
- Ensure that service instances are containerized, which allows instances to be short-lived and easily removed and recreated. A combination of Docker and Kubernetes is often used for this.
- Ensure service instances and code integration are managed via a CI/CD pipeline.
Set up all infrastructure in production using declarative infrastructure.
Create a test database with test data and generate credentials for test instances to connect.
Add declarative infrastructure with dynamic resource naming. This step is important to spin up temporary instances in aptly named namespaces with easily identifiable container names. A good idea would be to append branch names or commit numbers to a defined name for the ephemeral environments.
Add a step toward the end of the CI/CD pipeline that triggers the deployment of the aforementioned infrastructure. Ensuring the entire stack is deployed regardless of the changes made is important. This means that the front-end and back-end should always be deployed and configured to communicate with each other, even if, for instance, only a small change in the front-end was made. Furthermore, a DNS entry and URL should be generated for the deployed instance so stakeholders and developers can reach it. (Note that this should be secure and unreachable from outside traffic, which can be achieved through various networking configurations.)
Ensure that an update to the code in the pull request will result in the old ephemeral environment being removed and a new one being created or that the configuration is set up so that only the deployed instance will be replaced if the infrastructure is already up and running.
Configure ephemeral environment infrastructure to remove itself after a given amount of inactivity and add a trigger to redeploy it. This is important for scenarios where someone, for example, opens a pull request before a long weekend. The environment should not run the entire weekend, wasting money and resources while no one checks it.
Remove the step at the end of the pipeline that deploys to production or build a pause into the pipeline that stops the pipeline from deploying to production until it is manually triggered.
Add a manual trigger that stakeholders and developers can activate to unpause the pipeline or set off a deployment to the production environment, depending on what was done in step 8. This step should also remove the generated ephemeral environment.

These steps are generally required to set up ephemeral environments, although they may not fully represent the effort required since the workflow is simplified.

The environment-as-a-service solution

Those who may be inexperienced or would prefer not to put in the effort to set up the infrastructure required for ephemeral environments but are still interested in the benefits can take advantage of an environment-as-a-service solution.

Some vendors provide solutions that can save a large amount of time and effort for a small fee. Some of the most complex aspects of setting up ephemeral environments are handled by these vendors, allowing development teams to focus on business-related tasks rather than dealing with infrastructure or configuration concerns.

Some of the key features that can be expected from an EaaS solution are the following:

Variables: Built-in infrastructure for adding secrets and defining their scopes within an environment allows for easier integration with newer services.
Cloud provider integration and cost management: Out-of-the-box cloud provider integration abstracts the complexity of the ephemeral environment setup away from developers. It also allows for environments to be spun down after a configured amount of time, saving money and resources when they are not being used.
DNS and domain handling: Many vendors will handle the URL generation for preview environments, allowing users to serve preview environments under a custom domain.
Integration with version control systems: Automatically generated comments on pull requests allow for quickly navigating to spun-up environments with the correctly deployed version.
Turnkey integration testing: Streamline and accelerate testing with a solution that seamlessly automates integration tests with your development workflow, ensuring reliable and stable applications without requiring an extensive manual setup.

Coherence offers a platform-as-a-service solution that greatly simplifies the steps required to create ephemeral or preview environments by using preset integrations and automation.

Coherence not only offers all of the features mentioned above, it also integrates with both AWS and GCP, so you can create ephemeral environments in your existing cloud accounts. The architecture is set up slightly differently depending on the cloud provider. In general, a VPC, load balancer, and caching service can be shared across applications, while components such as storage buckets or databases can be defined and deployed on a per-environment basis.

While previews can be created and destroyed automatically based on configurations, Coherence also provides users with an overview of all existing preview environments and the functionality to manage these previews in an easy-to-use UI. Environments are also defined in lifecycles, moving from “active” to “paused” and finally to “archived” based on the configuration and current usage of the environments. Those interested in adapting Coherence for their systems can find more information at Coherence and can even ask for support with migration.

Last thoughts

As companies continue to look for ways to stand out from the crowd and development teams look for opportunities to ensure that new code changes do not create any downtime, ephemeral environments represent a significant improvement in development processes and a massive opportunity for teams to take advantage of its many benefits. They enable a transition from the pain of waiting in line in the staging environment and managing discrepancies with the production environment to having a fresh preview environment whenever one is needed and never needing to spend any effort managing the lifecycle. Teams can look forward to these benefits when adapting ephemeral environments into their processes.