<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">What about thrift? My experience with it has been pretty positive. <div><br></div><div><br></div><div>Sergej</div><div><br><div><div>On 16 May 2015, at 21:17, Thomas Elsgaard <<a href="mailto:thomas.elsgaard@gmail.com">thomas.elsgaard@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>The communication between services would then be http based. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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 ;-)</div><div><br></div><div>Thomas</div>
_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-questions<br></blockquote></div><br></div></body></html>