[erlang-questions] Microservices vs. Erlang processes

[Miles Fidelman]

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