Service fabric Stateful service - Scaling without partitioning?

0
votes

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?

1
azureazure-service-fabricservice-fabric-stateful
My recommendation after using with SF for a year is.. unless you have sufficient resources and a very capable team, just don't. It's way too immature as a platform and massively overkill for a lot of applications. Take things slow. Spin up two instances of your app and put them behind a load balancer. See how that fairs up, then look at moving some of your hot read data to redis. Fwiw reliable collections are more CA than P. Using SF just to make use of a distributed dictionary as a cache is a bit of a poor choice imo – Mardoxx
Another question: for what reason is your REST api stateful? – Mardoxx
Thanks Mardoxx. REST API is stateless. But we have used in-process cache (Memory cache) for hot data for data latency. You are right we are planning to use distributed dictionary as cache to store in-process cache data. – Ashish

1 Answers

1
votes

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.