Exploring Azure Service Fabric Mesh: A Platform for Building Mission Critical Microservices

Want to learn more about Service Mesh?
Read our ultimate guide to managing service-to-service communications in the era of microservices and cloud.
Read the guide

Earlier in the year Azure released a preview of Service Fabric Mesh, a platform targeted at microservice developers that do not want the operational responsibility of running an underlying orchestration platform. InfoQ recently sat down with Chacko Daniel, Principal Technical PM at Microsoft and service owner of the Service Fabric Azure Cluster service and Azure Service Fabric Mesh service, and discussed how this offering relates to existing Platform as a Service (PaaS) and Container-infrastructure as a Service (CIaaS) solutions like Cloud Foundry and Kubernetes.

InfoQ: Welcome to InfoQ! Could you briefly introduce yourself to the readers please?

Chacko: I’m Chacko Daniel, a principal Program Manager in the hyper-scale compute team within Microsoft Azure.  I’ve been on the Azure Service Fabric team for the last ten years. I am the platform runtime and service owner for two of our Azure Services - Service Fabric Clusters and Service Fabric Mesh.

InfoQ: Could you explain for readers that might not be that familiar with cloud technologies what  Azure Service Fabric is?

Chacko: Azure Service Fabric is a distributed computing platform that makes it easy to build, deploy, and operate always-on, mission-critical microservice applications (containerized and non-containerized). Developers focus on building microservices, and the service fabric platform solves the hard problems like lifecycle management, orchestration, availability and scalability of the applications. 

The platform also has a built-in, highly available, low-latency in memory state store with persistence. The developers can use this store via programmatic data structures (Dictionary and Queues) or as attached volume disk to build stateful microservices. 

Azure Service Fabric is open source and runs on both Windows and Linux, and you can use it either on-premises or in the cloud—it’s a great hybrid solution that can support demanding “cloud native” applications.

Azure Service Fabric has three public offerings: Service Fabric Azure Cluster service, Service Fabric Standalone, and Azure Service Fabric Mesh service. 

Service Fabric is not only used by large-scale Microsoft services such as Azure SQL DB, Intune, Azure Cosmos DB, Azure Event Hubs, and Bing, but also thousands of enterprise customers such as Citrix Systems, Alaska Airlines, Honeywell, BMW, and Societe Generale,  as well as SIs (System Integrators) & ISVs (Independent Software Vendors) such as Accenture and OSISoft.

InfoQ: How does the new Azure Service Fabric Mesh differ from Azure Service Fabric Clusters?

Chacko: We have two service fabric offerings in Azure -  Service Fabric Clusters and Service Fabric Mesh (in preview) to deploy and manage your applications in Azure.

The Service Fabric Cluster provides you with a reliable and scalable cluster of VMs running the service fabric runtime into which you deploy and manage your applications/services (containerized or non-containerized) via a highly available cluster endpoint. The service fabric runtime makes the service placements decisions based on the integration it has with the underlying azure infrastructure, making them reliable.

When using Azure Service Fabric Clusters, you have to administrator access to not only your cluster, but also the VMs that make up the cluster. You pick the VM SKUs to meet your needs, you get to decide on the network security rules and the autoscale rules by which you want to scale the cluster.  You can set up automatic upgrades of the service fabric runtime and the VM operating system. With this offering, you are only paying of the VMs, Storage and Networking resources you use, the service fabric runtime is effectively free. It is great fit for customers/ISVs who want need full control for the infrastructure.

Azure Service Fabric Mesh is currently in preview, and is a fully managed service that allows you to build, deploy and manage applications consisting of polyglot services (e.g. any language, any OS) running within containers in a serverless way. The developer just specifies the resources that his/her application/service needs like number of containers, its sizes, the networking properties, the autoscale rules etc, and the system takes care of provisioning and managing the infrastructure needed. This approaches allows the developer to focus only on the application/service rather than the infrastructure.

Service Fabric Mesh also provides intelligent message routing through software defined networking (SDN) capabilities (built on Envoy Proxy) making service discovery and routing easy between microservices. In the coming preview update we plan to enable other SDN capabilities like circuit breakers, retries, SSL termination, blue/green deployments and simplified security with managed service identities. Here you would be able to use the service fabric provided stateful capabilities that I had mentioned earlier as well. Here is a 2 minute video on Service Fabric Mesh that summarizes some of this information.

InfoQ: How does Azure Service Fabric Mesh relate to technologies that some readers may be familiar with, such as Cloud Foundry, Kubernetes or Docker (configured via Docker Compose)?

Chacko: All of these technologies are similar in that they orchestrate or deploy containers. Azure supports all the platforms you mentioned, so you can use your preferred technology stack.

