[erlang-questions] erlang-questions Digest, Vol 217, Issue 9

[Christopher Phillips]

>
>
> Date: Sat, 16 May 2015 17:17:39 -0200
> From: Thomas Elsgaard <thomas.elsgaard@REDACTED>
> To: Garrett Smith <g@REDACTED>
> Cc: "erlang-questions@REDACTED" <erlang-questions@REDACTED>
> Subject: Re: [erlang-questions] Erlang microservice architecture ?
> Message-ID:
>         <
> CAKSYKuJLNc4NBrqCv0f_Kks52bDWKw-6m_7YVWB2zwo_DznX+g@REDACTED>
> Content-Type: text/plain; charset="iso-8859-1"
>
> >
> > Except Thomas asked about micro services. I think you're talking about
> > nano services. That hasn't been discovered yet.
> >
> > Garrett
> >
>
> I should maybe add that this is for low volume but complex service
> activation in the telco domain, the current approach has been the
> traditional SOA solution with an ESB and process orchestration (all Java
> based), but the number of services has increased, and the ESB (service bus
> + message queue) is suffering from memory leaks and other stability
> issues which is hard to troubleshoot, and in general, the solution is just
> complex.
>
> Now the buzz is microservices (someone might call it SOA 2.0) but i would
> like to split the architecture up in smaller isolated services, and of
> course Erlang based. My original idea was to split the services up on
> separate servers, install yaws on each server, and then install Erlang
> applications as yapps on each server. This means that i can autoinstall the
> servers just with yaws, build Erlang apps and deployed them on the servers
> as needed. I could host several yapps on the same server, and if needed,
> move individual yapps to another server.
>
> The communication between services would then be http based.
>
> But is there an smarter solution ? Chandru had some good input for why not
> using RPC (back pressure issue). Protobuffs via sockets could also work,
> but requires some more work.
>
> Fred is defiantly having some good input about just having all the
> applications on the same VM, I could do that, it's better than the current
>  Java ESB monster, but if I then decide to split the services to different
> servers, it will require some re-write.
>
> Anyone who has done anything similar ? I do not need high performance, but
> i need to handle complicated business logic between many services, and of
> course keeping it fault tolerant ;-)
>
> Thomas
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://erlang.org/pipermail/erlang-questions/attachments/20150516/cc99b101/attachment-0001.html
> >
>

Per Fred's suggestion, it's not entirely true that it would require a
rewrite. If it's sufficiently low volume, it could just be some
configuration changes.

That would require all inter-app communication passing through a well
defined interface, such as a registered gen_server. I.e., you have app_a,
app_b, and app_c, and each registers itself globally. All communication
from app_a to app_b goes through the registered app_b process, etc.

On a single node, where app_a, app_b, and app_c are all running on the same
VM, messages pass between them using the registered name.

If you later split them out across multiple nodes, spanning multiple
machines (such that app_a gets its own box, app_b gets its own box, and
app_c gets its own box, or any combination of sharing between them), you
can just ping the different nodes together, still globally register them,
and messages still pass between them using the registered name; nothing has
to change in the code. That's one of the nice things about Erlang's
distribution mechanism.

Now, if those servers need to be geographically distant, and/or netsplits
are going to be a common occurrence (and you need things to be partition
tolerant), etc, it gets tricky, and will require domain specific
considerations and implementations. But that's true regardless of what
technology or architecture you pick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150516/0dd4fb1d/attachment.htm>