Datawire, provider of the Kubernetes-native API gateway, Ambassador, has released a new version of Ambassador Edge Stack designed to accelerate the inner development loop. The new Service Preview capability uses Layer 7 (L7) control to allow multiple developers to code locally and preview changes remotely as if the changes were part of the live cluster.
Service Preview addresses deployment and isolation problems by enabling developers to debug their application on their local computer as if it were in their cluster. It uses the 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. This enables developers to treat the local version of the microservice they are testing as if it is in the shared cluster, and test the interconnections to adjoining microservices and data stores. Additionally, developers on a team can send individually identifiable test traffic to test changes on the microservice they are working on without affecting the work of others.
By testing microservices locally, developers can code and iterate their solution while avoiding the time-consuming build, push, and deployment to a remote Kubernetes cluster 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.
Ambassador Edge Stack's Service Preview capability leverages parts of Telepresence, an open-source project created by Datawire and now a Cloud Native Computing Foundation (CNCF) sandbox project.
InfoQ asked Datawire CEO, Richard Li, some questions about the new release:
InfoQ: How can Ambassador Edge Stack support teams rearchitecting applications into microservices?
Richard Li: Moving from monolithic applications to microservices means that the overall system is now composed of more components. Each service often depends on many other services i.e. it has more dependencies. The process of testing modifications in each service, and the impact it will have on its dependencies, before deploying the service to production is quite challenging.
Microservices development therefore often introduces a centralised staging environment for testing. This has many benefits, but lengthens the inner development loop and does not allow for isolated viewing and testing of changes. To overcome this, most organizations clone their clusters in the cloud or create duplicate versions locally so that developers can independently test their microservices. When organisations clone in the cloud there is a risk that costs can increase exponentially.
Ambassador Edge Stack aims to reduce the costs by eliminating the overhead and maintenance needed to duplicate these environments.
InfoQ: How does a developer using Ambassador Edge Stack compare to a developer using feature branching?
Li: Use of the Ambassador Edge Stack and Service Preview functionality is somewhat agnostic to the development branching strategy, in that teams can use their preferred approach to building features, merging code, and releasing. Having said this, the Service Preview functionality does assist with the adoption of modern branching best practices, such as trunk-based development, as developers can work from the same branch but preview their changes in isolation within a production-like environment.
InfoQ: Why is it that containers optimise developer experience for inner loops and microservices outer loops?
Li: The outer development loop involves the coding and release of production-ready changes that impact end users. Moving from monolithic applications to microservices enables smaller teams to own services/product and independently release iterations on a more frequent basis. Rather than being saddled with orchestrated release cycles spanning weeks or months, microservice teams have the agility and speed they need to swiftly respond to the needs of their users.
The inner development loop is the iterative process of writing, building and debugging code that a single developer performs before sharing the code with their team. These inner development loops are completed much more frequently than outer development loops.
Containers, which have become the de facto unit of deployment in cloud systems, introduce a container image build, upload and deploy tax within each development loop. This is a larger problem for inner development loops because every developer runs these multiple times each a day, in comparison with, say, once a day for an outer loop build and release.
InfoQ: Is there a case for developing in the cloud rather than on local machines?
Li: It is really a matter of both organisational preference and cost. Larger applications are almost always going to be in the cloud since they are too large to replicate down to someone's desktop. That is exactly the problem we are helping to solve. We talk to people who ask for '64 core' desktops since they need to develop, and they can't fit their app on their desktop. The ops team is forced to give everyone their own cloud copy which just drives the cloud bill up. Good for the cloud provider, bad for the development team.
Additionally, the overhead of maintaining the individual cloud environments introduces a headache for many teams, especially as the application and teams grow in complexity and size. With Service Preview, teams can keep their shared development cluster in the cloud, but make a local copy of the microservice for development, then route the identifiable test traffic to a local copy. This allows developers to test changes locally as if they are in the shared dev cluster without affecting the work of their peers.
Additionally, using Service Preview allows developers to use the tools and workflows that they prefer. Many debuggers and IDEs have been created for cloud use, but do not compare favourably to the tried-and-tested tools that can be installed locally on development machines.
To view a demonstration of Ambassador Edge Stack Service Preview, please visit here.
