Build 2018: How Microsoft is embracing cross-platform development

Microsoft’s Linux support is also a key part of its microservices and DevOps story. When the company talks about cloud-native applications, it means applications broken down into microservices and easily scaled. Microservices generally also implies containers (though there is also a serverless platform, called Azure Functions). Further, making maximum use of managed services such as Azure SQL or CosmosDB (Microsoft’s no-SQL database manager), rather than hosting your own database server, reduces the maintenance burden and lets you take advantage of their built-in scalability.

Microsoft’s container story is diverse though, perhaps to the point of confusion. You can run a container in many different ways, including the following:

• Azure Container Instance. This service came out of preview in April 2018. It lets you run a Windows or Linux container without creating a VM or cluster (a serverless model) and with automatic scaling. It is charged on CPU and memory usage per second. “We hear consistently from customers that ACI is uniquely suited to handle their burst workloads. ACI supports quick, cleanly packaged burst compute that removes the overhead of managing cluster machines.,” says Sanders in a blog post.
• App Service. The Web App for Containers service lets you deploy containers with the same model as the Web App Service: deploy to a managed service with no OS to maintain. There is easily configured scaling and load balancing. However it is not truly serverless; you pay for what is running regardless of usage, though you can set rules for automatic scaling. You can now run more than one container in a single App Service.
• Azure Kubernetes Service. This is for Linux containers orchestrated by a hosted Kubernetes service. You deploy a cluster using either the command-line or via the Azure portal. Benefits of Kubernetes include configuring self-healing, scaling, load balancing, automated rollback if needed, storage management and more.
• Azure Service Fabric. This supports both Windows and Linux Containers. Service Fabric is a runtime for managing microservices. Whereas Kubernetes is widely used throughout the industry, Service Fabric is unique to Microsoft, though it can be run on-premises as well as in Azure. Service Fabric manages deployment, monitoring, upgrading, scaling and more. It supports an application framework called Reliable Actors, for stateful services. Announced at Build was a preview of Service Fabric Mesh, which removes the need to manage clusters in favour of a serverless approach.
• Azure Batch. You can run containers in batch computing jobs using Linux or Windows.

One thing that helps to make sense of the diverse choices is the Azure Container Registry (ACR). This service, which uses an API compatible with the Docker Registry, lets you manage container images and deploy them to all the above services. This means you can setup a continuous integration or continuous deliver (CI/CD) process that pushes containers to ACR, and from ACR deploy to production.

Which Azure container service should you choose? The idea is that if you have a monolithic or small-scale application you can use App Service, but if you need full orchestration the decision is between AKS or Service Fabric.

It is worth noting that Microsoft itself uses Service Fabric for numerous Azure services including Azure SQL, CosmosDB, Dynamics, Power BI, InTune, Azure MySQL, Visual Studio Team Services, Azure Container Registry and more. This is in a sense the native Azure microservices platform.