[erlang-questions] Microservices vs. Erlang processes
Mon Jul 7 18:24:29 CEST 2014
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?
Well... a few knee-jerk, opinionated comments - take them for what
- 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
--- 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?).
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
More information about the erlang-questions