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.
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.
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.
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.
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.
Apt for debugging integration issues and rolling out patches since developers do not need to run dependencies in the local for their development.
• 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.
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.
Parallel testing of large/complex feature rollouts.
Your developer should have the ability to select a subset of services that they require and spin-up ephemeral environments.
Multiple environments might lead to cost leakage.
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.
Preferably in the beginning stage when services are less in numbers and databases are simpler
• 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.
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.
This is useful for testing stateless micro-services as they are worked on by multiple developers.
• 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.
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.
Let us know if you have any additional queries, we'll get back to you soon.
Tell us your queries and we’ll get back to you
Prefer email? Reach out to us at info@facets.cloud
