<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>