Today, in part 2 of this series, I wanted to continue down the path of exploring Azure Service Fabric by presenting an overview of Azure Service Fabric. In part 1 of this series we talked about why you would want to use something like Service Fabric. That led us to a primer discussion around microservices which just so happen to run on the Service Fabric platform. If you haven’t done so already, you may want to read part 1 of this series first as it will help you build a better understanding.
My Journey to Service Fabric
Recently I was working on a project where the customer had an application that was hosted in Azure. They were utilizing the Cloud Services platform but soon came to terms that it may not be the best option for their application. With Cloud Services there are some limitations around being able to scale an application, primarily dependent upon how the application was architected. They soon realized that they needed a solution where their application workload would be scalable, reliable, and manageable. They had already begun to start working on a microservices approach for the application so it was only fitting that they explore Service Fabric. Hence, why I decided to write this blog series. I figured I could help others down the Service Fabric road to becoming DevOps Unicorns. So let’s see what Service fabric is all about.
What is Service Fabric
Service Fabric in its most simplest form is a platform for running microservices. It can’t be that simple right? Well, it is quite simplistic but there is much more to it than that. Service Fabric is a distributed systems platform that simplifies the packaging, deployment, and manageability of scalable and reliable microservices. This platform significantly changes how developers and administrators approach the deployment and management of mission-critical workloads. No longer do they have to deal with building and managing complex infrastructures. Instead they can focus their efforts on their application, increasing productivity and customer satisfaction.
Service Fabric itself is a shared pool of servers known as the Service Fabric Cluster. The cluster is made up of multiple nodes that host distributed microservices, those being stateful or stateless. By using microservices we have the ability to scale services independently of each other which allows developers to push out updates and fixes more frequently, not to mention reducing the chances of a broken service affecting the entire application. In addition, Service Fabric provides application management capabilities for provisioning, deploying, monitoring, upgrading, patching, and deleting of services. From a natural progression of application hosting we have gone from a physical server, to a virtual machine, to a container, to microservices. So whats next? Nanoservices? There is a concept of an application being too fine-grained and requiring more effort to stitch the services together but we won’t worry about that now. The image below shows a good representation of Service Fabric with many microservices deployed on top. Not only can Service Fabric be deployed in Azure, but it can be deployed in other clouds as well as on-premises.
Traditionally stateless applications required a database of some sort to maintain the state along with caches and queues to address latency. One of the problems with this is that it required more components to manage that didn’t scale really well together. In addition, each additional connection added to the latency. By using stateful microservices we remove the need for those additional components and can maintain high-availability and low-latency by keeping the application code close to the data.
Within Service Fabric there is support for application lifecycle management (ALM) from development, through deployment, during management, and decommissioning. By utilizing packaged microservices, multiple instances can be deployed and upgraded independently. Rolling upgrades can be performed to ensure the application is always available. In the event an upgrade fails, automatic rollback will kick in.
- self-healing applications
- run Service Fabric on your laptop as a dev environment; same code runs in Azure
- services can be built using framework of your choice
- applications deploy in seconds
- write once, deploy anywhere
- deploy on Windows Server or Linux (coming soon)
- deploy hundreds or thousands of applications per machine
- manage using .NET APIs, PowerShell, or REST
- monitor and diagnose the health state
- scale up or down the cluster, capable of scaling to thousands of machines
- redistribute and optimize load after failure
How Service Fabric Works
Briefly let’s discuss how Service Fabric works. Refer to the Azure Service Fabric documentation for a deeper dive.
In Service Fabric you have a cluster of nodes running a Windows service called FabricHost.exe that auto-starts upon boot. This service starts Fabric.exe and FabricGateway.exe which make up the node. Note: When running on your laptop as a dev environment you essentially just run multiple instances of these executables which show up as multiple nodes. An application package that references the service packages for each service type are copied to the image store. Once the package has been copied you can create an instance of the application within the cluster by specifying the type. The application type instance is then assigned a URI name of “fabric:/MyNamedApp“. Within the cluster you can create multiple named applications, each of which are managed and versioned independently. Named services instances are created under its named application which looks like “fabric:/MyNamedApp/MyNamedService“. During the named service creation you specify a partition scheme which spreads across cluster nodes allowing for scale. Within a partition stateless named services have instances while stateful named services have replicas which are kept in sync. Should a replica fail, Service Fabric builds a new replica from existing replicas. In addition, during named service creation, code, data and configuration packages are copied to the node(s) running the service where they can be used. You can create two types of service:
- Stateless: use when persistent state is not required or using external storage
- Stateful: use when persistent state is required. Uses Reliable Collections or Reliable Actors programming models.
Service Fabric Architecture
The diagram below shows the major subsystems of Service Fabric with a brief description of each.
- Transport Subsystem – provides secure communication between nodes
- Federation Subsystem – creates cluster of nodes into single entity for detecting failures, perform leader election, and provide consistent routing
- Management Subsystem – manages lifecycle of applications and services
- Testability Subsystem – help devs test services through simulated faults before and after deploying applications and services to production
- Communication Subsystem – resolve service locations
- Reliabilty Subsystem – responsible for reliability through replication, resource management and failover
- Hosting and Activation – manages lifecycle of an application on a single node
- Application Model – enables tooling
- Native and Managed APIs – exposed to devs
Service Fabric is being termed the next-gen platform for building and managing cloud-scale applications. If you are interested in seeing how this works or even deploying Service Fabric, stay tuned for the next post in this series where we will Deploy Service Fabric.