Service Fabric (continued) 

Part 2 compared Paxos and Raft. Part 3 discussed SF-Ring. This article continues the discussion on Service Fabric with it support for microservices. Microsoft Azure Service Fabric is a distributed systems platform to package, deploy, and manage scalable and reliable Microservices and containers while supporting native cloud development. Service Fabric helps developers and administrators to focus on the implementation of workloads that are scalable, reliable and manageable by avoiding the issues that are regularly caused by complex infrastructures. The major benefits it provides include: deploying and evolving services at very low cost and high velocity, lowering costs to changing business requirements, exploiting the widespread skills of developers and decoupling packaged applications from workflows and user interactions.

SF provides first-class support for full Application Lifecycle Management (ALM) of cloud applications, from development, deployment, daily management, to eventual decommissioning. It provides system services to deploy, upgrade, detect, and restart failed services; discover service location; manage state; and monitor health. In production environments, there can be hundreds of thousands of  microservices running in an unpredictable cloud environment. SF is an automated system that provides support for the complex task of managing these microservices.

An application is a collection of constituent microservices (stateful or stateless) in Service Fabric. Each of these performs a complete and standalone function and is composed of code, configuration and data. The code consists of the executable binaries, the configurations consist of service settings that can be loaded at run time, and the data consists of arbitrary static data to be consumed by the microservice. A powerful feature of SF is that each component in the hierarchical application model can be versioned and upgraded independently.

Service Fabric distinguishes itself with support for strong consistency and support for stateful microservices. Each of the SF components offer strong consistency behavior. There were two ways to do this: provide consistent – build consistent applications on top of inconsistent components or use consistent components from the grounds-up. The end-to-end principle dictates that if performance is worth the cost for a functionality then it can be built into the middle. If consistency were instead to only be built at the application layer, each distinct application will have significant costs for maintenance and reliability. Instead if the consistency is supported at each layer, it allows higher layer design to focus on their relevant notion of consistency and allows both weakly consistent applications and strongly consistent applications to be built on top of Service Fabric. This is easier than building consistent applications over an inconsistent substrate.

Support for stateful microservices that maintain a mutable authoritative state beyond the service request and its response is a notable achievement of Service Fabric. Stateful microservices can demonstrate high-throughput, low-latency, fault-tolerant online transaction processing services by keeping code and data close on the same machine. It also simplifies the application design by removing the need for additional queues and caches.