[erlang-questions] Microservices vs. Erlang processes

[Michael Truog]

On 07/07/2014 09:24 AM, Miles Fidelman wrote:
> 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.
If microservices require their own server, that isn't very "micro". 
Older SOA could require a service to hog a server, but I hope that a 
microservice is smaller than that.  Other people in the past have 
referred to Erlang processes as "nanoservices" which seems realistic.
>
> (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.
You can have "messaging and RESTful", they are not exclusive.
>
> 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.
I don't believe a "microservice" concept requires a container or 
virtualization.
>
> 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?).
If erlang processes are "nanoservices", I think "microservices" would 
utilize more than 1 Erlang process.  For an example of this, look at the 
cloudi_service behaviour for creating internal services with CloudI 
(http://cloudi.org).  Some links that can help you distinguish between 
Erlang usage and CloudI usage are here:
http://cloudi.org/faq.html#1_Actor
http://cloudi.org/docs/cloudi_meetup_seattle2014.pdf

I agree that Erlang can provide microservices with bare-metal.
>
> Miles Fidelman
>
>
>
>
>
>
>