What does Lambda and Actor Models have in common?


Every software engineer should learn about the Actor Model, even if they don't work with Erlang, Elixir or Akka. It opens up your mind to a new way of thinking about computation and concurrency.

And what better way to learn than to hear from its inventor, Carl Hewitt (R.I.P)? This conversation between Carl, Erik Meijer (of the Rx fame) and Clemens Szyperski is a must-see!

video preview

An actor is the fundamental unit of computation which embodies the 3 things – processing, storage and communications – that are essential to computation.

Actors come in systems, and they have addresses so that one actor can send messages to another actor.

Every actor has a mailbox, and when an actor receives a message, it can:

  • Create new actors
  • Send messages to actors it has addresses for
  • Decide how to handle the next message it receives (e.g. state)

Multiple messages might arrive in the mailbox at the same time, but they are processed one at a time. An arbiter decides the order in which these messages are processed.

So, inside the body of an actor, there is no concurrency because messages are processed one at a time.

The best way to experience the Actor Model is to spend time with Erlang, Elixir or Akka. F#'s MailboxProcessor also implements a similar idea.

Looking beyond code, you can also see the same pattern in AWS Lambda! Where a Lambda execution environment handles only one event at a time, and concurrency is managed at the platform level.

Master Serverless

Join 17K readers and level up you AWS game with just 5 mins a week.

Read more from Master Serverless

Lambda Durable Functions makes it easy to implement business workflows using plain Lambda functions. Besides the intended use cases, they also let us implement ETL jobs without needing recursions or Step Functions. Many long-running ETL jobs have a time-consuming, sequential steps that cannot be easily parallelised. For example: Fetching data from shared databases/APIs with throughput limits. When data needs to be processed sequentially. Historically, Lambda was not a good fit for these...

Step Functions is often used to poll long-running processes, e.g. when starting a new data migration task with Amazon Database Migration. There's usually a Wait -> Poll -> Choice loop that runs until the task is complete (or failed), like the one below. Polling is inefficient and can add unnecessary cost as standard workflows are charged based on the number of state transitions. There is an event-driven alternative to this approach. Here's the high level approach: To start the data migration,...

Lambda Durable Functions comes with a handy testing SDK. It makes it easy to test durable executions both locally as well as remotely in the cloud. I find the local test runner particular useful for dealing with wait states because I can simply configure the runner to skip time! However, this does not work for callback operations such as waitForCallback. Unfortunately, the official docs didn't include any examples on how to handle this. So here's my workaround. The handler code Imagine you're...