Today, we are excited to announce the public preview of Azure Dev Spaces, a cloud-native development experience for Azure Kubernetes Service (AKS), where you can work on your applications while always staying connected with the cloud and your team. Over the last year, we have spoken to many developers working in different languages and platforms who are exploring Kubernetes. They are excited about the opportunities it presents for them to build cloud-native applications with containers and microservices without having to do any infrastructure management or orchestration. We are also seeing enterprise teams migrating their existing apps to Kubernetes and then incrementally modernizing them by extracting application functionality into microservices. AKS makes it easier for application development teams to get going with Kubernetes in the cloud and Dev Spaces enables a familiar yet powerful developer workflow for building apps on AKS.
Containers and the microservices pattern enable you to build cloud-scale applications that are scalable and durable, where each microservice can be independently managed and updated. For dev teams, a key benefit of this pattern is that it parallelizes development. However, microservices introduce new challenges in your workflow. Some considerations developers working in a team (which is most developers) now have is: How do you work on your service when it depends on other services that are also being changed at the same time? How do you establish a baseline that all members in the team can work on until they are ready to commit changes? Since your microservice by design only handles a specific functionality needed by the application, how do you test any changes to it end-to-end? Azure Dev Spaces is a new service that helps you address these challenges and build cloud-native apps on AKS from your favorite tools.
Getting started on Kubernetes with Dev Spaces
Dev Spaces makes it easy for you to take your first steps into container development. You can use Dev Spaces with your code editor of choice to scaffold the artifacts required to build and run your code in a container, such as the Dockerfile. This allows you to quickly containerize your application. Your code is then synced to the cloud, where it is built and deployed as a container into AKS. Now you can edit and debug this code as if it’s all running locally on your machine. All without you having to install Docker or Kubernetes tooling on your local machine or having to learn about Docker or Kubernetes concepts such as Dockerfiles or Helm charts. But when you are ready to dive deeper into these amazing technologies, you are all set up with the right artifacts to start that journey.
It’s easy to get going with Dev Spaces – simply pick a Dev Space and spin up your app in it. In a few seconds, your app is running on Azure in AKS.
Now that your app is running in a Dev Space, you can make changes to it and debug it all on Azure.
Leveraging microservices and containers for your apps with Dev Spaces
Dev Spaces really shines when the app you are working on has many microservices. As your application gets past a couple of microservices, it becomes increasingly difficult to reap the productivity benefits of parallelized development. Imagine you are a developer who has just joined a team working on an application composed of microservices. You know which service or set of services you need to work on, but you don’t know how the different services of the application call each other. You also want a good level of confidence that when you commit your code and deploy it in your team’s integration testing environment, the overall application will continue to work with your changes. Typically, you would mock the dependencies that your services have on other services but how do you handle services that make calls to the services you are tasked with changing? And even if you could reproduce all the upstream and downstream dependencies locally on your machine, you’d be spending a good amount of time just setting them up, especially if they are written in different languages and require runtimes you must install locally. You end up with a lot of lost time that you’d have rather spent on working on the task at hand. And there is all the clutter on your machine that you need to clean up.
We built Azure Dev Spaces to specifically address these concerns and ensure that you get the same productive experiences that you have come to expect from Visual Studio and Visual Studio Code, even when building cloud applications. With your IDE or editor connected to an AKS cluster enabled with Dev Spaces, you can edit and debug your services while always operating in the context of the overall application. You create and work in your own space within the cluster; every space has a unique URL endpoint corresponding to the public endpoints your application is configured with. Then you can clone the service or set of services that you will be modifying and “up” them into your private space. As part of the development you will often want to debug just your services. You can simply set breakpoints and debug your service as if it were running locally. As you work on your service(s), you can hit the special endpoint for the overall application with your test requests. Dev Spaces is smart enough to route your requests through the default set of microservices in your application. For the services that you have “up”ed in your space, Azure Dev Spaces routes any upstream calls to them for these test requests. You can even set breakpoints on multiple services that you are working on in your space and debug across them and the overall application.
The following video shows how you can work on a service called MyWebApi that is called by a separate service called Webfrontend. You can work on MyWebApi in your own space, but test it end-to-end without having to mock Webfrontend or make a copy of it in your space. You can find the sample used here in our GitHub repo. While this is a simple example, you can leverage the same capabilities when working on a subset of microservices in an application that has 10s or 100s, and your upstream and downstream microservices are also changing all the time.
For more details on how to get going with Azure Dev Spaces, configuring your dev setup to work with Dev Spaces and using it as part of your dev workflow, please see the Quickstarts and Tutorials.
What’s next
We announced the private preview of Azure Dev Spaces in May at //build and excited about making it available to everybody now. To get started, simply head to https://aka.ms/get-azds.
Currently, you can develop in .NET Core and Node.js, both on Linux, in Dev Spaces. In addition to editing and debugging microservices independently from Visual Studio and Visual Studio Code, we are excited to see customers starting to use Dev Spaces for other scenarios such as integration testing and for supporting their GitHub flow. In the next few months, we will be announcing support for additional languages and such scenarios. As you delve more and more into cloud-native development, our goal is to support you with the right experience and enable rapid productivity with cloud-native development. Are there other challenges you have with cloud-native development? Do you have any feedback on Azure Dev Spaces? Let us know here in the comments or connect with our engineering team via GitHub.
 |
Balan Subramanian Principal Program Manager, Azure Developer Experience @balansubr Balan leads the Azure DevEx product team tasked with creating delightful experiences on Azure for all kinds of developers. This team builds and manages tooling for Azure services, SDKs and CLIs for Azure, OSS integrations, and services such as Azure Container Registry, Azure Lab Services and Azure Redis Cache. He is particularly interested in helping developers go cloud-native both in the apps they are building and their DevOps. Before coming to Microsoft, Balan launched new services for developers at Heroku and AWS. |