Why Should You Adopt Ephemeral Environments?

The use of containerized environments has improved the software delivery cycle significantly. As a result, most teams using these environments can have multiple variants, such as the local or dev environment, sandbox environment, staging or test environment, production environment, and so on, depending on what the stakeholders or the software demands. Each environment serves a unique purpose and helps the team deliver a solid product. 

Traditionally, an engineering organization works in this way: developers do their work on their local machines (whether the environment is containerized or not), and for testing and showcasing purposes, you typically have a testing environment for internal QA, a staging environment for feature showcases or customer UAT, and a production environment that is often containerized and distributed (e.g., using Kubernetes).

To scale this approach, at least the staging and testing environments must be replicated for each team developing new features and fixing bugs. This helps mitigate the risk of dependency issues in the development process (e.g., Team A developing Feature A can’t deploy and test it in the same environment where Team B is testing Feature B without causing potential conflicts). However, this process is slow and leads to high costs in managing these long-lived environments.

The solution to these limitations is using ephemeral environments. By integrating Platform Engineering (PE) practices and ephemeral environments, the platform team can prepare standard container images with all the necessary dependencies (libraries and packages) and can then replace long-lived environments with ephemeral ones. This allows the team to work without issues and further streamlines the development experience.

The organization can then replace long-lived environments with ephemeral ones, setting up delivery pipelines as follows: A team pushes a new feature, and then when the Pull Request (PR) is opened, an ephemeral environment is created. Integration tests and other necessary checks are performed in this isolated, purpose-driven environment. Once the feature is validated and the PR is closed, the ephemeral environment is gracefully terminated. This approach speeds up the SDLC (Software Development Lifecycle) and cuts infrastructure costs.

There are other ways in which using traditional long-lived environments can affect the software development lifecycle; here are a few examples.

Example 1 – A team member pushes a critical feature that works flawlessly in development but fails during deployment due to a dependency mismatch. Trying to find the issue delays the product release, frustrating developers and stakeholders. 

Example 2 – The team needs to quickly demonstrate new features to stakeholders or the Quality Assurance (QA) team. Setting up demo environments is time-consuming and resource-heavy. 

Example 3 – The team manages numerous microservices, and QA must validate them under various production-like conditions. This requires manual setup, which is error-prone and labor-intensive.

To mitigate these limitations, one of the best approaches is using ephemeral environments.

What are ephemeral environments, and why do they matter?

Ephemeral environments are short-lived, on-demand, temporary environments with the configurations and resources of your desired environment. These environments are exact replicas of specific environments, such as the production or test environments, and can be created when needed for testing, shared for reviews, and dismantled once the task is complete. 

With ephemeral environments, developers and quality assurance teams can test and experiment with features independently, without the constraints of traditional environments. This approach helps simplify the process and prevent delays.

When integrated into a GitOps workflow, developers can easily and automatically spin up these environments to serve as a ground for reviews based on a particular Git flow, branch, or pull request. Once the Git action (the branch is merged, or PRs are closed or merged) is completed, the environment can be easily destroyed, ensuring that cloud resources are used efficiently and keeping the development process agile.

Ephemeral environments and GitOps are closely related as both emphasize automation and consistency in software development. GitOps uses Git repositories to define the desired state of infrastructure and applications, enabling automated provisioning of ephemeral environments for testing code changes. This ensures that environments are consistent with production, isolates development efforts, allows for easy version control and rollbacks, and enhances collaboration among team members. Together, they streamline the CI/CD pipeline, promoting faster and more reliable deployments.

Ephemeral environments fit into Continuous Integration and Continuous Delivery (CI/CD) by providing temporary, isolated environments for testing code changes. 

In an ideal CI workflow, an ephemeral environment could be generated for PRs. However, because this can be resource-intensive, many teams adopt a mixed strategy, creating ephemeral environments selectively, such as for feature branches or only on merges, balancing feedback needs with infrastructure capacity.

