<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 05/16/2015 12:17 PM, Thomas Elsgaard
wrote:<br>
</div>
<blockquote
cite="mid:CAKSYKuJLNc4NBrqCv0f_Kks52bDWKw-6m_7YVWB2zwo_DznX+g@mail.gmail.com"
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>
</blockquote>
CloudI (<a class="moz-txt-link-freetext" href="http://cloudi.org">http://cloudi.org</a>) is a good fit to this situation if you
want all the microservices to be fault-tolerant with service
discovery in an AP-type distributed system (that is master-less).
Each service only contains transient/temporary state that can be
used for caching or related use. Erlang services would use the
cloudi_service behaviour which is similar to the gen_server OTP
behaviour, but with many other features for its configuration and
messaging. If you only will be doing Erlang services, you could use
the cloudi_core repository (<a class="moz-txt-link-freetext" href="https://github.com/CloudI/cloudi_core">https://github.com/CloudI/cloudi_core</a>),
otherwise if you need to create non-Erlang services also, use the
main repository (<a class="moz-txt-link-freetext" href="https://github.com/CloudI/CloudI">https://github.com/CloudI/CloudI</a>).<br>
<br>
CloudI is using distributed Erlang to share service discovery
information with other CloudI nodes and to exchange service requests
with remote node services. Each of the 20 services would want to
have multiple instances created to be redundant (so by having the
count_process set to > 1 for each service configuration entry of
the 20 services) and would exist on a remote CloudI node for
redundancy.<br>
<blockquote
cite="mid:CAKSYKuJLNc4NBrqCv0f_Kks52bDWKw-6m_7YVWB2zwo_DznX+g@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>The communication between services would then be http based.
<br>
</div>
</blockquote>
If you used CloudI, you would be using service requests which
contain a Request (body) and RequestInfo (request meta-data, e.g.,
HTTP headers) with additional parameters for various features (a
unique transaction ID as a v1 UUID, a timeout that decrements based
on any delays the service request encounters, a priority with 255
possible values). Due to fault-tolerance concerns, service requests
are randomly load balanced automatically among any services that
subscribe to a single service name pattern that matches the service
request's service name (which is why you want multiple processes for
each of the 20 services, and CloudI handles that as a service
configuration parameter). If you want to exchange HTTP traffic, you
can, the service request data is whatever you want it to be (in the
RequestInfo/Request pair and the ResponseInfo/Response pair). It is
only if you are sending to an external service that you need to use
binary data, to make sure the external service can utilize the data.<br>
<blockquote
cite="mid:CAKSYKuJLNc4NBrqCv0f_Kks52bDWKw-6m_7YVWB2zwo_DznX+g@mail.gmail.com"
type="cite">
<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>
</blockquote>
With CloudI it would be simpler to reuse the Java source code by
using the Java CloudI API and having CloudI execute the Java
external services as an application server. There is more
information about why you would want this path at
<a class="moz-txt-link-freetext" href="http://cloudi.org/faq.html#4_Erlang">http://cloudi.org/faq.html#4_Erlang</a> . The CloudI source code is
small when you consider everything is handled by the cloudi_core
source code, the extra integration tests and example services help
you get started and facilitate other usage and testing.<br>
<blockquote
cite="mid:CAKSYKuJLNc4NBrqCv0f_Kks52bDWKw-6m_7YVWB2zwo_DznX+g@mail.gmail.com"
type="cite">
<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>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
</body>
</html>