Service fabric Stateful service - Scaling without partitioning?

Question

I am planning to migrate my existing cloud monolithic Restful Web API service to Service fabric in three steps. The Memory cache (in process) has been heavily used in my cloud service.

Step 1) Migrate cloud service to SF stateful service with 1 replica and single partition. The cache code is as it is. No use of Reliable collection.

Step 2) Horizontal scaling of SF Monolithic stateful service to 5 replica and single partition. Cache code is modified to use Reliable collection.

Step 3) Break down the SF monolithic service to micro services (stateless / stateful)

Is the above approach cleaner? Any recommendation.? Any drawback?

More on Step 2) Horizontal scaling of SF stateful service

• I am not planning to use SF partitioning strategy as I could not think of uniform data distribuition in my applictaion.
• By adding more replica and no partitioning with SF stateful service , I am just making my service more reliable (Availability) . Is my understanding correct?
• I will modify the cache code to use Reliable collection - Dictionary. The same state data will be available in all replicas.
• I understand that the GET can be executed on any replica , but update / write need to be executed on primary replica?
• How can i scale my SF stateful service without partitioning ?

• Can all of the replica including secondory listen to my client request and respond the same? GET shall be able to execute , How PUT & POST call works?

• Should i prefer using external cache store (Redis) over Reliable collection at this step? Use Stateless service?

Answer 1

This document has a good overview of options for scaling a particular workload in Service Fabric and some examples of when you'd want to use each.

Option 2 (creating more service instances, dynamically or upfront) sounds like it would map to your workload pretty well. Whether you decide to use a custom stateful service as your cache or use an external store depends on a few things:

• Whether you have the space in your main compute machines to store the cached data
• Whether your service can get away with a simple cache or whether it needs more advanced features provided by other caching services
• Whether your service needs the performance improvement of a cache in the same set of nodes as the web tier or whether it can afford to call out to a remote service in terms of latency
• whether you can afford to pay for a caching service, or whether you want to make due with using the memory, compute, and local storage you're already paying for with the VMs.
• whether you really want to take on building and running your own cache

To answer some of your other questions:

• Yes, adding more replicas increases availability/reliability, not scale. In fact it can have a negative impact on performance (for writes) since changes have to be written to more replicas.
• The state data isn't guaranteed to be the same in all replicas, just a majority of them. Some secondaries can even be ahead, which is why reading from secondaries is discouraged.
• So to your next question, the recommendation is for all reads and writes to always be performed against the primary so that you're seeing consistent quorum committed data.