In CD, they enable teams to deploy and test features in a production-like setting before merging or releasing to production. This integration enhances speed, reduces conflicts, and ensures consistent and reliable deployment processes.

There are several benefits your team can gain from using ephemeral environments. Let’s explore a few.

Technical benefits of ephemeral environments

Using ephemeral environments throughout the development process enables your team to work in a more efficient way. Here are some of the key benefits they offer:

Cost and environmental efficiency: Since ephemeral environments only exist for a limited time span—such as a test, build, or deployment—they do not consume resources when not in use, leading to cost savings and environmental benefits. Because cloud providers often bill based on usage, ephemeral environments can help optimize infrastructure costs. Additionally, by reducing resource consumption, ephemeral environments contribute to a lower carbon footprint, aligning with GreenOps principles to create more sustainable cloud operations.

Enhanced troubleshooting and debugging: With the ability to easily replicate production environments, ephemeral setups make debugging more efficient. Developers can recreate an environment with the exact configuration where a bug occurred, allowing for more accurate troubleshooting without disrupting the main development workflow.

“When developing software, bugs are an eventuality. We use ephemeral environments to isolate their blast radius.”
David Aronchick –  Co-founder at Hack

Supports parallel development: Multiple development and operations teams can work on different features or branches simultaneously, each within their own isolated environments. This reduces bottlenecks and enables parallel workflows without the fear of environmental conflicts, ensuring faster delivery cycles.

Experimentation and prototyping: While CI/CD pipelines enable continuous integration and deployment of code, ephemeral environments take this a step further by providing isolated, temporary spaces for rapid experimentation, A/B testing, and prototyping of new features. These environments can be spun up to test ideas, validate assumptions, or integrate new tools without impacting the main CI/CD workflows or live systems. If an experiment fails, ephemeral environments can be safely discarded, ensuring resources are reclaimed without disrupting the broader development process.

According to Stu Cairns, Head of Engineering for Health and Disability, “The short-lived nature of ephemeral environments creates huge possibilities for user research. Instead of having prototypes done in isolation, we can now alter a user journey, put it out in a non-production environment, and conduct user research against it.”

Consistency across environments: Being dynamically created from predefined infrastructure and application configurations, Ephemeral environments help ensure consistency across development, testing, and production stages. By automatically provisioning environments for each task (such as testing or deployment), they mitigate issues like ‘it works on my machine,’ providing consistent environments without manual setup or configuration discrepancies.

Advanced security/performance testing: Ephemeral environments can be used to conduct performance testing and advanced security testing, such as penetration testing and vulnerability scanning, in a controlled and isolated setup. By creating environments that mirror production, your platform teams can simulate attacks and identify weaknesses without risking the integrity of the live system. This setup allows for comprehensive security and performance assessments and the ability to test remediation measures immediately. Once testing is complete, you can quickly dismantle the ephemeral environments, eliminating potential lingering vulnerabilities and ensuring that resources are only used when necessary, maintaining a secure and optimized development lifecycle.

There are several other benefits you can get based on the type of ephemeral environment you wish to integrate into your workflow. Let’s take a look at some common types of ephemeral environments.

Environment-based vs. Branch-based ephemeral environments

Ephemeral environments are designed to be fast, disposable, and useful for specific workflows. Two common types are Environment-Based and Branch-Based ephemeral environments. While both serve the purpose of quickly setting up testing environments, the difference comes down to how and when they’re used.

Environment-Based ephemeral environments

With this approach, environments are created based on specific stages in your software development lifecycle, like development, staging, or production. The idea is to replicate these stages’ environments as closely as possible, providing a reliable testbed with all its dependencies to run the code.

Why it works: The main goal here is to keep the environment in sync with the production stage you’re working on. So, if you’re developing a feature for production, you can test it in an environment that looks and behaves just like production. These environments are usually reusable, meaning different teams or developers can test their work without spinning up separate environments for each task.

