Now the ordering of lessons in this section is very deliberate. The next lesson, this lesson, on the Actor Model would be a lot harder to understand without having a firm grasp of state as a concept. So now that we know what it means to be stateless or stateful, we can apply these ideas to particular programming paradigms. The paradigm under discussion here is something called the Actor Model, which is a design pattern. 

Again, if you're a seasoned programmer, you're probably already familiar with this, so bear with me. So let's start by defining the most important term here, actors. With the Actor Model, what is an actor? The best way to think of it is to think of actors as computational units. This is kind of similar to how object-oriented programming, they say everything is an object, right? Well for the Actor Model, our basic unit is an actor. So now everything is an actor. So what do these actor units do? Actors do only three things. They can receive messages, they can send messages, and they can create new actors. Azure describes this in their implementation of Reliable Actors as "Isolated independent units "of compute and state with single-threaded execution." Now, this is important. The fact that actors can communicate with one another and sort of copy themselves, create more actors on their own, makes the Actor Model particularly well suited for concurrency and message-processing systems. 

That's kind of the high level and the thing very important to remember is that, as with any design pattern, the most important thing is to know when to make use of it. If you've ever been steeped in the world of Java development and design patterns, you might know how painful it is to deal with things like Singletons or Abstract Factories when the paradigm doesn't suit the problem. You end up with a lot of spaghetti code basically. The Actor Model, like any other paradigm, is just another tool. It's not a fix-all for every situation. 

What you should ask yourself is, when does it make sense to use the Actor Model? Microsoft offers some good rules of thumb in their documentation. They recommend you ask yourself these three questions. One, does my problem entail many isolated units of computation and state? Two, does my problem require mostly single-threaded objects that don't need a lot of interaction with external systems? This is probably the most important consideration. How many different things are you talking to? Are single-threaded objects going to work? And then three, does my problem entail a lot of blocking calls from unpredictable I/O operations? So the level of consistency with your I/O is really really important to how efficient the Actor Model is gonna be. 

Now, these are kind of abstract questions to ask, but they do get at the heart of when and where the Actor Model is going to do the most harm or the most good. We'll include some links with some additional info and examples if you want to break that down into actual software. 

Now Service Fabric, for its part, they offer their own implementation called Reliable Actors. You'll have access to this class once you incorporate the library into your language of choice. They currently support C Sharp and Java. Service Fabric Reliable Actors offer a number of helpful features. 

So this is an API, this is class, specifically. Now for one, Reliable Actors are highly resilient because they run inside of something called the Actor Service. This is an Azure stateful Reliable Service responsible for distributing actor instances across partitions and nodes. Stateful Reliable Service, keep that in mind. We talked about state. This is a tool that makes Reliable Actors reliable. So what it means is that because it's running with a Reliable Service scaled across nodes, if a node fails, the service will automatically migrate actor instances to healthy partitions within healthy nodes. By default, actors are distributed randomly across partitions within your cluster. However, it is possible to deliberately control which actors go to which partitions, should you need to do so. 

So, with Azure Reliable Actors, you get strong partition tolerance. You get resilience due to Service Fabric's distributed nature. And you get basically, the most efficient, recommended approach to implementing the Actor Model within Azure, whether it's Service Fabric or some other paradigm. That's basically all there is to say about the Actor Model. 

Now that we've covered it, we can move on and talk about collections. Collections are very relevant to actors. Please take heed in the next section if you're a little unsure about collections in this context. If you're ready, we'll see you there. Bye.