Microsoft, at its annual Build conference, announced Azure application services on Kubernetes with the help of Azure Arc, which was covered in an earlier InfoQ news. InfoQ caught up with Jeff Hollan, director of product management, Azure Application Platform at Microsoft, for more details of the announcement.
He talks about the philosophy behind running Azure application services on Kubernetes, some of the technical details, and the requirement of Azure Arc for multi-cloud.
InfoQ: What was the primary motivation for bringing Azure application services to Kubernetes? Is it possible to leverage an existing Kubernetes cluster to deploy Azure application services, or do they have to be created via the Azure portal or CLI?
Jeff Hollan: Azure offers the most comprehensive application platform spanning from web apps, functions, APIs, and workflows. Developers have told us how much they value these purpose-built experiences for running their mission critical workloads – you can get code up and running in the cloud often with a single CLI command.
While developers love these experiences in Azure, they had to find another option when running elsewhere. If a scenario required running an app on-premises or in another cloud, developers would have to drop down to a lower level of abstraction – something like Kubernetes. As powerful and revolutionary as Kubernetes is, it’s not optimized for developer workflows. And we were hearing our customers asking for help here.
We built the capability for Azure application services to run on Kubernetes to allow developers to use the same tools and service abstractions regardless of the environment.
We wanted to make these capabilities as flexible as possible. You can bring any Kubernetes cluster, new or existing, and install the Azure Application Services on top. Your cluster can now expose rich web applications, serverless functions, APIs, and workflows using the optimized tools and experiences we’ve been improving for nearly a decade.
InfoQ: What is the role of Azure Arc? Can you provide more implementation/technical details on the different components and how they fit together?
Hollan: With Azure Arc, we enable you to use the tools and services you're already familiar with, deploy your applications consistently to multiple clusters, automate security and governance across the entire environment no matter where it's located. This provides flexibility, lets you deploy with high velocity and enables you to have a single pane of glass to easily manage your entire app and data estate.
With Azure Arc enabled services, this allows you to bring the Azure services you're using today -- such as application services, data services, ML services -- to any environment including on premises, on the edge, or even other clouds, like AWS or GCP.
When combined with the use of Arc-enabled data services, like Azure Postgres and Azure SQL, applications and their data can now run anywhere using fully managed cloud services, an industry first. Importantly, the way you deploy does not change; you can still use your existing tools and practices and benefit from a seamless, consistent experience.
On the technical implementation, Azure Arc acts as the bridge between the service APIs and the destination Kubernetes cluster. So as a developer, I use the CLI to deploy a function, and if the destination maps to my own cluster, Azure Arc relays that request via a secure relay to my cluster. Once the request hits my cluster, the application services running on the cluster go about configuring the app and code as requested.
All the compute and traffic will go directly between the user's cluster – Azure Arc bridges the management and monitoring alongside your Azure managed resources. It’s a single pane of glass to manage and deploy your applications, regardless of whether the destination is an Azure data center or your own cluster.
InfoQ: Kubernetes provides platform agnosticism. How is this extra layer of Azure application services helping when Cloud-Native apps can be developed on Kubernetes directly instead?
Hollan: While Kubernetes has provided platform agnosticity, it’s a general-purpose container orchestrator. Going from Kubernetes to an application that is integrated with monitoring, certificates, scaling, and DevSecOps requires teams to piece together, operate, and build on top of this general-purpose platform.
Platform services like Azure application services and Azure Functions have monitoring, certificates, and scaling as pre-configured and built-in features of the service – greatly reducing the energy and effort required. So, by always developing on Kubernetes directly, you’re needing to take on this additional operational and configuration overhead.
With Azure application services on Kubernetes, we’re hoping to provide the most value wherever we can. When you can run a workload in Azure, you can target our platform services directly – no cluster management or configuration required. However, if you need more flexibility or control, we’ll allow you to target Kubernetes, but will layer on monitoring, certificates, scaling, and more – transforming your general-purpose cluster into one with a world class application platform.
InfoQ: From a development and operations perspective, what are the challenges of running Azure application services on-prem (or another cloud) instead of consuming the services on Azure cloud? How does scaling, observability, etc., work?
Hollan: The main notable consideration is that while we’re layering on features like code build and scaling, the underlying cluster still needs to be maintained and operational. Teams will need to make sure to monitor the health of their Kubernetes cluster, keeping it up-to-date and with enough capacity. We’ve strived to make the behaviors of the application consistent between our fully managed services and when running in your own Kubernetes cluster, so things like auto-scale and routing will behave the same.
InfoQ: How does GitOps (or other automation techniques) factor into deploying and managing such deployments at scale?
Hollan: We built these experiences with git flows in mind. When managing multiple clusters, GitOps can be leveraged to provide consistent configuration through Azure Arc. This means you can make a configuration change in a git “source of truth” and have Azure Arc apply that change too all clusters defined in a given policy.
For the applications themselves, we recommend using Git with continuous integration and deployment so changes can be validated, tested, and deployed through a git flow. We’ve even released two app templates along with this application services release to give users a starting point for building apps that can run anywhere, while also maintaining a strong governance and versioning story.
InfoQ: Finally, what is the plan/roadmap for more Azure services migrating to the edge on Kubernetes?
Hollan: We’ve been very excited by the interest and customers who have joined and are using application services on Azure Arc today. Our primary goal right now is to take the preview bits and get them to general availability. That includes continuing to build out the number of features that are supported when running within Kubernetes and iterating on the current experiences based on customer feedback. We’d love to work with as many teams as possible to build productive experiences that can run anywhere. Feel free to reach out for any questions or feedback!
More technical details are covered in the technical blog. The recording of the Build presentation walks through some of the technical details including a demo.
