Microservice Testing & Inner Dev Loops in Kubernetes
Preview Microservice Changes Locally and Minimize Dev Environment Costs with Service Preview
How do you set up a product development environment for microservices and Kubernetes?
Talking to several developers, we identified four approaches that organizations currently take when setting up environments for microservice development and five tradeoffs to consider when choosing a strategy. In this article, we will review these approaches and tradeoffs, and then discuss the new Service Preview capability available in the Ambassador Edge Stack.
Tradeoffs
1. Speed of Inner Dev Loops
Autonomy, agility, fast dev cycles, full-cycle development, better products sooner. Microservices are great for minimizing OUTER development cycles and supercharging innovation, but containers, which are used to deploy microservices, introduce additional steps that slow INNER development loops. The inner development loop is the iterative process that a developer performs when they write, build, and debug code. Containers add the need to build and deploy code to the cloud, which adds minutes to a workflow that a typical developer runs 25–75 times a day.
2. Isolation of Coding Loops
If we forget about the inner dev loop delays for a moment, a shared staging environment may sound like a dream — where you can make code changes and then test them as part of the larger microservice and latest cluster. Start working on an application with a team of people, and you’ll soon start affecting each other’s work, and that dream becomes a nightmare pretty quickly.
3. Fidelity of Environment
Say you wanted to work with a few people on a document. If you’ve been using a collaborative, real-time way of working (like Google Docs) with your team to write, you can see how something your team member has written can be referenced later on in your section. You can also see if your changes affect any links your team member may have to your section. By duplicating a static development environment, you’re each essentially working offline with a downloaded version for a day or a week.
4. Maintenance Efforts/Costs
Static environments that require constant upkeep usually meaning merging changes and creating new environments regularly. With duplicated cloud environments for each developer, your development clusters’ cloud bills are going to increase quickly.
5. Scalability
With entirely local development environments, scalability becomes an issue as your application grows. Most development computers only have so much memory, and they cannot possibly host copies of all the microservices that are relevant for testing changes to your microservice. We’ve heard horror stories of computers overheating and crashing. In some cases, developers build service emulators to help. If not done well, these emulators can impact the fidelity of the environment negatively.
Approaches
With the dreaded inner dev loop delays and it being impossible to work in isolation, very few teams attempt to adopt a true container inner dev cycle (approach 1).
Most teams turn to static duplicate dev environments to solve these two problems, but they bring about additional issues. The first typical way (approach 2) is to create a duplicated environment on your local machine, test the changes locally with service emulators, and then merge changes later. Another way (approach 3) is to create duplicated clusters for each developer to use.
A new capability of the Ambassador Edge Stack, Service Preview (approach 4), allows developers to debug their application on their local computer as if it were in their cluster while examining its results.
Here is a summary of the issues with each of these three approaches:
What is Service Preview?
The Ambassador Edge Stack’s new Service Preview capabilities address the deployment and isolation problems without sacrificing the benefits of fidelity, low maintenance, scalability that a shared staging environment can provide.
Service Preview uses the fine-grained L7 routing of the Ambassador Edge Stack to enable users to send test traffic requests into the development cluster through the edge and have those requests routed to and from their local development machine. Service Preview can intercept HTTP and HTTPS traffic.
This enables developers to treat the local version of the microservice being tested as if it is in the shared cluster and test the interconnections to adjoining microservices and data stores.
With Service Preview, developers on a team can send individually identifiable test traffic to test changes in the microservice they are working on without affecting the work of others.
By testing microservices locally, developers can code and test while avoiding the time-consuming build, push, and deployment to Kubernetes with every cycle. By routing test versions of live traffic requests to the local copy of the microservice being tested and treating the microservice as part of the live cluster, developers can more efficiently test their microservice and all of its connections.
Service Preview vs Telepresence
Service Preview is powered by Telepresence, an open-source tool developed by Ambassador and now a CNCF sandbox project. Telepresence.io
Telepresence alone works for small teams with one person making changes to the shared dev environment. Utilizing the power for fine-grained layer 7 controls of the Ambassador Edge Stack, Service Preview is ideal for larger teams and allows for multiple people to work in a shared environment.
Learn More About Service Preview
Visit the Ambassador website. Watch Daniel Bryant’s Demo: https://youtu.be/LDiyKOa1V_A
