[erlang-questions] Erlang microservice architecture ?

[Michael Truog]

On 05/16/2015 12:17 PM, Thomas Elsgaard wrote:
>
>
>     Except Thomas asked about micro services. I think you're talking about
>     nano services. That hasn't been discovered yet.
>
>     Garrett
>
>
> 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.
>
> 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.
CloudI (http://cloudi.org) 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 (https://github.com/CloudI/cloudi_core), otherwise if you need to create non-Erlang services also, use the main repository (https://github.com/CloudI/CloudI).

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.
>
> The communication between services would then be http based.
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.
>
> 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.
>
> 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.
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 http://cloudi.org/faq.html#4_Erlang .  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.
>
> 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 ;-)
>
> Thomas
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150516/3d4929a2/attachment.htm>