[erlang-questions] Microservices vs. Erlang processes

[zxq9]

On Monday 07 July 2014 11:45:24 Lloyd R. Prentice wrote:
> Hello,
> 
> We're hearing much about "microservice architecture" in system design
> circles these days:
> 
> http://martinfowler.com/articles/microservices.html
> 
> 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").[1]

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...).

-Craig

[1] 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.