Imagine

The year is 2030+. CPU technology has advanced to the point where machines have CPUs with thousands of cores. How would you take advantage of that number of CPUs? You could just divide up work with thousands of threads all stepping on each other trying to access common resources. Concurrent locks and barriers would number in the millions. So, it's time to regroup. Here we exploit the Actor Model. (look it up or just read on). An idealized actor could exist on its own little “island” including a processor, an operating system, its own disk storage, and a network connection. It would have a unique “address” such as a URL. It would have an “inbox” that other actors could send messages to. Our actor would process messages, one-at-a-time. The actor would also have an “outbox” which would then send messages on to other actors. Each of these actor-machines would be independent of the others. Thousands, or even millions of these Actors all humming away without concern about concurrency. Think of this as the ultimate in a scaleable design.

Now, you might be thinking that it could be problematic if each of these millions of actors needed to establish a connection to a database. And you would be correct. So, Sodacan doesn't do it that way. The Actor model combines data and behavior together on each of these Actor islands. Actors in Sodacan include “big” actors such as an employee list. And, small actors such as an individual employee. Or, a controller for an IOT device. An actor can even be tiny and short lived such as a single HTTP request.

And now back to reality. It's not 2030 yet, but the march is on. Sodacan takes a measured approach to future technology. Without getting into details, a simple configuration setting will control how many actors run on a particular island. Another configuration setting determines how many replicas of an Actor need to be maintained to make the system durable and available. So, as the compute environment progresses, Actors do not need to change, only configuration, because they are already designed and implemented at the smallest practical granularity.

Assumptions

The following is a summary of assumptions about the Sodacan framework. They are explained in more detail elsewhere:

  • In Sodacan, Actors really are isolated from other Actors. No locking and blocking needed.
  • Each actor has its own private storage, if it needs storage. Sodcan handles persistence of this data transparently and reliably.
  • An Actor can and often does move around in a cluster. The movement of an actor, including its persistent data, is handled by Sodacan.
  • Messages are the only way Actors can talk to each other. Sodacan facilitates the full lifecycle of messages including keeping track of where in the cluster a particular Actor is active.
  • Sodacan maintains replicas of Actors for hot, warm, and cold backups.
  • Sodacan is a peer-to-peer network. No broker-intermediary between Sodacan Hosts.