Developers creating microservices face a common challenge related to the design-code-test cycle: integration testing against other services during development. For example, engineers are often forced to create (potentially brittle and unrealistic) mocks, or try to spin up a full stack locally. The new Service Preview feature of Ambassador Pro, built on the Telepresence local-to-remote Kubernetes project, aims to help developers solve this problem, accelerating their design-code-test cycle.

Current Microservice Development Challenges

Imagine Jane Developer is coding an API service on her laptop. The service consumes data from several other backend services. Jane wants to integration test her code changes with the backend services. In a traditional development environment, Jane has the following options:

Test locally. Jane can set up all the backend services locally. This makes her local development environment more complex, and ensures that her environment is up-to-date without the maintenance headache of constantly updating services. Moreover, if her backend services require significant memory/CPU, this option might not be practical. Test on a remote Kubernetes cluster. Jane can deploy all the services remotely. This makes testing more cumbersome, since she has to commit her code and wait for her CI system to build and deploy a new Docker image to the cluster. Moreover, Jane must maintain her own private cluster (or namespace) for testing purposes, since other developers won’t want to see her changes as well.

Introducing Service Preview

Today, we’re introducing Service Preview as part of Ambassador Pro. With Service Preview, Jane has a faster, easier option. In this model, Jane (and the other engineers on her team) use a shared environment such as staging. Requests from Jane are routed to Jane’s laptop, so Jane can Preview these changes. Importantly, requests from other engineers do not get routed to her laptop, and instead get routed to the stable version of Jane’s service running in the staging environment.

Thus, Jane’s development workflow becomes:

Run service locally on her laptop in a development environment, making changes using her favorite IDE. Before committing, run Service Preview to see these changes with the other services that Jane’s service depends on. These other services are deployed in a shared environment, e.g., staging. Jane can send test requests to Ambassador, which will dynamically route her requests (and just her requests) to her laptop via Telepresence. Other users will not see any of her changes. Once satisfied with her changes, Jane commits her code and allows CI to deploy these changes for everyone else to see.

Why Service Preview?

We built Service Preview to give application developers the best of both local and cloud development. Service Preview is not a replacement for CI/CD — instead, it helps accelerate the “inner loop” of development (if you’re interested in more context, Phil Lombardi gave a talk on this at KubeCon NA 2018).

You get the benefits of local development: use your preferred IDE, fast iterative feedback, hot reload. You get the benefits of cloud development: unlimited compute/memory, a realistic test environment. Your organization can adopt a shared development / integration test environment, where every developer is able to test against everyone else’s latest service versions. This can also reduce the costs of maintaining development infrastructure for your engineering team.

This last point is perhaps the greatest benefit we see in adopting Service Preview across your team. In a microservices application, services are being continuously deployed, resulting in an application that is a constantly moving target. With Service Preview, developers can test against the latest versions of everyone else’s services in a single shared environment.

Getting Started

Service Preview is in beta, and one of the core features in Ambassador Pro, along with Single Sign-On and rate limiting. To get started, sign up for a free trial and check out the Service Preview Tutorial.