Service Preview
Quickly test new microservices within an accelerated inner dev loop, while eliminating the need to stand up complex, costly test environments for each developer.
Watch the video of Service Preview in action
Why Service Preview? What Problem Does it Solve?
Developing and Testing Microservices Can Be Challenging
Due to the nature of microservices being a collection of connected services, developers creating microservices face the common challenge of integration testing against other dependent services during development.
Recreating the Monolith Isn't Ideal
The first way teams attempt to develop microservices is similar to the process used for monolithic applications. Individuals work on microservices locally, then commit their changes to the development environment. At some point, all the changes to all the microservices are bundled together into a release candidate which is tested. Using this approach, the nimbleness of microservice development has been erased and essentially the organization has a distributed monolith.
Mocking and Emulators are Tough to Maintain
Development teams that recognize that recreating the monolith but with microservices isn't ideal, many times attempt to move to a better model by using emulators or service virtualization/mocking. By emulating upstream and downstream services on local development machines, theoretically, microservices can be developed and tested for their interactions with neighbouring services. But in this case, the fidelity of the environment suffers greatly since mocks and emulators can only go so far. In addition, maintenance costs are high, and scalability is challenging as the need for more and more mocks increases.
Cluster Duplication Drives Up Costs
To solve some of the issues with the inner dev loop, and provide for isolated coding, duplicating the cluster for each developer is a technique pursued by many teams.
The first variant of this approach is to duplicate the cluster locally on a laptop. In this case, money is being spent with laptop manufacturers to purchase the largest laptops available. At some point, however, no laptop can be powerful enough to hold the entire application. At this point, organizations will many times replicate the dev environment in the cloud and create names spaces for one or a group of developers. This drives development costs up significantly. Worse, the environment fidelity is poor. Once the first microservice is committed to the dev cluster master, all the local copies are now out of date.
Proxies and Routing with Service Preview
Service Preview, built on the open-source Telepresence project, uses a network proxy pod in your Kubernetes development cluster to route test data for the cluster under development to your local process. A single copy of the development environment is maintained, with individual copies of a microservice under development being loaded on local machines. Using traffic routing, these local copies only see test traffic routed to them, while other developers traffic maintains its routing through the original microservice. In this manner, developers can develop and test against the most recent copy of the service without impacting other developers.
How Service Preview Works
Assume microservice 2 (MS2) is under development.
- Traffic routes live through the system before entering the microservice being developed (MS2).
- Instead of running the service in a remote cluster, traffic is routed through a proxy to the code on a local computer (MS2 Code). On the local machine, the developer hacks away at the service.
- Traffic is routed back through live system.
- Since traffic to the microservice under development is quarantined from the other traffic, work done on MS2 doesn't impact any other microservice as it travels through MS3.
- Traffic egress at the edge.
Service Preview Documentation Links
Constant container deployments complicate the inner development loop. Service Preview leverages Telepresence and the fine-grained layer 7 routings available with the Ambassador Edge Stack to accelerate the inner development loop.
Local Preview
Preview microservice changes locally as if they are in the shared dev cluster without affecting the work of their peers. Leverage your favorite local IDE and/or debugger.
Read the Docs:
Browser Link Preview
Send a browser preview link after making a change to your local microservice. The link recipient can view the change as if it is live in the cluster without having Service Preview installed or downloading a browser extension.
Read the Docs:
Next Step
Quickly test new microservices within an accelerated inner dev loop, while eliminating the need to stand up complex, costly test environments for each developer.
Start Enterprise Trial of Service PreviewGet a DemoContact Sales for a Guided Installation