[erlang-questions] Microservices vs. Erlang processes

Miles Fidelman mfidelman@REDACTED
Mon Jul 7 18:24:29 CEST 2014

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?

Well... a few knee-jerk, opinionated comments - take them for what 
they're worth:

- first off, it depends on how one defines "microservice architecture"

- the notion of building software and systems from re-usable components 
is not new - it generally doesn't work well, though things like CPAN are 
a notable exception
- the notion of services as components is not new - again, the devil is 
in the details:
--- can you say objects-oriented?
--- E2EE and JavaBeans seems to have traction
--- SOAs and web services seem to generate a lot of papers on "SOA 
governance" than real systems - IMHO because W3C web services are very 
complicated and high-overhead
--- RESTful interfaces and mashups are another approach - again, with 
some traction, particularly for building things on top of Google and 
Amazon services
--- message oriented middleware (e.g., Mule) is yet another approach
--- overall, the questions always come down to: what are the services, 
and how does when orchestrate/choreograph them

What differentiates microservices seems to be the notion of putting each 
service on its own server - be it hardware, a VM, or a container (can 
you say "Docker?").  The folks pushing the idea seem to be driven by 
rapid deployment and management considerations - and seem to come out of 
the DevOps and the cloud provisioning communities - i.e., folks who 
focus on tooling and platforms.

(IMHO) The notion of services and composition of services is not a bad 
design pattern, particularly with clean interfaces; which to me, means - 
protocol oriented (messages or RESTful) rather than programmatic APIs.

But... the microservice implementation strikes me as basically 
wrong-headed.  The notion of a VM or container (i.e., a full o/s) 
carries a LOT of baggage and overhead, if all one is doing is running a 
single service on it.  Running a micro-service on a heavyweight platform 
seems fundamentally broken.  Granted, something like LXC offers an 
interim step for "containerizing" existing code bases (e.g., postfix in 
one container, mysql in another, apache in another) - but for new code, 
a much more lightweight platform seems in order - something like a very 
stripped down microkernal.

To me, a serious "microservice platform" would look like Erlang on bare 
metal - with "microservices" implemented as Erlang processes (a 
gen-server seems like an awfully good start for a "microservice"). 
(Parenthetically - whatever happened to the Erlang on Bare Metal and 
Erlang on Xen projects?).

Miles Fidelman

In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

More information about the erlang-questions mailing list