31

I am new to Azure Service Fabric and the biggest questions I have are

  1. When should I use reliable actors? Give me practical examples please.
  2. When should I use reliable services? Give me practical examples please.
Super Jade
  • 5,609
  • 7
  • 39
  • 61
spdev
  • 361
  • 3
  • 9

2 Answers2

23

Taken a look at the differences:

  • State analogy : Actors work on a single instance of an object graph. Services usually have state for multiple callers.
  • Scope : Actors can’t work alone, because of their size (more like objects).
  • Life-cycle : Actors are only active when used, so more will fit on your available server resources
  • Concurrency : Actors enforce single threaded access
  • State : Actors just modify the aggregate, services work on sets so often use transactions on sets for ACID behavior.
  • Communication : Actors communicate through channels provided by the platform. Services may choose otherwise.
  • Access : Actors in the cluster can’t be reached from the outside by default. You’ll probably need a Service that provides access.

Samples when to use an actor:

  • For every user of your mobile app you could have one actor.
  • For every thermostat that sends information to your application you could have one actor.
  • For every customer of your e-commerce site, you could have one shopping-basket actor.

Create a service in the cases that you are probably used to. Create a reliable service that provides a service for multiple users at once. For example a weather service.

Pascal Naber
  • 1,092
  • 8
  • 14
  • thanks for this, so lets say if I were developing a simple book inventory online application, what would be the services and what would be the actors? – spdev Apr 06 '16 at 08:41
  • Quite hard to say without more context. Can end-users hire or buy books? What's the business-case? When you have functionality for end-users, you could have an actor per end-user. Maybe even per book, but it depends. – Pascal Naber Apr 06 '16 at 12:40
  • The note about scale isn't true. Reliable Actors is a framework on top of Reliable Services so they scale exactly the same way. Actors are limited by server resources the same way that Services are. – Vaclav Turecek Apr 06 '16 at 18:41
  • 1
    About the samples you give, yes you can model those problems that way. But you'll need a separate storage mechanism for querying if you want to answer questions about your data, like: "show me all mobile users from Seattle" or "get me all thermostats set to 25 degrees or more" – Vaclav Turecek Apr 06 '16 at 18:48
  • Thanks Vaclac, i've corrected the overview regarding scale. About the Actor samples. Yes, when you choose to solve a problem with Actors which represent a single object, like a thermostat, there are consequences for data that covers multiple actors. – Pascal Naber Apr 08 '16 at 07:10
  • I am confused about the Actor Partition, if you use the example, "For every user of your mobile app you could have one actor." then the Node(s) that contains that Partition(s) has to scale. If the only thing the Node has is that Actor Partition, that would be ok, but if there are other things in that Node, the seems counter intuitive to the scaling. Or it seems like scaling within scaling. Actor Partition scales Actor inside a Node which is also scaled. – jmbmage Oct 24 '16 at 17:27
7

I don't mean to use a word to define itself, but use Reliable Actors only if you've determined your problem fits the actor design pattern. Actors are a design pattern much like many of the Gang of Four design patterns. If your problem fits one of the patterns, use it. If it doesn't, it's best not to try to shoehorn your problem into the wrong pattern.

In Service Fabric, Reliable Actors are an implementation of the Virtual Actor pattern. It has certain rules of operation and caveats that go with them. This is a good doc to read to get an idea of how the Reliable Actor framework works and whether or not it meets your requirements: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-actors-platform/

Reliable Actors are in fact just a framework built on top of Reliable Services, so all the same scaling, partitioning, and distribution rule apply.

Super Jade
  • 5,609
  • 7
  • 39
  • 61
Vaclav Turecek
  • 9,020
  • 24
  • 29
  • 1
    What would be problems that will fit in actor design pattern? – stack247 Aug 17 '16 at 16:26
  • 15
    It's funny, no one on the internet can give a clear, concise, real world example of why you would use a service vs an actor. I've read the documentation and the wikipedia article on actors and I'm still utterly confused. – The Muffin Man May 05 '17 at 04:50
  • 1
    I believe this will help you greatly https://stackoverflow.com/questions/4493001/good-use-case-for-akka TL;DR when you need high concurrency plus state isolation, you need actors. Also if your service is managing a entity that undergoes a complex state machine transition where every branch out requires isolation, Actors are a superb fit – Megha Feb 01 '19 at 05:42