Hi Roland, Thanks for thoughts...
On Thursday, June 5, 2014 6:57:38 AM UTC-7, rkuhn wrote: > > > *Data Flow Topology* > - Akka is pretty good at this already, supporting many types of data > flow. The only concern I see is that you have to define the flow via the > like of routers and such, which are defined in the code on each node, > rather than externally via say a message queue (see ZMQ, NSQ etc). This > can be mitigated through DI and configuration and things like that, of > course. > > > I’d propose to build only direct peer-to-peer communication into the > fabric and model all other concerns (queues, pub-sub, etc.) as uniservices > on top. These implementations will then naturally be part of the whole > package, but I would rather not conflate different notions of > message-passing under a common umbrella. > Sounds good. And Akka already has support for ZMQ... > > > *Data Serialization* > If we are using native Akka protocol to talk over the wire, this is > already really good. One defines case classes, and Akka transparently > serializes them over the network if the actor is remote. This is one thing > about Akka that really appeals to me. > > So the question is can we make this work for Play / Akka HTTP > transparently as well? > > *Related - Polyglot support* > How would a Ruby/Python/etc process talk to an Akka network? My thoughts: > - Easiest way would be to have a way to automagically generate HTTP > endpoints that includes case class serialization to/from JSON. Type > classes to handle special data types. > - Did you guys define the Akka binary protocol and keep it stable? > Client libraries could then be written for different langauges, but this > doesn't solve the problem of message format -- Java serialization and > Chill/Kryo won't work. > > > My current thoughts on this front (also for changing the Akka remote > protocol to allow interoperability between different versions) go into the > direction of CBOR <http://tools.ietf.org/html/rfc7049> as a kind-of > binary JSON-like format that is friendly to streaming, compact, > self-describing and standardized. In the end it will require a structural > data format (i.e. not tied to JVM nominal types) to accomplish polyglot > deployments. The reason to prefer it over protobuf is that it can be parsed > without knowing the schema. > > The raw serialization implementation can be used for any number of > use-cases, e.g. remoting, streams, persistence, etc. > This shouldn't be hard - after all serialization is already pluggable. Is there momentum behind CBOR though? > > > > > *Hot Reloads* > I didn't include this in the list above, because the assumption is that > with lots of independent small services, they will be naturally easier to > redeploy. Some will argue that the JVM is heavyweight (actually I think a > lightly loaded JVM app is under 50MB, which is very reasonable), and will > want Erlang-style hot reloads of individual actors. This is really tricky > area though. > > > I fully agree, redeployment should be done on a per-JVM granularity, where > one JVM possibly hosts multiple (related) uniservices. > > 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. > You mean Actor become() and friends? Failure handling is inherently tied to the topology ... I'm not sure what common themes we can bring to the table, other than distributed supervision should be a fundamental piece (and a strength of Akka's). > > > Anyways, I'd love to get the thoughts of the community about this idea of > using Akka as a "microservice" platform. > > > Much appreciated that you started this, and sorry for taking so long to > respond, the last few days were a bit hectic on my end. > > Regards, > > > *Dr. Roland Kuhn* > *Akka Tech Lead* > Typesafe <http://typesafe.com/> – Reactive apps on the JVM. > twitter: @rolandkuhn > <http://twitter.com/#!/rolandkuhn> > > -- >>>>>>>>>> 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.
