From the first days of computing applications of all kinds, they have faced growing demands for processing increasing volumes of data within diminishing processing times. Up until recently, these challenges were addressed by scaling applications vertically, by adding more memory and higher speed processors. This approach was possible because of growing processor speed, which is described by Moore's law as the following:
But the pace of advancement in hardware started to slow down, as stated by Intel in 2015. This trend made it obvious that the only way to scale applications from now on was via horizontal scalability—by increasing the number of processing cores and machines which are to process data in parallel by using multiple application threads. Two obvious challenges in this situation are as follows:
- To prevent concurrent modification and, as a result, corruption of data
- To provide access to the data for processes running on different cores or machines
The first challenge is traditionally solved by using shared memory and different locking approaches. Unfortunately, this approach effectively makes the parts of the application that are synchronizing with each other pseudo-sequential, which in turn limits possible speedup in accordance with Amdahl's law:
The most important corollary is that the speedup is limited by the serial part of the program.
Fortunately, there are other solutions that make it possible for different parts of the program to work together toward the same goal in parallel. One of these approaches is the actor model. Fortunately, the actor model also addresses the second challenge with a concept known as location transparency.
The concept of actors was first introduced in 1973 by Carl Hewitt, Peter Bishop, and Richard Steiger.
The idea is that everything is represented as an actor, which is a basic computational entity. Actors communicate with each other using messages. In response to a message, an actor can undertake any of the following actions:
- Send a finite number of messages to other actor(s)
- Create a finite number of other actors
- Change its behavior for the next message to be processed
This definition is quite abstract, but already allows you to recognize a couple of constraints that the implementation must satisfy:
- Actors communicate using messages and are not allowed to expose or inspect the internal states of each other.
- A shared mutable state has no place in the actor model.
- Side-effects are not mentioned in this definition, but they are obviously the end goal of any system. Therefore, an actor's response to the message might be any combination of the following:
- Changing internal state
- Modifying behavior
- Producing side-effects
- Actors need to be able to address each other. Consequently, a naming system is expected to exist. Having an appropriate naming system is a prerequisite for location transparency, meaning that every actor can be addressed by some canonical name regarding its actual location.
The preceding definition also leaves the following questions unanswered, among others:
- What would be an effect of the limitations of the underlying hardware, operating system, and runtime environment?
- Where do actors coexist and how is the first actor created?
- How are messages delivered from one actor to another?
- Are actors mortal, and if yes, how do they die?
The most prominent languages that use the actor model are Erlang, Io, D, Pony, and Scala.
We will take a closer look at the Scala implementation—Akka—by building an enterprise bakery application. Our bakery will be crowded by different actors, each with their own responsibilities, producing cookies as a result of their teamwork.