writes: The Actor Model is a theoritical computation model which aims is to improve concurrent computing. In essence, Actors are 'processes' that can receive, process and send messages to other Actors. This
is a computation model that is not based on shared memory and opposes the traditionnal shared memory, locking and multithreading model. In terms of hardware architecture, the multithreaded model aims at powerful servers few CPUs and shared memory whereas the actor model aims for concurrent processing on many computers cooperating through reliable networks links.
To my profane eyes, there are little theoritical differences between object model and actor model. But I am no academics and the intent here is to throw some practical views on the possible benefits that programmers can draw from actor based programming.
One has to admit that the original vision of many computers cooperating through networks did not materialize yet. The dominant model is a cloud of powerful cooperating servers providing online services to smart terminals through network. Multithreaded programming is the mainstream way of developping server side software.
However, there are some trends in computing that may be game changers. These are:
- the 'cloud' or flexible computing where server-side applications are hosted on virtual machines
Multiple 'instances' of the same application can be created on demand to cope with load surge. Context information is shared through add-ons such as memcached or databases. Advanced realtime web applications such as facebook use message and notifications and look like good candidate of actor based implementations.
- the Internet of Thing where multiple devices with low processing power coordinates over a local area network and through the Internet. Again, this matches nicely with actor model purposes.
- finally, server side applications such as HTTP servers are put under pressure by growing users bases. The 10K user problem well documented for web servers, occurs in any big server-side application. Adding more processors to cope with load does improve performance linearly as processes or threads spend more and more time to wait for locks when accessing critical ressources. The actor model provides a 'lock free' alternative that can overcome this issue.
Several programming frameworks and languages provides very good ways to implement actor based software. Three of them come in mind:
- Erlang, a language developped by Ericsson and open sourced or Elixir that provides a friendlier language syntax but produce bytcode that is compatible with Erlang VM.
- Scala a language that produces java compatible bytcode. It is used in the famous Minecraft game
- The C++ Actor Framework brings the actor model into native code.
Erlang and Scala merge functional programming with actor model and that has a solid consequence: developpers can only assign variables once and cannot change the value. The only way to change a variable is to send a new messsage (or to call a function) with new arguments. This is a radical way to prevent any use of memory sharing but this breaks most of the classical programming techniques: loops needs to be implemented by recursive function calls or can be replaced with more functional equivalents.
Let's focus now on server side application development, especially in telecommunication field where protocol exchange is
the main purpose. Intuitively the actor model fits perfectly . However the majority of telecommunication apps are still developped in classical C/C++ with scripting languages or in Java (SIP servlet). But Actors make four important promises:
- I shall not fail: Telco applications should always be on. With the OTP framework, Erlang provides a radical way to recover. If an actor detects an error condition, it can crash and be restarted. Dependant actors will be nicely notified about the restart. Application can partially crash and restart limiting the impact to a single user. Erlang also supports code replacement without application stop. I did not test it first hand but if proved, this is a tremendous advantage in telco business.
- I will not block: by design, actor model is lock free. This remove one of the worst nightmare of any server side application developpement.
- I can scale: actor model breaks downs a piece of software into a set of coordinated actors that do not share any memory. They exchange messages transparently and therefore can be very easily spread on several hardware system. Traditionnal approach implies communication context sharing that was never fully scalable.
- I am a finite state machine: That concept is not enough understood while it is central to build robust and resilient telecommunication applications. actor model is about exchanging message. The actor framework provides a natural way to map messages into function calls and implement FSM easily.
So ... why the telecom world is not rushing to embrace actor based programming ?
Its because it requires major cultural changes and telco world is a bit conservative.
- Software needs to be entirely redesigned into actors that are simple and pipelined.
- Developpers need to give up any use of shared memory to store a "communication context".
- no more control on lock and threading
- Langages such as Erlang and even C++ Actor framework uses a syntax that is so different from procedural approach that the learning curve is very steep. Almost hostile.
All this is much more radical than moving from init scripts to systemd on Linux. And this transition is costly: training developers, software redesign and reimplementation.
Is it worth it ? That is a question we are asking ourselves