In this episode, I introduce the Actor Model as a Design Pattern that can offer faster and more efficient processing by managing state in memory. I discuss potential use cases for the Actor Model, such as in online gaming and IoT sensors, but acknowledge that it is a different development model than traditional approaches.
Or listen at:
Published: Wed, 24 May 2023 15:52:17 GMT
Transcript
Hello and welcome back to the Better ROI from Software Development Podcast.
In last week's episode, I introduced you to the idea of Design Patterns - a generally reusable solution to a commonly occurring problem. In the episode, I explained what a Design Pattern was and why they're ubiquitous in our everyday life. I also went into their use within software development and how they can provide higher quality and greater understanding when we are working with code.
In this episode, I wanted to pick up on a specific design pattern - mainly due the fact I've got a current interest here and I'm trying to research it and understand it - the Actor Model.
So why do I want to talk about the Actor Model?
Firstly, most Design Patterns within software development aren't really a great subject for a podcast. They're quite in depth and deeply technical, and probably not for this audience. However, the Actor pattern is something different. I think there's something quite interesting in it and something I wanted to talk about in this episode.
At its heart, the Actor pattern is a way of modeling behavior within a computer system, but it does this in a different way than I've traditionally seen used. Thus, I think there's some real opportunity potentially for future use within projects, and it may actually be a direction of flight within the actual software development industry.
So let's talk about what the actor model is. Wikipedia describes the actor model as:
"The actor model in computer science is a mathematical model of concurrent computation that treats an actor as the basic building block of concurrent computation. In response to a message it receives, an actor can: make local decisions, create more actors, send more messages, and determine how to respond to the next message received. Actors may modify their own private state, but can only affect each other indirectly through messaging"
Now, it may not be obvious from that description why I'd want to talk about it in this podcast.
The main reason I wanted to bring up in this podcast is because it introduces a different way of thinking about how we develop our systems. In the Wikipedia description, you might have noticed the use of the word "state".
What is state? State is our data that we're acting upon. Normally within software development, we will store that state in a database- somewhere we will store, whether it be an order, an invoice, product description, a blog post. We store that away in some form of database storage or even to a flat fike - we store that somewhere. Even a Word document gets stored as a file.
Now, most software development works on the principle of hydrating that saved data and making it usable.
So say for example, we wanted to make a change to an order; the request comes into the system, the system then has to go and look that data up, it has to understand it, and then make the amendment that we've requested, save it back, and then let us know that the event was successful.
The Actor Mmodel changes that slightly. It is responsible for its own state, which is generally held in memory. So rather than having to go back to a database to make a change, we making this change in memory, which is inherently so much faster by cutting out the need to go firstly to the database, retrieve that data from the database, interpret that data, understand it, and then write it back to the database after changes.
This approach is considerably faster and has a much lower overhead. Thus allowing the running of many, many Actors within a relatively small computational space, a relatively small system. And by having that capability, it allows us to then scale considerably because we have much lower overheads and we are getting much more computational return on our equipment - we are able to scale to hundreds of thousands of actors at any one time.
So this represents a great opportunity for anywhere where we need to have hundreds of thousands of digital representations of something.
The Actor pattern has been used a great effect within online gaming, for example, where each player has their own individual Actor to represent their current state, you know, score lives, what equipment they're carrying, how far through they are in the game. It allows for a very large amount of data that can be held and maintained in separate discreet chunks.
Another great example is digital twins. A digital twin is a virtual representation that serves as a real-time digital counterpart of a physical object or process. So take for example, Internet of Things sensors - while you could have hundreds of thousands of physical sensors, then being able to represent them digitally as a digital twins. Actors are an exceptionally good use case for that because of their ability to manage their own state and run a very low overhead. And by having that digital twin of a physical object, it means we can interact with it much easier.
It'd be almost impossible to go and ask the current state of a hundred thousand IoT sensors. It just wouldn't be practical. Some wouldn't be connected to the network at the time. Some will be just too slow to respond. It would take a considerable period of time, and by the time you've got the end result that the original results are probably out of date.
Whereas an Actor will allow its physical counterpart to send it messages. The physical counterpart can send those messages as appropriate when it has connection to the network. And as relevant events occur, maybe a change in temperature, it sends those events to the Actor. The Actor can then update its own internal representative state. Thus, if we want to know the state of our hundred thousand sensors, we have that digitally in memory within our digital twins, and thus can report and understand where we are.
It also allows for excellent computation in terms that each Actor can then be responsible for monitoring and making changes to its physical counterpart. For example, if the physical sensor sends temperature readings, the actor can be aware of what is good and what is bad. Thus, when it receives a temperature reading outside of his expected range, it can then choose what to do with it - now, this might be simply sending another message onto another actor to alert that this may be a problem, it may be an automated request to make some change to the environment in which the sensor is maybe turning down the air conditioning.
And by representing our physical product as a digital twin, it allows us to think as a software development much more around what it is trying to achieve and how it behaves, making it a much easier task to actually develop and test completely.
So let's take a bit of a step back for a second.
I talked about the Actor model in terms of us being a Design Pattern. I suspect many of my colleagues would disagree with me that it is actually a Design Pattern. However, for me, it provides a common solution to a common problem for me. However, it is a common solution to a common problem, it allows us to model hundreds of thousands of entities that could represent switches, sensors, gamers - all while keeping the cognitive load understandable, and the overheads of actually running the system manageable.
I would however agree that the Actor pattern is a different scale to most Design Patterns. In the case of most Design Patterns, you can think about them being the size of a house brick, whereas an Actor model is more akin to an entire housing state, including roads, utilities, and facilities.
And conceptually, you can think of Actors as being very similar in benefit and thought process to microservices. It's a way of splitting up the work into smaller chunks so that it's easier to build, develop, and think about. And by doing this, the substantial productivity benefits are there as well.
However, because our Actor Model is akin to an entire housing estate, including roads, utilities, and facilities, it would be incredibly impractical and a massive undertaking to develop your own from scratch. Luckily, there are platforms available to help us do this. Many of the platforms available can help also provide us with capabilities such as resilience and distribution, allowing us a level of resilience and redundancy so that we're in a position to be have a reliable and safe system.
The downside to the actor model is that it is a different development model to the traditional.
Traditionally, we are used to having our software go and retrieve data from the database and then interpret it in a certain way. We've been doing that for many, many years - switching to this different way of thinking, and the paradigms that come along with it, may be difficult to take on.
The Actor Model isn't new. It was originally developed back in 1973, but it's still not really seen much in mainstream development. While there are a number of the Actor platforms that I talked about earlier, I've been around for a while and I've only recently started to look at it and even then not in production, and I've got a 30 year career.
That being said, I think there is a growing influence of the Actor Model in mainstream services. I'm seeing Actor principles starting to appear in mainstream services from AWS and Microsoft Azure. Thus, it feels as if it's on the cusp of mainstream adoption.
So is the actor model useful for you? Short answer is, it depends.
There are certainly really good use cases for it. Anywhere where you need to model and understand hundreds of thousands of things at any one time - take for example, our online gamers or monitoring hundreds and thousands of IoT sensors - they're a really good candidate.
It's certainly something to ask your a development team to look at if what you are trying to do is create the idea of digital twins - if you're trying to keep a copy digitally that represents either a cognitive concept or a physical product.
Thank you for taking the time to listen to this episode. I look forward to speaking to you again next week.