A set of DDD-friendly tools for the JVM, simplifying reactive, event-driven, and microservices architectures.
The vlingo/PLATFORM 0.9.1-RC2 is released.
P.S. regarding snapshots. probably, no luck with github repo either:
Note: GitHub Packages does not support SNAPSHOT versions of Apache Maven. Make sure you disable SNAPHOT in your ~/.m2/settings.xml file.
https://help.github.com/en/github/managing-packages-with-github-packages/configuring-apache-maven-for-use-with-github-packages
@kbastani , @VaughnVernon thanks a lot for the meetup!
Hi everyone! I have a basic question as a noob looking to use Vlingo soon. What was the rationale behind not using Akka as the actor toolkit instead of developing a new actor platform which presumably will require all the comprehensive featureset of a long-matured actor toolkit like Akka?
@VaughnVernon I want to thank you for your great work and all the Vlingo developers!
Thanks @VaughnVernon! Yes we're analyzing the differences. We build solutions for clients - so I mainly have a few questions that clients may ask when we recommend Vlingo:
- If it is not already, what's the timeframe Vlingo will be considered ready for production-grade use?
- Has there been any performance benchmarks done separately for Vlingo or comparing Vlingo with other comparable solutions (like Axon, for example).
- What are the known scalability limits, if any?
@shafqatevo Good questions.
- vlingo has been in production use for approximately 8 months. As I recall that was around the 0.8.3 timeframe. The full platform reached 1.0.0 on 10 January. There have been successful PoC uses as far back as October 2018.
- There is an experience report being delivered soon. It notes how the vlingo/actors and vlingo/http performance is far better than the equivalent Akka components.
- We have not had any reports of scalability limits. Consider that an actor-based service internally scales much better than something like Axon or Spring because the asynchronous messaging throughout prevents the vast majority of blocking. Due to this, there are typically far less nodes (clustered or otherwise) because there is more efficiency in each node. One client has deployed vlingo to AWS Fargate, which scales in different ways. The feedback has been only positive.
Some may argue that there is a non-blocking web server or streams available in their solutions, but these only address a limited number of potential thread blockers. Since the vlingo/PLATFORM is entirely implemented on the actor foundation, it avoids blocking at all possible points.
BTW, what are your performance and scalability requirements in terms that can be applied to our platform? What are your use cases? Do you employ entities for business objects, or are you primarily working parallel processing to crunch data/numbers?
@VaughnVernon thanks for the answers!
It'll be very interesting to see a performance benchmark under load for a real life application like https://github.com/gothinkster/realworld for Vlingo vs Axon vs Lagom. I do acknowledge that performance is just one aspect and in most other aspects Vlingo, to me, is a clear leader with a great vision in this space.
By known scalability limits, I was mainly referring to the various vertical and horizontal scalability limits that arise from choice of approaches. Limits won't mean anything low here - can be quite high scalabilities - but with finite limits for a typical cloud infrastructure. For example, the following paper compares concurrency approaches of Akka vs Go vs Erlang and each shows interesting scalability limits on a given hardware for increasing loads: http://www.dcs.gla.ac.uk/~trinder/papers/sac-18.pdf
For the immediate client project for which we're preferring Vlingo, it is a patient-centric health care platform that will also make use of IoTs in future. Not really in need of anything much high scalability - but clients always keep asking questions on scalability and expect convincing answers. For Akka, there are few such benchmarks which we can show to client. Then there is the question of scalability characteristics of the entire platform not just the actor toolkit.
Another factor for us is a Kubernetes Operator - hopefully this will be initiated soon in Vlingo. The more comprehensive the operator is, the better.
Probably @kmruiz will have better recollection of this since he created the benchmark.
I have asked @kbastani to reply to your inquiry regarding k8s support, which is already in vlingo/zoom. You would use vlingo/xoom as the vlingo microframework and microservice boot. Our boot times are often in 30ms and far less. We have no runtime annotation wiring. The support of and minimal use of annotations is "just right" and resolved at compile time.
I think that it's safe to say that the entire vlingo/PLATFORM is comfortably scalable for most services/apps. If your medical domain needs to support a few million entities spread across thousands of users, no problem. If that needs to double and then triple, no problem. Given your current scale requirements it seems unlikely that this will ever be an issue, but if so it's one that we look forward to solving for you.
Minimizing annotations should help with running Vlingo on GraalVM (assuming other uses of reflections are minimized too).
Startup time on Graal native image should be even lower.
Fully understand that @VaughnVernon . We look forward to contribute to Vlingo where we can, after understanding it fully.
One example of how essential infrastructure components could constrain scalability is Kafka's limits to support dedicated topics for millions of DDD aggregate instances.
None of the currently available message queues actually are designed for such scale otherwise needed to support actor mailboxes or publish channels.
I have seen your talk where you discussed Geode
What is your current recommendation for event store?
Keeping an eye on Pulsar and Kafka's recent efforts for increasing topic scalability
They still need some work to get to the scalability levels of typical actor instances of couple millions per VM
As a pure event store, I guess the main requirement is efficient event sourcing during actor reactivations
I mean besides message delivery