[erlang-questions] Erlang microservice architecture ?
Sat May 16 22:34:19 CEST 2015
On Sat, May 16, 2015 at 2:17 PM, Thomas Elsgaard
>> Except Thomas asked about micro services. I think you're talking about
>> nano services. That hasn't been discovered yet.
> 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.
I'd go with Fred's suggestion with 100% certainty that it's the right course.
Wait until you are driven with real problems before separating anything.
You can always, trivially separate OTP processes and put them on
separate servers, either by using Erlang distribution or wrapping each
in some socket interface. Some have suggest Thrift or other
frameworks. Why? What's driving this?
> The communication between services would then be http based.
> 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.
Why? Is it working, in production with known problems that you can point to?
> 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.
No - it will require some wrapping (additional code). But you're
proposing to do this *now* rather than put it off until you you know
you really need it. Again, why?
> 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 ;-)
I'd get it working in the most direct possible way. If you're writing
OTP compliant systems, your system will be fault tolerant, at least
reasonably so out-of-the-box without any thought at all.
Once it's working and running in production in some capacity - note
the *actual* problems, then tackle each one.
Not having microservices is not an actual problem.
More information about the erlang-questions