Microservices based application on the Azure compute platform
This is a post by Boris Scholl, a Principal Program Manager on the Microsoft Azure Compute team.
Introduction
This blog post covers two microservices-based applications implemented and deployed onto Microsoft Azure’s Service Fabric and Azure’s Container Service. While this blog post focuses on microservices-based applications on Azure Service Fabric and Azure Container Service it is worth mentioning that Azure is an open platform that allows you to run microservices based applications on a variety of technologies such as CloudFoundry, RedHat Openshift, or Kubernetes.
Azure Service Fabric
Let’s start with Service Fabric, Azure’s turnkey microservices platform. Azure Service Fabric makes it easy to develop, package, deploy, and manage scalable and reliable containerized and non-containerized microservices and is currently being used by more than 300 customers, such as BMW and Schneider Electric.
Service Fabric clusters can be provisioned into pretty much any environment such as public Azure, on premises, private clouds, or other cloud providers. The generally available version of Service Fabric currently runs on Windows, but it is available on Linux in a private preview. Follow the link to find more information on Deploy anywhere on Windows Server or Linux with Service Fabric
On top of the fundamental platform capabilities, such as fast deployment, placement of services, reliability, high density, health reporting, coordinated upgrades, and service endpoint discovery to any type of application (Node.js, Java etc.), Service Fabric offers programming models to build stateless and stateful microservices. The programming models are currently available in .NET on Windows and Java on Linux.
It’s important to point out that stateless microservices in the context of Service Fabric means stateless service instances that persists state externally, for example a database or cache.
Service Fabric stateful microservices on the other hand, store the state locally with the compute instances. This enables low latency reads and writes, and also simplifies the overall architecture as there are less moving parts to take care of. One of Service Fabric’s highest goals is to provide data reliability and consistency, which is accomplished through replication.
Let’s look at a real world microservices example built on Service Fabric.
TalkTalk’s video streaming and encoding solution started out as a “lift and shift” solution on Azure Infrastructure as a service offering because this was the quickest way to move the entire application to the cloud. However, with continued rapid growth and new business requirements, the TalkTalk team began to redesign parts of their encoding application to a microservices-based approach using Azure Service Fabric as the platform.
The microservices approach enabled TalkTalk to make service deployments easier, support scale requirements of each service more flexibly, and enable no downtime upgrades of individual services. Their microservices-based application also integrates well with Azure services such as Azure Media Services or Azure Batch.
Figure 1 shows the high level architecture of the microservices based application and the flow of an encoding request through the microservices application.
Below is a description of the role for each microservice taking part of an encoding request:
Step 1: A TalkTalk client calls the EncodeRequest method, which is exposed on the Activity Web API through the Azure Management API.
Step 2: Activity Web API stateless microservice is a listener, based on Open Web Interface for .NET (OWIN), hosting an API Controller that exposes the ability to create new encoding requests. This API is used for external interaction by services outside Service Fabric. It receives calls from the Management API service.
Step 3: Activity stateful microservice uses Service Fabric Reliable Queues API for incoming work. This microservice then creates an activity actor that represent the encoding work that needs to happen.
Step 4: ActivityActor microservice represents a list of work items to track the step execution and create the individual activity step actors. Being a stateful actor means no data is lost during failures as the data has been replicated.
Step 5: ActivityStepActor microservice coordinates the work step itself. The work is executed in other Service Fabric applications. For example, the Encryption Job Management App uses Azure Batch to perform a custom encryption step required for TalkTalk set-top boxes. The encryption job management app itself contains multiple microservices and encapsulates the required interactions Azure Batch. The activity step actor communicates with the relevant services using the service proxy that Service Fabric provides.
The ActivityStep stateless microservice exposes a Service Communication Listener, so that other Service Fabric services such as the Azure Media Services (AMS) Job Management app (Step 6) and the Encryption Job Management App (Step 7) can interact with activity steps. It’s like a call-back service — such as when work is completed by the Batch service and needs to wake up the ActivityStepActor to finish or update the work step.
Throughout this process a reminder on each actor is used to periodically save actor state in DocumentDB, this serves two purposes — firstly to provide ad-hoc querying capability, secondly it provides a protection and backup of the data outside of Service Fabric.
You can find a more detailed description of Talk Talk’s microservices based application here.
Azure Container Service
Azure Container Service (ACS) is another Azure service that allows you to deploy and run microservices based applications. Some of the well-known customers using ACS today are Avanade, ESRi and CloudBees.
The core functionality of ACS is to allow you to create a cluster for orchestrating container based workloads using either DC/OS or SWARM as the orchestrator. From a microservices perspective you are responsible for choosing what to use for service registry/discovery, service communication, monitoring etc.. This is also the main difference to Service Fabric, which goes beyond just cluster and orchestration capabilities by offering integrated services such as services registry and discovery and programming models.
So what are the benefits of using ACS?
Let’s start with the obvious one — using OSS technologies. Given that ACS uses Docker Swarm and Mesosphere’s DC/OS you can take advantage of all the OSS community resources available for those two technologies. Given the time they have been in the market you find walkthroughs, tutorials, code snippets and even mature solutions for pretty much any scenario you want to enable.
Another benefit is the simplicity of setting up a cluster and having it managed by Azure. Those of you who have set up a DC/OS cluster or a Docker Swarm cluster on bare metal or virtual machines before may know that it requires more than just wiring together bunch of machines. You also need to configure a variety of additional components and services, expose endpoints, hook the agents up to the load balancer etc. As you can imagine, quite some lines of customization scripts are required to automate such a cluster set up. ACS simplifies the cluster setup using a templated approach and abstracting away all the configuration steps.
But setting up a cluster of machines with an orchestrator is just half the job. Once the cluster is up and running you may need to patch the machines in your cluster or you want to upgrade to a newer version of SWARM and DC/OS. Those are traditionally tasks that require thorough planning. ACS will support a fully managed infrastructure in the future, which will allow you to solely focus on your workloads in the cluster rather than any infrastructure management related tasks.
You can either provision a cluster from the Azure portal or automate the provisioning by using Azure Resource manager template for an infrastructure as code approach. The only values you need to provide are
- orchestratorProfile: This defines which orchestrator you want to use. DCOS or Swarm
- masterProfile: defined the numbers of master nodes and the DNS prefix
- agentPoolProfiles: number of agent nodes, size of the nodes and the DNS prefix
- linuxProfile: Username and ssh key for connecting to the nodes
The snippet below shows the json code of the Azure Resource Manager template for ACS.
“resources”: [
{
“apiVersion”: “2016–03–30”,
“type”: “Microsoft.ContainerService/containerServices”,
“location”: “[resourceGroup().location]”,
“name”:”[concat(‘containerservice-’,resourceGroup().name)]”,
“properties”: {
“orchestratorProfile”: {
“orchestratorType”: “[variables(‘orchestratorType’)]”
},
“masterProfile”: {
“count”: “[variables(‘masterCount’)]”,
“dnsPrefix”: “[variables(‘mastersEndpointDNSNamePrefix’)]”
},
“agentPoolProfiles”: [
{
“name”: “agentpools”,
“count”: “[variables(‘agentCount’)]”,
“vmSize”: “[variables(‘agentVMSize’)]”,
“dnsPrefix”: “[variables(‘agentsEndpointDNSNamePrefix’)]”
}
],
“linuxProfile”: {
“adminUsername”: “[variables(‘adminUsername’)]”,
“ssh”: {
“publicKeys”: [
{
“keyData”: “[variables(‘sshRSAPublicKey’)]” }
]
}
}
}
}
As a result, you end up with an DC/OS or Docker Swarm cluster that is fully configured and you can start deploying your applications into it. Figure 2 shows the output of a fully configures ACS cluster based on DC/OS
In addition to deployment, ACS integrates with Virtual Machine Scale Sets (VMSS), which, in the future, will enable simple auto scaling and patching support across orchestrator and infrastructure. As mentioned before ACS is not opinionated when it comes to deploying and running microservices-based applications. This offers a huge amount of flexibility when deploying using ACS. You can use whatever you would use for running those types of applications on top of DC/OS or Docker Swarm in other environments.
Let’s look at an example for a microservice based application using DC/OS as the orchestrator in Azure Container Service. Flak.io is an ecommerce sample application that is being specifically built to demonstrate a microservices application that:
- Uses different technologies
- Honors different scale and availability requirements for each service
- Implements a data store per service
- Uses DC/OS’s service registry and discovery options.
From a user’s perspective it allows shoppers to browse and purchase products from a catalog.
The application consists of four main services and a frontend service:
- Frontend: The frontend is implemented as an AngularJS SPA and provides the landing page for Flakio
- Catalog service: The catalog service is responsible for managing product information
- Order service: The service is responsible for processing orders. You should note that the order service would also have a product model that’s different from that in the catalog service because it belongs to a different context
- Recommendation service: The service is responsible for analyzing historical information and maybe more real time information to make recommendations
- Notification service: is responsible for sending email notifications, as well as storing and managing email templates.
Figure 3 shows the high level architecture of Flak.io
You can find the source code for Flak.io at https://github.com/flakio.
Note: Flak.io is work in progress, for example event sourcing, recommendation and notification are still being worked in, but it should give you a pretty good idea about designing and deploying a containerized microservices based application to ACS.
Summary
In this blog post we covered two examples for microservices architectures, one for Service Fabric and one for Azure Container Service. Overall you can think about Service Fabric as a turnkey solution for building microservices based applications where developers can solely focus on writing code whereas the Azure Container Service helps you quickly set up a cluster and seamless manage the infrastructure with either DC/OS or SWARM. Once an ACS cluster is provisioned you have the choice to use whatever technologies meet your needs best for microservices based applications and leverage the growing communities of Docker and Mesosphere. You can find more information by clicking on the links below
Getting started with Service Fabric
Try Service Fabric using party clusters for free
Deploy and run microservices based applications on top of ACS