As with the other service fabric offerings, with service fabric Mesh we continue our strong focus on being an application platform first by abstracting away the container orchestration that is required, and by adding intelligent messaging routing and storage that you can use with your applications.  You deploy and manage your application with a set of declarative policies about the capacity and network you need, how you want to scale, route message, manage certificates and the platform will not only orchestrate the containers, but also take care of managing the infrastructure and running it.

When using Service Fabric Mesh, unless you review the platform logs, you wouldn’t even know that Service Fabric is the underlying platform that powers the service, just as you wouldn’t know that Service Fabric is used in Azure databases and the other services. It frees developers from having to think about orchestrators and other low level management services.

InfoQ: Can you discuss the scalability aspect of Service Fabric platform?  

Chacko: Although, we run a large amount of tests internally to stress the service internally using synthetic workloads, let me provide an evidence-based answer to this question. Service fabric platform is used by most of popular Azure services like Cosmos DB, IOT Hub, Event Hub, Azure SQL DB, Intune, Event Grid. Every Azure SQLDB transaction is a replicated operation in Service Fabric, and there are many millions of SQL DBs in Azure. Every CosmosDB write is also a similar replicated operation, and EventHub uses Service Fabric and processes 2 Trillion messages daily so on. It is unlikely that most people/companies will need a scale that exceeds that of these large services that use millions of cores in Azure.

Not only is the platform highly scalable, but it also supports zero-downtime rolling application upgrades, security, built-in health monitoring, ability to do geographically spanned clusters, and more. Here’s a video of a talk that Mark Russinovich, the CTO of Azure gave that showcases Service Fabric scale and deployment speed. He deployed and ran a million containers on a 3500 node Linux cluster in under two minutes.  

Service Fabric is a technology that gets battle tested everyday.

InfoQ: Service meshes are currently a hot emerging topic? The naming is somewhat similar, and so how does Azure Service Fabric Mesh relate to service mesh technologies like Linkerd, Istio, and Cilium?

Chacko: Service meshes are all about connecting services and enabling networking primitives, including service discovery, and fast, safe and reliable service-to-service communication. Linkerd, Envoy, Cilium are network proxies that can be deployed as a service mesh on top of an orchestrator like Kubernetes or Service Fabric. Projects such as Istio lets you connect, secure, control, and observe services, and provides layer 7 (L7) networking capabilities using Envoy.

Azure Service Fabric Mesh also allows to you connect, deploy, secure and manage services and uses  Envoy under the hood to provide L7 capabilities for both Windows and Linux containers. However, it is more than just a service mesh -- it is an application platform to build, deploy, scale, and operate your microservices based applications.   

InfoQ: The Azure platform offers a range of deployment options -- what is the primary use case for Azure Service Fabric Mesh, and why should I choose to build and deploy here over another Azure offering, like AKS or Azure Functions?

Chacko: Azure offers multiple compute options to meet different customer use cases. At the end of the day, we want customers to be successful with their preferred stack, architecture, and/or existing investments.

If you’re looking for a serverless compute experience for event-driven scenarios, then Azure Functions would be our recommended path given its programming model (based on triggers to respond to activity happening in other services and bindings to easily connect to different services).

Likewise, if you are coming from the Linux ecosystem and are building containerized applications, you would use Azure Kubernetes Service (AKS). On a related note, we also find customers who have been using Red Hat Linux moving to OpenShift on Azure.

If you want Windows/.Net or microservices, Service Fabric is a great option, and Service Fabric Mesh provides the serverless, fully-managed flavor that allows you to deploy any containerized work load, Linux or windows to Azure. While Service Fabric can be used as a container orchestrator, its sweet spot resides in its programming model, and it is specifically designed for building, deploying and operating microservices applications at scale in azure.

We have been in preview with Azure Service Fabric Mesh since July 2018, and we are seeing customers taking advantage of this “serverless” offering to modernize/Lift and shift their current applications  (Windows or Linux) to azure, or to deploy new polyglot applications to the Azure.

InfoQ: Many thanks for taking the time to speak to us today. Is there anything else you would like to share with the InfoQ readers?

Chacko: Thank you for the opportunity to share details on what our team is working on. The Service Fabric Mesh journey has just started, but we need your help.  Please try out the Service Fabric Mesh preview here, and provide feedback.

You can share your thoughts, questions and feedback with us here.  Also, please feel free to tweet @chackod, if you have a question that you want me to answer.

About the Author

Chacko Daniel is a product leader with a proven track record of product /service development building enterprise-grade distributed computing platform and services. He currently works as Principal Technical PM at Microsoft and is the platform runtime and service owner of two Azure Services - Service Fabric Azure Cluster service and Azure Service Fabric Mesh service.