Stateful Services
One important pattern we need to implement for high-performing services is the colocation pattern. Colocation means that the data needs to be as close as possible to the service to avoid latency when accessing the data. In addition, the data is usually partitioned to avoid too much traffic on a single data store, which then becomes a bottleneck.
This is exactly where we can use stateful services in Service Fabric. Think of stateful services as those where the data is partitioned and colocated directly within the service itself. Service Fabric ensures reliability of data through replication and local persistence.
There are three important concepts when it comes to stateful services replication.
• Partition: A partition is a logical construct and can be seen as a scale unit that is highly reliable through replicas, which are spread across the cluster.
• Replica: A replica is an instance of the code of the service that has a copy of the data. Read and Write operations are performed at one replica (called the Primary). Changes to data due to write operations are replicated to multiple other replicas (called the Active Secondary replicas). This combination of Primary and Active Secondary replicas is the replica set of the service. Service Fabric places each replica in a set on a different node across fault and upgrade domains in the cluster to improve scalability and availability. It also redistributes them in the case of a cluster scale-out or scale-in to ensure an optimal distribution.
• Replication: Replication is the process of applying state changes to the primary and secondary replicas. A replica is an object that encapsulates the state of a failover unit. In other words, it contains a copy of the services code and the state. All replicas that back up a stateful service build a replica set. Service Fabric places each replica in a set on a different node across fault and upgrade domains in the cluster to improve scalability and availability.
Figure 8.6 shows a cluster with two partitions and their replicas spread across the nodes.
So how does this work practically? Let’s assume we have implemented a stateful service that calculates the digits of PI. In this case, Service Fabric would create a primary replica on some node (say Node 1) and secondary replicas on other nodes like Node 2 and Node 3. The primary replica receives all reads and writes, in our case the calculated digits and the state of the execution, and synchronizes the state with the secondary replicas. In case Node 1 goes down, it would automatically failover to one of the secondaries. As each secondary contains the state, the service could continue with the calculation once the new primary, for example Node 2, is up and running. As soon as Node 1 is up again it will be made a secondary. That sounds like a lot of work and we might wonder what we need to do as developers? The good news is that we need to do nothing as Service Fabric handles all this for us.
This article provides detailed information on how to partition stateful services: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-concepts-partitioning/.
Besides resiliency and performance, we gain some more advantages when building stateful services. First, we can eliminate dependencies on external systems and with that reduce potential points of failure. Second, we do not need to implement all the code for accessing external systems, including retry handlers, and similar items. Third, we can reduce the number of components such as Cache we had to use in a traditional three-tier architecture. Fourth, it makes it a lot easier to deploy a complete system in a development environment because there are fewer external dependencies to manage.
Now that we know what kind of services and applications we can build in Service Fabric, we can have a look at the programming models. Service Fabric has two main programming models.