In-Depth

Azure Arc: A Deeper Look at Microsoft's Multicloud Play

Arguably one of Microsoft's biggest announcements this year was the introduction of Azure Arc at Ignite. But is this really a game-changer or is Microsoft just falling for the multicloud buzz?

• By Joey D'Antoni
• 12/23/2019

One of the major announcements at Microsoft Ignite this past November was the introduction of Azure Arc, a Kubernetes-based platform that allows you to deploy Azure data services, which currently include Azure SQL Database Managed Instance and Azure PostgreSQL Hyperscale. You can run Azure Arc on any Kubernetes cluster, anywhere -- whether in your on-premises datacenter, Amazon Web Services (AWS) or Google Cloud Platform (GCP).

While this is all very interesting and enables many multicloud scenarios (timely, as "multicloud" seems to be the buzzword of the year), it also marks a fundamental change in the way Microsoft is developing on the platform.

Building Clouds
When you are building a public or private cloud, you need to have a platform upon which to build it. When we built our private cloud at Comcast, we used a combination of commercially available hardware, VMware's virtualization framework and some other code-based tools to perform all of our automation tasks, handle scaling and changes, and, frankly, abstract all of our hardware.

Microsoft has built an open source solution for this called Service Fabric, which is the platform that most Azure services, including Azure SQL Database, are built on. Service Fabric has proven itself to be quite powerful and resilient at running Azure, and it has flexibility in that it has no connection to Azure or Microsoft (you can run it on Linux), and you can even run containers on the platform.

However, the recent momentum of Kubernetes is unquestionable. With Microsoft (along with the rest of the world) embracing the Kubernetes ecosystem, it was just a matter of time before we started seeing major cloud development take place on Kubernetes.

Why Do We Need Kubernetes for the Cloud?
I have been on the Kubernetes hype train as much as anyone, mainly because I think it's a really well-engineered platform for modern computing, and because I really like the notion of all of my infrastructure being stored in code and in source control. Hardware being abstracted away is another big benefit.

The other component is how aligned Kubernetes is to cloud platforms. From the moment I started using the platform, it was very clear to me that Kubernetes had a very similar design and mindset to that of Azure. Which is natural; they are both built using the latest distributed computing theory and mindset.

However, I immediately thought that if I were building a new cloud service, I would want to build on Kubernetes. I have a number of reasons for this, foremost being the fact that it could be deployed anywhere. While Kubernetes has some hardware and networking requirements, it doesn't require specific hardware like Azure Stack or AWS Outposts do. If you build a solution to ship to customers and you build it on Kubernetes, they can run it.

Trending Toward Multicloud
This year, I have heard a lot of buzz and read a lot of articles about organizations moving toward a multicloud deployment. In some scenarios, this is a mix of private and public clouds, or different public clouds.

While the intention of multicloud is to avoid vendor lock-in and provide protection from a major public cloud outage, in general, I am against it as a strategy. There are some rare exceptions where I see multicloud having a major benefit, but those are really only mission-critical front-ends for major Internet companies. If your company doesn't do 90 percent of its commerce via its Web site, your app does not need to be multicloud.

There are numerous reasons for this, but the first is that it leads toward a strategy where organizations are exclusively using infrastructure-as-a-service (IaaS) solutions. This is not terrible in and of itself, but it does tend to be more expensive without offering the same degree of flexibility that platform-as-a-service (PaaS) solutions offer.

Additionally, there is the nontrivial component of network egress cost: Data into any cloud solution is free, but data out is metered. Finally, getting your IT organization up to speed on one cloud platform is challenging enough. Having them try to master two or three is even harder.

However, multicloud is clearly what the marketplace demands, and by building a platform that can easily run anywhere, Microsoft is meeting this need. Unlike Azure Stack, which requires the purchase of expensive hardware and support, Azure Arc is strictly a software-based offering.

What Does Azure Arc Deliver?
Azure Arc allows you to view and manage all of your resources -- whether they're on-premises, in another public cloud or in Azure itself -- through the Azure portal.

It will allow you to perform deployments using Azure Resource Manager and its tools like PowerShell and the Azure CLI. You can also manage Azure Arc using Azure Policy, giving you governance just like you would have in Azure.

Currently, you can run Azure SQL Database there, and going forward I expect to see more Azure platform services being added. Splashy announcements for a service offering like this would not happen if the roadmap were limited to a single Azure service or two. The fact that the Azure Arc service is built on Kubernetes allows Microsoft to ship all of the components you need to hook into Azure for management and have Azure-like services available to you.

Summary
As I was writing this column, a customer messaged me about the level of effort required to do a proof-of-concept of Azure Arc running on AWS, as one of their customers would like to have my client's services available there. While multicloud is challenging (and not recommended by me), it is clear that organizations are demanding solutions to run across public clouds.

What does this mean for the IT professional? They have to learn Kubernetes. But aside from that, I think it suggests a trend of platform convergence. That is, it does not matter where your resources are located, as long as they share a common management pane.