[erlang-questions] Microservices vs. Erlang processes
Tue Jul 8 04:47:54 CEST 2014
On Monday 07 July 2014 11:45:24 Lloyd R. Prentice wrote:
> We're hearing much about "microservice architecture" in system design
> circles these days:
> Can anyone explain to me how this design practice differs from the Erlang
> practice of factoring a system into concurrent processes?
> I think I understand that they have different interfaces and that Erlang
> processes can be easily monitored and supervised but, beyond that...
> - Is this a case of another term for a functionally equivalent concept?
> - Is an Erlang process typically coarser or finer grained than a typical
> microservice? - What "itch" is being scratched by microservice design that
> can't be scratched by well designed Erlang?
To sum up this thread: There is nothing technically new or interesting here.
There is a new label, and that is interesting for reasons that have nothing to
do with technology and everything to do with market psychology.
Regarding "microservices" meaning bare metal: This would be a much more
interesting, precise, and original meaning! Leave it to the smart guys who
hang around here to read this meaning into such a term. Unfortunately, the
same reasons this would be a good idea (semantically and technically) are why
this is *not* what the term means, and never will be -- because buzzwords are
designed to repackage a previously hyped-but-immature idea, and therefore must
be vague enough to mean literally anything (consider "cloud").
What itch? The marketing itch. Nothing else. Its a chance for quite a few
folks to clean up and republish a bunch of work on an idea that never was
never really executed on properly (like so many others...).
 I had an interesting conversation with Peer Stritzinger about bare metal
Erlang just the other day. (In relation to a reactive infrastructure idea I am
working on, which is a bit different than the "yet another browser accessible
primate distraction device" sort of thing that gets web folks excited.) He's
done a lot of work in this direction, initially using Erlang as a friendlier
alternative to C in industrial applications, but clearly with an awareness
that more interesting opportunities would emerge as a side effect of his
project. The idea of using actual micros for "micro"-sized services is
intriguing, but the implications seem to be way outside the realm of the
average web-style VC's imagination. There is sometimes a conceptual fuzziness
in this space between running an OTP-style constellation of distributed smart
things where "thing" means "physical device" (of whatever sort -- a crane arm,
a solar panel, etc.) and running Erlang directly on Xen. I've not seen this
discussed anywhere. I think the groups working on both methods are targetting
different problems. The Erlang-on-Xen/Erlang-as-the-OS crowd is focused on
running web, business or other software-only services, and sees elimination of
an increasingly shifty and messy OS layer as a simplification. The embedded-
Erlang folks are focused on the problem of driving hardware, and sees Erlang
as a friendlier alternative to assembler and C, and possibly one of the only
reasonable new languages in an era where a "service" and a "device" may become
interchangeable ideas at some level of industrial application. None of this,
of course, is what "microservices architecture" is intended to mean.
More information about the erlang-questions