Designing for Freedom: Erlang Generic Servers

It is very pleasing to work with tools that are well designed. This is the story of one of them.

In his SXSW panel “Designing for Freedom” Michael “Rands” Lopp recites a situation from a design meeting for the current version of Apple Remote Desktop, Apple’s remote administration software. He, being a nerd, proposed a very nerdy feature (that is a feature whose value every nerd immediately understands but is less obvious for others): Let’s add the ability to send shell scripts to all machines in a lab and have them run there.

Your reaction is one of “What for, exactly?” and “Hell Yeah!”. And if you could anticipate both, you see the problem: Designing an application is figuring out the problems a user has and then solving these problems. Running scripts somewhere does not solve a specific problem, it is a general approach to solve a class of problems to avoid solving them over and over again, because different users have different needs. And this is another step in application design: You give the user the freedom to add whatever customisation he needs for his specific problem and your generic solution. Therein lies power.

Now, sorry, it gets extremely nerdy. Joe Armstrong is the father of Erlang and in his Book “Programming Erlang” he explains the Erlang design pattern of a generic server. All a generic server does is accepting messages and returning responses. Actual functionality can be added with a callback module. And with its modular nature, you can change the callback module of a generic server while the server is running, without turning it off (Look ma, no downtime!). How is that related to the first three paragraphs?

Joe shares an anecdote: He used to work at a place that had a large network of computers across the world. By the time he started working there he did not have anything specific to do with it, but the possibility of having a large cluster of hardware to work with had him installing generic servers on all the machines. Later, he could turn these into specific servers that served HTTP or SMTP or anything else really. And he could change the nature of these servers for each new task.

This is a very extreme design for freedom. It does not solve any specific problem, but it allows to build any solution that uses a client-server architecture. It is pretty generic (hence the name), but so powerful that you can leverage hundreds of machines to make the computations you need with just a few lines of code. And when you are done, you can use the same infrastructure to solve a completely different task.

Joe and his team did a really great job at analysing their user’s problems and finding a generic solution that is also easy to use and customise. My friend Philip Ratzsch just published a first-in-a-series tutorial explaining hands-down how to make use of Erlang’s generic server. Go, check it out.

While you can argue about other things in Erlang, the generic server is a pretty damn good design.

It is a pity though, that there are only a few who can appreciate this and I really hope that we will see this concept in more places. Just because I want to use well designed tools wherever I go.