Microsoft is investing in containers, both with its Azure Container Service and with Azure Service Fabric, its distributed systems platform for building microservices apps.
Service Fabric is the fabric that Azure runs on, made available to developers. Azure SQL Database, Skype for Business, Service Bus, Event Hubs, Cosmos DB, Intune and other Microsoft cloud services run on Service Fabric. Users can deploy the cloud version in Azure (and soon other clouds) or put the runtime on their own Windows and (soon) Linux servers.
Azure Service Fabric takes care of handling resiliency by placing different microservices in different servers in different racks; it handles rolling updates, with an automatic rollback to known good states if there are problems, and has health monitoring for failures in VMs, in services and microservices, plus it supports both stateless and stateful microservices.
Originally pitched to developers as a PaaS for building cloud services, Service Fabric is also being used by organizations to “lift and shift” existing applications to the cloud, sometimes in conjunction with Visual Studio Team Services, Microsoft’s continuous integration and deployment service. Service Fabric has a naming service for container endpoints and DNS service for inter-container communications. Apps can be debugged remotely with Visual Studio and monitored with Operations Management Suite.
Last week, the company released a new version of Azure Service Fabric (version 5.6) would handle container orchestration duties for Windows Server Containers. And later this year, you’ll be able to use Service Fabric as a container orchestrator on Linux and there are more container orchestration features planned.
Brendan Burns, who runs the Microsoft ACS team, views Service Fabric as “a container orchestrator just like Kubernetes or anything else; it also has a richer environment for building applications. It combines the ability to deploy containers with a richer programming environment.”
Microsoft just acquired Deis for its Kubernetes expertise. And it’s also adding Docker Compose support to which already has orchestration for in Windows Server Containers.
ACS is Microsoft’s (increasingly heterogeneous) container hosting service that you can build container-based systems on. ACS runs container orchestrators for you, and you use the same open source APIs and the same ecosystem of tools you’d use to work with those orchestrators anywhere else, without having to worry about the complexity of building and maintain the orchestrator infrastructure.
ACS also supports the new managed NoSQL offerings on Azure, PostgresSQL and MySQL as a Service; these are high-availability services with data protection, recovery and elastic scaling. That’s Microsoft meeting developers where they are, Microsoft general manager for database systems Rohan Kumar told us; “There are developers who want to build on MySQL. This uses the same fabric on which we’ve built our other relational databases, it has built-in high availability, scaling up and down without any downtime.”
According to Burns, ACS Deis’ Steward and other service brokers will be supported for the managed NoSQL services soon, so that if you want your Kubernetes application to use a PostgresSQL or MySQL database, you’ll be able to browse a service catalog, pick the keyboard you want and have the service broker provision it and bind it to your application, all through ACS.
Scenarios and Services
With so many container features coming to Service Fabric, when should you be considering it and when would you use ACS? Or how about Azure Batch, where you can use Docker to package and deploy jobs?
For the Azure Service Fabric, you can use low-level primitives, or higher-level abstractions like key-value stores and queues, or even the higher-level actor model (based on the same research that was first developed as Project Orleans. As Azure Chief Technology Officer Mark Russinovich put it when Service Fabric was first announced, “This really democratizes stateful distributed programming — which is the hardest kind of programming there is.”
Increasingly, you can use containers almost every Azure service, so that you can choose the right service — not just the one that supports containers, Corey Sanders, Microsoft head of product for Azure Compute told InApps Technology.
“One of the benefits of having containers everywhere is that you don’t need to make your decision on which platform to use based on whether you’re using containers or not. For web apps, if you want to deploy a solution that’s got CI and CD integration, that’s got pre-warming, that’s got all the bells and whistles that come with app services as a fully managed platform offering, but you want to use containers — great, we have that support [in Service Fabric]. Or if you want to run a job-based computing solution and not have to manage the infrastructure and just run jobs across a set of virtual machines, but you want to use containers to host your jobs — we’ve got that. That’s Azure Batch. The idea being that when you approach the platform, you approach with a scenario [in mind], not just with ‘I want to use containers’.”
Containers are rapidly becoming the de facto way of encapsulating applications, which is why Docker and the rest of the container ecosystem are showing up in Microsoft’s products and services, from Windows Server to SQL Server 2017 to everywhere in Azure, Sanders explained. Rather than a destination, containers are another tool.
“The combination gives customers a lot of flexibility to pick [a service] based on their interest, their scenario and their programming models. Containers supported everywhere on Azure is such a great step forward.”
InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.
Feature image via Pixabay.
