Hi Evan, 10 jun 2014 kl. 02:26 skrev Evan Chan <[email protected]>:
> 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... Yes, it should be easy to implement these services. > >> >> 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 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? Check Todd Montgomery’s latest: http://www.slideshare.net/toddleemontgomery/qcon-ny-2014-evolving-rest-for-an-iot-world (last slide or so) I will spend some quality time with RFC7049 in the upcoming weeks, but currently it looks really promising for the reasons I outlined above, and it seems that others have the same impression. > >> > >> >> 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). Yes, that is what I meant: we need to lift the notion of supervision from the Actor hierarchy (i.e. within a single uniservice) to the relationship between services. Redeployment etc. is not what become() is about, actors change behavior all the time as part of their normal function. Redeployment would mean crashing / killing the JVM and creating a new one, because only then can you be sure that all resources are cleaned up. Regards, Roland > > >> >> 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 – Reactive apps on the JVM. > twitter: @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. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @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.
