Improve Developer Experience with Specialized Environments
An overview of different types of developer environments with their usage and considerations.
Rohit Raveendran
March 1, 2022
table of contents
SHARE
Non-production environments are critical for a Development team’s ability to ship stable software. In our conversations with over 200 enterprises, most have non-production environments like Quality, Integration environment, pre-prod environment but rarely do they have Developer Playground Environments.
Developers/teams need reliable end-to-end testing capabilities for their experiments without interfering with shared environments like Integration and Quality environments.
Most developers set up the dev playground in their local environment with necessary components and mocking what is optional. However, this solution may not be practical for everyone depending on the size and complexity of the applications.
Let us first look at what the developers need and what is the cost to the organization if they don’t deploy dev-environments. Then we present four ways of deploying dev-environments. We will break down the costs, benefits, limitations and usage scenarios for each of these methods of deployment.
What The Developers Need :
Looking deeper into our conversations with tech teams, many wanted a dev playground, feature-centric environments before their code hits the first shared environment, which is usually integration or Quality environment. The broad level of conversation can be categorized into two types of asks
• Per Developer / Team environments: Developers should have their own sandbox to test their features. This would give them the flexibility to come up with quick iterations of new and experimental features.
• Per Feature environments: Developers wanted additional environments built for specific features that are work-in-progress and need to be tested in parallel.
Cost to the Organisation
Organisations shy away from additional environments for two primary reasons. One is the increased burden on the DevOps team to manage and support each environment. The other is the Cloud costs that can quickly escalate if environments are created indiscriminately.
However, by not enabling developers, they incur costs in a different way:
• Unstable Integration Environments: If developers are not able to run basic checks, then issues creep into Integration, QA, and Staging environments and waste everyone's time.
• Low Developer Productivity: The feedback loop for developers becomes longer. Delayed discovery of issues interrupts the next feature development.
• Higher Lead Time: Integration environment availability becomes a blocker. These factors slow down the pace of releases and increase the lead time.
Various Developer Environments Options
Though the above-mentioned issues are common, organisations can still find specific solutions to mitigate them and reduce the costs. Broadly they can mix and match to create dev-environments from the following options.
1. Shared Developer Environment with Telepresence
The simplest solution is a common/shared cloud-based environment for all developers, where developers can test as they code. Using Telepresence, a developer working on a service can intercept the traffic on the shared cloud environment and direct it to their local version. This gives fast access to the environment allowing developers to edit and deploy their code without going through an entire CI pipeline.
When to use :
Apt for debugging integration issues and rolling out patches since developers do not need to run dependencies in the local for their development.
Considerations :
• Difficult to test entire feature overhauls that might have backward incompatible changes.
• Cloud costs are manageable as a single integration environment is serving multiple developers.
2. Multiple Isolated Environments
For entire feature overhauls, multiple isolated environments can be used where each developer (or a small feature team) can spin up their own environment in the cloud, including their own services, resources, etc. This allows for fully isolated and parallel testing of features before making them mainstream.
When to use :
Parallel testing of large/complex feature rollouts.
Considerations :
Your developer should have the ability toselect a subset of services that they require and spin-up ephemeral environments.
Multiple environments might lead to cost leakage.
3. Local Environments
Each developer creates a Production-like local environment on their system (laptop/desktop) using some deployment mechanisms or a prepared Vagrant box. Kubernetes have made the local setups easier for services. However, required services with their databases/schema, etc are to be bundled together to make it functional. The cloud services which can't be bundled together are needed to be mocked or can be used from the cloud, remotely. (lyft-in-a-box) discussed this in detail.
When to use :
Preferably in the beginning stage when services are less in numbers and databases are simpler
Considerations :
• Local development is difficult to set up and provides a better development experience
• Resource constraints on the local box can become counter-productive.
• The biggest issue would be that the Local Environments will drift from the cloud environments with changes propagating in the CI environments. So the local environments have to be kept refreshed from time to time.
4 . Partially Isolated Environments :
This again is a shared cloud environment solution, but it allows for multiple versions of service using request-header manipulation tools like Envoy. A sidecar pattern is used to offload the required service, say S2. The usual requests and responses to the offloaded service are routed away from it and it is undiscoverable until it is ready. Thus other developers working in parallel do not get affected.
When to Use :
This is useful for testing stateless micro-services as they are worked on by multiple developers.
Considerations :
• Header-based routing needs to be propagated throughout the system, leading to complexity in implementation.
• This Doesn't work for all types of services -. For e.g., if the service uses shared resources like common queues in the environment as multiple versions of services will read from it, it will lead to unpredictable outcomes. In some scenarios, cache needs to be invalidated.
Conclusion :
Developer Environment Comparison
A summary/comparison of the methods is provided in the table. They have their own limitations, cost, and benefits. Speak to your developers and observe the bottlenecks in your SDLC. Understand your architectural patterns and decide on a way to provide developers with an environment as a sandbox.
"With Facets, our staging environments look identical to production environments. So in case of production issues, we can be sure there are no infra drifts."
Kadam Jeet Jain, Co-Founder & CTO, Treebo Hotels and Hotel Superhero.
GGX switched from AWS to GCP in 2 weeks
"Facets has radically changed our DevOps for the better. They did all the heavy lifting and saved us precious time and resources in our when we switched from AWS to GCP."
Kaustubh Bhoyar, Head of engineering, GGX
Trusted by companies to run production at scale
Request a Quote
Let us know if you have any additional queries, we'll get back to you soon.
Capillary reduced ops tickets by 95%
“Our releases are fast. And with less developer time needed our teams can focus on building exciting features. We’ve saved countless hours and costs.”
"With Facets, our staging environments look identical to production environments. So in case of production issues, we can be sure there are no infra drifts."
Kadam Jeet Jain, Co-Founder & CTO, Treebo Hotels and Hotel Superhero.
GGX switched from AWS to GCP in 2 weeks
"Facets has radically changed our DevOps for the better. They did all the heavy lifting and saved us precious time and resources in our when we switched from AWS to GCP."
Kaustubh Bhoyar, Head of engineering, GGX
Trusted by companies to run production at scale
Get in touch with us
Tell us your queries and we’ll get back to you
Prefer email? Reach out to us at info@facets.cloud