Key factors to note

• Environment parity: You get a near-perfect replica of the stage you’re working on, reducing surprises in production.
• Shared use: These environments can handle tests for different features or changes, so multiple teams can use them without stepping on each other’s toes.
• Versioned configurations: Paired with Infrastructure as Code (IaC), these environments are created using predefined templates, keeping things consistent.

When to use it: This setup shines during QA testing, load testing, or when validating changes before a major release. If your team needs a reliable test environment that mirrors production, this is the way to go.

Branch-Based ephemeral environments

This approach ties environments directly to branches in version control. Whenever a new branch or pull request (PR) is created, an environment is spun up that includes the changes in that branch. Once the PR is merged or closed, the environment is automatically destroyed.

Why it’s useful: Each branch or feature gets its own isolated environment, so you can test changes without worrying about interfering with other developers’ work. These environments are created automatically and disappear once the branch is done, making them ideal for quick tests and faster feedback. These environments require many resources in large projects and can become difficult to manage if not well-controlled. The most used approach is the PR ephemeral environments.

Key factors to note

• Feature Isolation: Each branch gets its own environment, which means you can test things without affecting the main codebase.
• Automation: Tools like Jenkins or GitHub Actions can spin up and tear down environments specifically triggered by the creation and closure of branches or pull requests.
• Immediate feedback: Developers and reviewers get a live environment to play with, speeding up testing and approval.

When to use it: A branch-based ephemeral environment should be used when you want to test new features, bug fixes, or other changes in isolation before merging them into the main codebase. This allows you to ensure that the changes work as expected and do not introduce new issues. It is particularly useful for continuous integration and continuous deployment workflows, as it provides a consistent and reproducible environment for each branch.

Creating ephemeral environments in Kubernetes (K8s)

Ephemeral environments work best with container-based workflows, as these workflows enable bundling applications with their dependencies. Container orchestration tools like Kubernetes have become popular for managing application containers, offering solutions for scaling, deployment, and maintenance. Kubernetes allows for the creation of ephemeral environments due to how it works underneath. 

By virtue of its declarative approach, you could use it in conjunction with your GitOps workflow using tools like Argo CD and GitHub Actions to automate environment creation and deletion, ensuring that your environments are consistent and easily reproducible directly from your Git repository.

Let’s briefly look at the process of setting up ephemeral environments in Kubernetes and how to automate the process using GitOps with GitHub.

Setting up ephemeral environments in Kubernetes

To set up ephemeral environments, start by preparing your Kubernetes cluster and defining how your application should be deployed. Each pull request or branch can trigger the creation of a new environment, which is isolated within its own namespace. 

Once deployment has served its purpose, Kubernetes allows you to clean up the environment automatically, ensuring no resources are wasted. 

Here’s how you can do this:

•  Prepare Kubernetes Cluster: You’ll need a Kubernetes cluster, either on a cloud provider (e.g., GKE, EKS, AKS) or locally (e.g., Minikube, Kind). Make sure you configure access with a kubeconfig file, as this is what your automation system will use to interact with the cluster.
• Create Application Configuration: Define your application’s infrastructure and deployment settings in Kubernetes YAML manifest files. These files will describe resources such as deployments, services, and ingresses. Include placeholders for dynamic values, such as namespace or application name, to customize the environment for each pull request.
• Define Namespace Management: Namespaces in Kubernetes allow you to isolate resources for different environments. For ephemeral environments, you’ll create a namespace dynamically for each pull request. This prevents conflicts between environments and ensures complete isolation.
• Set Up CI/CD System: To automate the creation and deletion of these environments, you’ll use a CI/CD system like GitHub Actions. It will trigger workflows when you open or update a pull request.

How to Set Up Ephemeral Environments on GitHub (GitOps)

You can automate the creation and teardown of these environments using GitOps. To do this, you‘ll need to combine ArgoCD and GitHub Actions. 

