<div dir="ltr">Hi Thomas,<div><br></div><div>All the approaches you outlined below are valid and workable. The exact answer depends on your particular set of requirements around system integration, failure handling, load balancing, scalability, performance required etc. Further comments inline below.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 May 2015 at 02:59, Thomas Elsgaard <span dir="ltr"><<a href="mailto:thomas.elsgaard@gmail.com" target="_blank">thomas.elsgaard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi list<div><br></div><div>If you should recommend the architecture for an microservice implementation with around 20 Erlang microservices implemented on separate servers, how would you implement it ?</div><div><br></div><div>1) using gen_servers on each server and use rpc calls between services ?<br></div></div></blockquote><div><br></div><div>The downside to using RPC is lack of flow control. When using RPC there is no (easy) way for the server end to put back pressure on the clients. The upside is obviously convenience. This approach probably has the lowest barrier to entry so ideal for prototyping.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>2) using web servers like yaws or webmachine on each server, and use http + json/xml between services ?</div></div></blockquote><div><br></div><div>This approach is fine up to a certain point. Things to consider here are:</div><div>- Is strict ordering required between messages?</div><div>- What is the transaction volume? For very high volumes, the overhead of HTTP becomes significant. HTTP isn't the best designed protocol either. Sure, client libraries exist (I myself maintain one) which can hide this for you, but the ugliness is still there.</div><div>- The upside is that integration between components (written in different languages) is easy</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>3) roll my own erlang applications + message parsing on each server ?</div></div></blockquote><div><br></div><div>This takes the most effort (compared to the rest, but still quite easy to do in Erlang), but will also deliver maximum control and performance for you. You can either roll your own protocol, or use things such as Thrift or Protobuffs if integration between systems written in different languages is important.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Or any better ideas ?<br></div><div><br></div><div>At some point, thing like service discovery will also be interresting </div></div></blockquote><div><br></div><div>If the topology of your network of erlang nodes can be expressed in a few hundred lines of config, I would say things like service discovery are less useful I wouldn't spend time up front providing support for service discovery.</div><div><br></div><div>cheers,</div><div>Chandru</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="HOEnZb"><font color="#888888"><div><br></div><div>Thomas</div><div><br></div><div><br></div></font></span></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div></div>