Build and test microservices applications with Azure Dev Spaces

Azure’s service platform’s adoption of Kubernetes and containerschanges how you build, deploy, and manage cloud-native applications, treating containers and services as the targets of your builds, rather than the code that makes up those services.

Kubernetes itself automates much of what had been infrastructure tasks, orchestrating and managing containers. Azure’s AKS tools simplify configuring Kubernetes, but you need to deploy straight into an AKS instance—a hurdle for anyone developing new apps or handling a migration of an existing service. Although AKS itself isn’t expensive, setting up and tearing down orchestration models takes time—time that can better be spent writing and debugging code.

Introducing Azure Dev Spaces

That’s where Azure Dev Spaces comes in to play, a managed AKS instance that’s integrated with your local development tools. It’s where you can try out code, integrating it with other Azure services, and where you can collaborate with other members of your development team. With a dev space for each member of a team tied to a specific branch of a Git repository, you can work on your specific part of a service while other developers work on theirs in their own dev space, before you merge your code with pull requests and before running integration and system level tests.

It’s also a good way to start learning about container-based development. With Azure Dev Spaces, you can use tools like Helm and Brigade to quickly build the scaffolding for new apps, creating containers and the framework need to support code running in your containers. You can work with Node.js, .Net Core, or your choice of development tools—with support for both Visual Studio Code and the full Visual Studio IDE. It also simplifies set up development environments: you won’t need to have Docker or Kubernetes running on your development PC; all you need is your usual IDE with all its familiar debugging tools.

Currently available in public beta, Azure Dev Spaces is only running on a subset of the available AKS clusters, in some US Azure regions, a couple Canadian regions, and one European region. As the service heads to production release, you should see it running in more regions, but until then be ready to have a little more latency than you might normally expect. There may also be delays when setting up a dev space; for example, when configuring the public DNS for your app, which can take several minutes on first run. If you use an SSH tunnel to your space, you can access your code as if it were running on your device even though it’s on a remote container running on AKS.

Getting started with Azure Dev Spaces

To start with Azure Dev Spaces, you need to have a Kubernetes cluster enabled and running Kubernetes 1.10.3. It’s not the latest version, but it’s a good place to start. Again, expect the range of supported cluster versions to change as the service evolves—both before and after production release. The cluster also needs to support HTTP application routing, giving you access from your IDE for test and debugging.

When working with Visual Studio Code, you need to ensure you’ve installed both the Azure CLI and the Azure Dev Spaces extension for Visual Studio Code. Setting up Azure Dev Spaces requires a one-line command in the CLI, which you can access from Visual Studio Code’s built-in terminal. Microsoft provides sample code in GitHub that you can use to get started with a basic web app.

Once you have built the appropriate Docker and Helm assets for your code, you can start to edit code and any web content live in the container. By working against live Kubernetes assets, you’re avoiding the whole build/compile/deploy/test cycle. The simple azds up command handles content synchronization for HTML and CSS, so content edits can be used as soon as they’ve been uploaded. The same command rebuilds and deploys your app using its Helm chart if you make changes to compiled code.

Debugging Kubernetes containers

Debugging code in Azure Dev Spaces is surprisingly easy: All you need to do is first run a Visual Studio Code command to enable debugging support. Once that’s done, enable the appropriate debugging options in Visual Studio Code for working with .Net Core and Azure Dev Spaces. Pressing F5 will build and deploy your code, syncing to a new container that’s been built with an attached debugger. Adding a breakpoint to your code gives you access to a live code editor, where changes you make are automatically recompiled and synced to the currently running container.

Using Azure Dev Spaces as a target for debugging like this short-circuits the process of building a new container each time you make changes to your code. Even if you’re using ExpressRoute to link your local network directly to Azure, pushing an entire container to Azure will take time—even if it is using .Net Core and Windows Server Nano. Updating code in near real time gives you the opportunity to rapidly iterate on your code base, saving it back to your Git instance when you’re satisfied with any changes you’ve made.

Using shared Azure Dev Spaces

Modern microservices architectures mean code doesn’t run in isolation. Code you write needs to work with code from your colleagues, running in separate containers or even in different cloud resources. Azure Dev Spaces supports this approach, letting you deploy multiple containers in a single-user dev space, so you can work with a personal instance of your application. By running in a dev space, you’re offloading the required compute resources to the cloud, letting you debug much more complex applications than can run on your local development system without having to mock services and endpoints.

Shared Azure Dev Spaces let teams o work on their code, with a default space that contains the live application. Developers can create their own derived spaces, which inherit the code from the default space. Code changes can be uploaded to the derived space, with calls to other, unchanged parts of the application routed to the default space. Azure Dev Spaces uses a URL prefix to handle calls to the new code, falling back to the default if code can’t be found in your personal space. The URL prefix works with any endpoint in the shared dev space; it doesn’t need to run in your space. Remove the prefix to test code that’s in the shared space—so you can compare performance between your code and the original.

With support in Visual Studio and Visual Studio Code, there’s really no excuse for not giving Azure Dev Spaces a try.