Service Fabric Service Types

The model for Service Fabric allows for flexibility when it comes to designing the individual services, giving you the ability to pick the right programming model for each service. Deciphering the multiple options can be complex and really depends on each scenario and service you are building. Here I will try to break down the options how I see them. Please leave feedback if it was helpful or you think of options in a different way. Remember every application is composed of many services and each service will likely have a different programming model so assess each service individually.

Service Types

There are two main types of services you can build with Service Fabric:

One of the real advantage of using a platform like Service Fabric is when you begin to leverage the power of Stateful services. But Stateful services takes a bit of a mind shift in the way we think about building applications so let’s look at stateless applications first then move onto the stateful service approach.

Once you have decided whether you are building a Stateful or Stateless service you can then choose from multiple types of programming models to help you build you services:

Stateless Services

Stateless services are a familiar paradigm in most web development. You typically have a middle tier layer that receives requests and then calls out to a database where the state is stored. When those requests to the data store are expensive there is often a caching mechanism in place. Since there is no state maintained inside the service a request can be routed to any instance of the service. A typical application using stateless services looks like:

stateless application [modified image from https://github.com/Azure/azure-content/blob/master/articles/service-fabric/media/service-fabric-application-scenarios/AppwithStatelessServices.jpg]

It is important to note that the above diagram only uses stateless services. Inside a service fabric application you will typically have a combination of stateless and stateful services.

Stateless Application Use Cases

Typical use cases for a Stateless Application are:

Stateless Service Fabric Programming Models

The Service Fabric Programming model that you might use depends on the specific use case. A few guiding tips:

Stateful Services

Stateful services are different from Stateless services in the fact that the data is stored on the same machine that the service is running. There is no external data store. This removes the need for additional layers like caches and queues, simplify the service. The latency in the system drops because the data can be retrieved without additional network calls to the external store. A diagram says it all (be sure to compare this to the diagram of a stateless application):

stateful application [modified image from https://github.com/Azure/azure-content/blob/master/articles/service-fabric/media/service-fabric-application-scenarios/AppwithStatefulServices.jpg]

Now that the data is on the same machine as the service, if the machine failed then you would lose all the data but this is not the case with Service Fabric. The Service Fabric runtime manages the reliability of the state for you so you do not have to worry about machine failures. The way the reliability is accomplished using replicas is fairly complex and ultimately you don’t have to think about it to much but I do recommend that you learn how the reliability of your data is ensured so you can understand some of the considerations you need to take in place. A great introduction is in the video Building MicroServices with Service Fabric.

Another reason the Stateful approach to services is powerful is because now you remove the need to translate between your conceptual model and data model (multiple rows and tables in the case of a SQL database). This simplifies your programming model and enables you to work in one mental model with out worry (to much) about how it is stored in the database. This is achieved through the Reliable Collections IReliableQueue and IReliableDictionary interfaces.

Use Cases

Typical use cases for a Stateful application are:

Stateful Service Fabric Programming Models

The Service Fabric Programming model that you might use depends on the specific use case. A few guiding tips:

Conclusion

There are two main types of services that can run inside Service Fabric. The first being Stateless services where state is stored in external service. This is the familiar way to build services and applications today. In the stateless applications you can either bring your own service or build one using the Service Fabric API’s that let you tie into the Service Fabric runtime. Tying into the runtime allows you to begin to leverage the platform to get more insight into your services.

The second type is a Stateful service where the data is co-located with code that runs the service reducing latency and reducing service complexity. There are currently two models for building Stateful services: Reliable Service and Reliable Actors. By choosing a Stateful service you are beginning to tap into the Service Fabric platform which goes beyond service orchestration.

Hope that was a helpful break down of the services. Let me know in the comments or tell me how you view the options for building services in Service Fabric.

Comments

comments powered by Disqus