Hi, Am Donnerstag, 5. Juni 2014 15:57:38 UTC+2 schrieb rkuhn: > > thanks for bringing this up! We have been discussing similar things at > Akka HQ, so far without the ability to dedicate resources to such an > effort. I agree with Thomas that Actors already cover the basics, I would > call the Actor Model the ideal substrate on which we can efficiently and > conveniently grow uniservices(*). > > [specific replies inline] > > (*) I prefer this term because it focuses on the Single Responsibility > Principle (see also the introduction of modules > <https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf>) > instead of the rather irrelevant notion of “size” . >
I like that term, actually. It describes well what a microservice should be focussed on: doing one thing well. > One thing that is commonly left out—even when citing Erlang—is resilience: > it is of the utmost important to include a sane model for handling service > failures, restarting or redeploying them, switching to backup topologies, > etc. We have that within Akka and porting this to the way we express > uniservice architectures is one of the most appealing aspects of this whole > endeavor. > In addition, I think it should be as transparent as possible. One of the major advantages of RESTful HTTP in microservice architectures is the statelessness of HTTP. A request might be ending up at any endpoint, I don't really have to care, as long as I have a router in between. And routing/loadbalancing HTTP requests is a solved problem. The drawbacks are clearly the increased overhead and that I need to write a layer that translates from messages in one system to JSON, send it via HTTP, receive on the other endpoint and deserialize. If I could talk to an actor without knowing where it lives, that would provide the same benefit as the HTTP architecture, but with much less overhead. The cluster sharding allows me to do that, but I would assume that might be a bit too specific as a solution. And there is another aspect. Especially for larger projects microservices are great to "enforce" a share nothing philosophy. Using akka serialization, I either have to share the messages or use protobuf + code generation, which is again more complicated. I am not sure whether that can be achieved with CBOR standard you mentioned, but using JSON via HTTP has the advantage that I don't have to share code while it's still very easy to use. But it would be awesome to have an Akka based microservice platform that solves some of the common problems discussed in this thread in a nice way. best Carsten -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
