Meet Microsoft’s new managed microservices: Azure Service Fabric Mesh

Microsoft’s Azure platform services have always offered support for microservices. In fact, Azure Service Fabric has been there from the start. Initially supporting Azure’s SQL services, it’s now a foundation of much of the Azure platform, along with Cosmos DB.

You’ve been able to use Azure Service Fabric in your own applications for nearly as long, because it’s key to managing and scaling your own code. With support for containers and virtual infrastructure, you can compare it with other service orchestration tools like Kubernetes. Although powerful, it’s not that intuitive to use; its complex set of XML-based configuration files can get in the way of building a deployment and can be hard to debug.

Azure Service Fabric Mesh is meant to fix that difficulty of use, building on lessons from Kubernetes to simplify configuring and deploying applications built up of container-hosted microservices and of Azure’s own platform services.

Introducing Azure Service Fabric Mesh

Azure Service Fabric Mesh is a serverless host for .Net Core-based microservices, using either ASP.Net Core or console applications. But it also lets you develop and host code in any language that’s supported by a Docker container, so you can work with languages that have a more distributed systems focus, such as Google Go. Azure’s underlying platform flexibility makes this an alternative to other microservices frameworks, as well as removing the need to build and manage service orchestration around your code.

All you need to do is set the resources you need, the availability requirements for your services, and any resource limits. Azure Service Fabric Mesh does the rest for you, handling the underlying infrastructure and restarting services as necessary. While it’s best suited for microservices, it can also support larger applications. If code can run in a container, it can be supported on Azure Service Mesh. It’ll also automatically handle upgrades, when you deploy a new version of an application over running code, swapping out containers for you—which makes it a useful endpoint for a devops pipeline.

Azure Service Mesh clusters can also work across Azure availability zones and across regions. By using this feature, you automatically get geographic reliability as well as overall service reliability. This approach does require more work in defining your clusters, but it’s still a lot less than when working with other Azure platform tool.

Azure Service Mesh’s pricing is also good, with per-second billing for container compute and additional costs for storage.

Building Service Fabric Mesh applications

Microsoft recently added support for Service Fabric Mesh to Visual Studio 2017. Available through the Visual Studio Marketplace, the tool adds a new Azure Service Fabric Mesh Application option to the project dialog. Because it supports both Windows and Linux containers, you can choose the target container type.

However, you can only test and debug Windows containers at this point, so use Windows containers to build your .Net Core microservices before deploying as Linux. To deploy as Linux, all you need to do is change the target osType property from Windows in your Azure Service Fabric Mesh’s service.yaml configuration file.

Visual Studio’s Azure Service Fabric Mesh tool creates the appropriate service.yaml file for your service, as well as the Dockerfile to host your service images. It also can build and manage application and networking YAML files. These files, along with service.yaml, are used to deploy to your Azure account, handling working with the underlying Azure Service Fabric. Code is compiled and added to Docker images that are stored in the Axure Container Registry. Once published, the service is activated and you’ll get details of the service endpoint URLs for your application.

To work with Azure Service Fabric Mesh code on your local hardware, you need to configure a local Docker environment, supporting Windows Containers and Hyper-V. On top of that, you need to be running the Azure Service Fabric Mesh SDK. You can download it from the Web Platform installer, along with other tools you might need for building and testing code intended to run on Azure.

Azure Service Fabric apps need to run on a cluster, and although Visual Studio will build and configure a single-node cluster for you, you can build your own cluster using PowerShell with the DevClusterSetup command that’s part of the Azure Service Fabric SDK.

Debugging and deploying Azure Service Fabric apps

Local debugging is a useful feature, though you need to enable Docker support on your development PC. Visual Studio’s remote debugging tools connect to your app’s local container, and you can then use the IDE’s familiar debugging tools to ensure your code runs before deployment.

You’re not limited to testing on your PC. You can use Visual Studio’s devops features to work with Azure Service Fabric Mesh code that’s hosted in a continuous integration/continuous (CI/CD) deployment pipeline. You do need to use tools like Azure Service Fabric’s local cluster manager to ensure that your test environment is up and running. Breakpoints can be used to debug and step through your code across services.

It’s a good idea to keep each Azure Service Fabric Mesh application in a separate resource group, because that lets you quickly clean up after a new deployment. It also helpx handle deployments in different regions. Azure Service Fabric environment variables can handle IP addresses, Azure service access keys, and other instance-specific information.

Microsoft’s tool also supports adding multiple services to an Azure Service Fabric Mesh solution in Visual Studio. All you need to do is define a new service fabric service in the Visual Studio Solution Explorer. Once you’ve created the new service, you can define its endpoints in its service.yaml file, so your code can work with Azure Service Fabric Mesh environment values to handle interservice communications.

Finally, to publish an app, you walk through a familiar Visual Studio Azure deployment wizard. You need to indicate the location for the application deployment, the resource group it’s part of, and the Azure Container Registry it will use to host its containers. Once the various elements of your app have been uploaded to Azure, you use the Azure CLI to manage your code. Start by installing the Azure Service Fabric Mesh CLI, then use its commands to see currently deployed apps and their state.

By giving you a serverless platform for your application containers, Microsoft is taking much of the stress out of building distributed applications at scale. If you can build microservices in .Net, you can use Azure Service Fabric Mesh. All that really matters is how you choose to deploy your code, and that’s all down to your YAML.