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