News
Bridge to Kubernetes Simplifies Microservice Development in Visual Studio/VS Code
New Bridge to Kubernetes extensions available for Visual Studio and VS Code simplify microservice development by bridging a local dev machine to specific dependencies in remote clusters.
Bridge to Kubernetes reached general availability last month and was featured in Microsoft's online Ignite 2020 developer/IT pro conference.
The goal is to help Visual Studio and VS Code developers to create microservice apps faster, including debugging and end-to-end testing.
"Bridge to Kubernetes extends the Kubernetes perimeter to your development workstation, allowing you to sidestep operational complexities of building and deploying your code into the cluster to test, debug and rapidly iterate," said Microsoft's Nick Greenfield, program manager, in a blog post announcing the project's move to general availability.
Greenfield also last week appeared in a Visual Studio Toolbox video on the company's Channel 9 site to further describe the project.
"Bridge to Kubernetes is an iterative development tool for developers that are authoring microservice applications that target Kubernetes," he said. "It's offered as a client experience in both Visual Studio and Visual Studio Code through extensions that you can pick up in the marketplace."
[Click on image for larger view.] Microservice Development Options (source: Microsoft).
Greenfield explained the project in the context of three approaches for working on a single microservice as part of a larger application, as shown in the graphic above and detailed below:
- Local: in which code on a local dev machine handles external dependencies -- such as environment variables, connection strings, volumes from a cluster and so on -- via stubs, mocks or connecting manually to dependencies actually running on the local machine. Or developers can use a system like Docker Compose to run those dependencies and containers. An advantage of that approach is speedy development loops, but a disadvantage is that the local dev machine is likely to be quite different from the environment to which the code is deployed, like Azure-hosted Kubernetes.
- Remote: in which code is developed locally but then deployed to an environment such as Azure-hosted Kubernetes for testing and debugging. While providing fidelity with the deployment environment, that approach can slow down build loops and add friction to the development workflow.
- Hybrid: this best-of-both-worlds option is where Bridge to Kubernetes lives. It allows developers to "write your code on your development workstation, but connect to external dependencies that are running in some remote environment," Greenfield said. "So I'm actually fulfilling all those external dependencies by connecting to my Kubernetes cluster -- let's say running in Azure -- so that I can leverage the whole end-to-end workflow. But the only thing I'm running on my developer workstation is the code that I'm working on."
[Click on image for larger, animated GIF view.] Bridge to Kubernetes in Animated Action (source: Microsoft).
The project's GitHub page says:
Bridge to Kubernetes extends the Kubernetes perimeter to your development computer allowing you to write, test, and debug microservice code while connected to your Kubernetes cluster with the rest of your application or services. With this workflow, there is no need for extra assets, such as a Dockerfile or Kubernetes manifests. You can simply run your code natively on your development workstation while connected to the Kubernetes cluster, allowing you to test your code changes in the context of the larger application.
The page lists key features including:
- Simplifying microservice development by eliminating the need to manually source, configure and compile external dependencies on a development computer.
- Easy debugging as developers can run their usual debug profiles with the added cluster configuration, debugging as usual while taking advantage of the speed and flexibility of local debugging.
- Developing and testing end-to-end during development time. Developers can select an existing service in the cluster to route to a development machine where an instance of that service is running locally. A request generated by the front end of an application running in Kubernetes will route between services running in the cluster until the specified service to redirect is called.
As noted, Bridge to Kubernetes provides a client experience with extensions for the Visual Studio IDE and the open source, cross-platform VS Code editor available in their respective marketplaces.
Of the two, the VS Code tool is getting more traction, boasting 30,100 installations at the time of this writing, compared to 1,934 for the Visual Studio IDE extension.
In response to a developer's question voiced in a comment on his blog post, Greenfield noted that the VS Code extension isn't tied to any one programming language or to .NET, specifically confirming that it can be used to debug Node apps.
In response to another question, he said, "At the moment, Bridge to Kubernetes is limited to .NET Core targeting Linux containers. We are working through supporting Windows containers and will hopefully have a preview available in the next few months."
Yet another question asked how Bridge to Kubernetes compared to Azure Dev Spaces. The two offerings do indeed appear to be similar, as Microsoft documentation for Azure Dev Spaces says: "Azure Dev Spaces is an extension to AKS [Azure Kubernetes Service] that allows you to easily run and debug your code in the context of a larger application. You can test your code end-to-end, hit breakpoints on code running in the cluster, and share a development cluster between team members without interference."
Here is Greenfield's answer to what he said was "a great question":
In short, Bridge to Kubernetes offers many of the key development scenarios Dev Spaces supports, but with an improved lighter weight solution.
Dev Spaces helps developers work with code running directly in their cluster, avoiding the need for replicating a local environment that closely matches the deployed environment. This approach improves certain aspects of development, such as providing high fidelity, but it also introduces a prerequisite of learning additional concepts such as Docker, Kubernetes, and Helm before starting to use Dev Spaces.
Bridge to Kubernetes reduces inner loop complexities by side-stepping the need to create Docker and Kubernetes configurations, allowing developers to focus purely on the business logic of their code. Developers can work directly on their development computer while interacting with the rest of the services running in their cluster. This approach takes advantage of the familiarity and speed of running locally, while sharing the dependencies and environment provided by their cluster. Bridge to Kubernetes also takes advantage of the fidelity and scaling that comes from running in Kubernetes.
More information is available in:
About the Author
David Ramel is an editor and writer at Converge 360.