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! 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:
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 16K readers and level up you AWS game with just 5 mins a week.
A common challenge when building APIs is supporting multiple live versions without letting the system turn into an unmaintainable mess. You need to keep older versions running for existing clients, roll out new versions safely, and avoid breaking changes that might take down production. And you need to do all that without duplicating too much infrastructure or introducing spaghetti logic inside your code. There’s no official pattern for versioning APIs in API Gateway + Lambda. API Gateway...
I recently shared six event versioning strategies for event-driven architectures [1]. In response to this, Marty Pitt reached out and showed me how Orbital [2] and Taxi [3] use semantic tags to eliminate schema coupling in event-driven architectures and simplify the schema management. It's a novel way to manage schema evolution, and I want to share what I learnt with you. Problems with Schema Coupling In an event-driven architecture, event consumers are typically coupled to the schema of the...
Last week, we looked at 6 ways to version event schemas [1] and found the best solution is to avoid breaking changes and minimise the need for versioning. But how exactly do you do that? How can you prevent accidental breaking changes from creeping in? You can detect and stop breaking changes: At runtime, when the events are ingested; During development, when schema changes are made; Or a combination of both! Here are three approaches you should consider. 1. Consumer-Driven Contracts In...