Argo CD ensures the Kubernetes cluster stays in sync with the desired state defined in the Git repository (the repository housing the Kubernetes configurations), automatically deploying and updating resources for the ephemeral environment. GitHub Actions handles event-driven automation by triggering workflows when a pull request is opened, merged, or closed. It dynamically manages tasks like creating namespaces, injecting PR-specific configurations, and cleaning up resources.

Here’s the overall workflow:

1. Monitor GitHub Repository: Argo CD is configured to track changes in your GitHub repository. It applies changes automatically when a new Pull Request (PR) is opened.
2. PR Event Triggers Deployment: A GitHub Action runs whenever a PR is opened. It creates a namespace in Kubernetes specific to the PR and deploys the application and its related configurations to this namespace.
3. Teardown: When the PR is merged or closed the environment and its namespace are cleaned up.

Now, every time you open a PR, a new namespace and ephemeral environment are created in Kubernetes. This ensures isolated environments for each feature branch. When the PR is merged or closed, the environment is automatically torn down.

Common challenges when transitioning from traditional long-lived environments to ephemeral environments

You can encounter the following common challenges when moving from traditional environments to ephemeral environments.

• The complexity of setup: Shifting from traditional, long-lived infrastructure to ephemeral environments often requires significant changes in tools, workflows, and expertise. The initial setup can be complex, with a steep learning curve for teams unfamiliar with the necessary tools.
• Resource Management: Ephemeral environments can be resource-intensive, requiring robust cloud provisioning strategies to avoid overuse or costs.
• State Persistence: Managing data persistence in short-lived environments, especially for tests requiring databases or stateful services, which can be challenging.
• Compatibility with Legacy Systems: Integrating ephemeral environments into existing workflows can be difficult when dealing with legacy systems that may not support modern containerization or cloud-native approaches.
• Transition Costs: Migrating to ephemeral environments involves not only technical adjustments but also potential disruptions to current workflows and team productivity, increasing the overall transition cost.

Ways to mitigate these challenges

To mitigate against these challenges, Luca Cruciani mentioned using tools and services such as;

• Automation Tools: Leveraging Infrastructure as Code (IaC) tools like Terraform or Kubernetes can help automate and simplify the environment setup process. 
• Cost Monitoring: Implementing proper resource monitoring to track resource usage and associated costs.
• Auto-scaling Policies: Setting up auto-scaling policies to manage resources efficiently and reduce costs.”
• Stateless Services: Using mock services, pre-seeded databases, or versioned data snapshots to address state persistence issues. 
• Internal Developer Portals could be a valid solution; they are user-friendly interfaces that connect developers to internal platforms, allowing them to access tools in a simplified manner, reducing cognitive load, and enabling self-service autonomy. Ephemeral environments can be integrated into these portals through: 
  • • • Direct triggering of environment setups with pre-configured settings. 
      • Monitoring of environments to adjust resources based on demand, minimizing waste.
      • Integration with CI/CD pipelines for automated testing and deployments. 
      • Management of access to ensure only authorized users can create or interact with the environments, maintaining security and governance standards.

Key takeaways

Environments are essential to the development lifecycle, providing spaces for testing, staging, and deploying software. However, relying on traditional environments often introduces bottlenecks, slowing progress and driving up costs due to resource constraints. Ephemeral environments, on the other hand, offer a dynamic, scalable, and cost-effective solution, enabling efficient testing, quick development, and deployment cycles while integrating seamlessly into CI/CD pipelines.

By enabling your development team to spin up and tear down environments on demand, this approach ensures consistency across development stages, reduces infrastructure costs, and accelerates the pace of delivery. Mia-Platform provides a simplified approach to implementing these ephemeral environments.

To see how easily you can implement ephemeral environments in your workflow, check out Mia-Platform’s comprehensive documentation that guides you through the process.