Posts Tagged ‘Joe Armstrong’

Highly Available Systems == Scalable Systems

June 1, 2012 4 comments

In this QCon talk: “Building Highly Available Systems In Erlang“, Erlang programming language creator and highly-entertaining speaker Joe Armstrong asserts that if you build a highly available software system, then scalability comes along for “free” with that system. Say what? At first, I wanted to ask Joe what he was smoking, but after reflecting on his assertion and his supporting evidence, I think he’s right.

In his inimitable presentation, Joe postulates that there are 6 properties of Highly Available (HA) systems:

  1. Isolation (of modules from each other – a module crash can’t crash other modules).
  2. Concurrency (need at least two computers in the system so that when one crashes, you can fix it while the redundant one keeps on truckin’).
  3. Failure Detection (in order to fix a failure at its point of origin, you gotta be able to detect it first)
  4. Fault Identification (need post-failure info that allows you to zero-in on the cause and fix it quickly)
  5. Live Code Upgrade (for zero downtime, need to be able to hot-swap in code for either evolution or bug fixes)
  6. Stable Storage (multiple copies of data; distribution to avoid a single point of failure)

By design, all 6 HA rules are directly supported within the Erlang language. No, not in external libraries/frameworks/toolkits, but in the language itself:

  1. Isolation: Erlang processes are isolated from each other by the VM (Virtual Machine); one process cannot damage another and processes have no shared memory (look, no locks mom!).
  2. Concurrency: All spawned Erlang processes run in parallel – either virtually on one CPU, or really, on multiple cores and processor nodes.
  3. Failure Detection: Erlang processes can tell the VM that it wants to detect failures in those processes it spawns. When a parent process spawns a child process, in one line of code it can “link” to the child and be auto-notified by the VM of a crash.
  4. Fault Identification: In Erlang (out of band) error signals containing error descriptors are propagated to linked parent processes during runtime.
  5. Live Code Upgrade: Erlang application code can be modified in real-time as it runs (no, it’s not magic!)
  6. Stable Storage: Erlang contains a highly configurable, comically named database called “mnesia” .

The punch line is that systems composed of entities that are isolated (property 1) and concurrently runnable (property 2) are automatically scalable. Agree?

My Erlang Learning Status

February 14, 2011 3 comments

Check out this slide from Erlang language co-designer Joe Armstrong’s InfoQ lecture: “Erlang – software for a concurrent world“. I’ve circled the features that have drawn me to Erlang because I’m currently developing product software where those qualities are hugely important to my customers. Despite their importance to success, they’re almost always given second class status by programmers and managers because they’re not domain-specific, “glamorous“, features.

The blue arrow is my sore spot. You see, I’ve been programming imperatively in FORTAN, then C, and then C++, since Jesus was born. Thus, learning the stateless, recursive, functional programming mindset that Erlang is founded upon is a huge hurdle for me to overcome. Nevertheless, as I’ve stated before, I’m half-assedly trying to learn OMOT how to program in Erlang with the aid of this very good book:

Here’s my learning “status” in terms of the book’s table of contents:

I don’t have an ironclad, micro-scheduled plan or BS risk register pinned on the wall in my war room, so I have no idea when I’ll be 100% done. But who knows, if I don’t abandon the effort:

Note: OMOT = On My Own Time

%d bloggers like this: