Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Brian Wehrle
    @bwehrle
    Ah, must be a mac thing, since I copied using Finder. Will make a PR now with the build file.
    Vaughn Vernon
    @VaughnVernon
    In Travis-CI vlingo-micronaut is turned on for build. I am testing it now by touching the README in the root.
    Interesting, vlingo-micronaut is building due to my README tweak.
    Ah, no it is not. It is building due to your PR ^^^ :smile:
    Brian Wehrle
    @bwehrle
    The branch with the .yml is building now, yes :-) - after we merge that, I can work on making it publish. You don;t mind that it is using Gradle do you?
    Vaughn Vernon
    @VaughnVernon
    Gradle is awesome as long as it works :smile_cat: @kbastani Indicated that Micronaut is very dependent on Gradle, so it seems best to use it for related projects.
    Brian Wehrle
    @bwehrle
    Yes, so long as it works!
    Vaughn Vernon
    @VaughnVernon

    The build succeeded. I merged the PR. I have also created a Bintray artifact package. If we can run the build again with the deploy steps based on another repo that is copying to Bintray and the artifact gets deployed/copied then I can request a new Sonatype/Central artifact.

    https://bintray.com/vlingo/vlingo-platform-java/vlingo-micronaut

    ^^^ This is about enhancing the .travis.yml to copy the artifact to Bintray.
    Brian Wehrle
    @bwehrle
    I'll look at how to do this and then try it out this evening.
    Vaughn Vernon
    @VaughnVernon
    Cool, thanks! You should be able to pretty much copy and edit one from vlingo-actors or most others. I will have to provide the deploy.key after you have the basic publish edited.
    Brian Wehrle
    @bwehrle
    Ok, thanks
    Vaughn Vernon
    @VaughnVernon

    @/all We have a news piece on InfoQ:

    The vlingo/PLATFORM JVM and team are in the news on InfoQ regarding:

    1. Reactive Foundation charter member

    2. Blog post and recent work by @kbastani on vlingo/zoom.

    3. Features available on version 0.9.1-RC2

    4. .NET edition

    5. How to contribute

    https://www.infoq.com/news/2019/11/vlingo-reactive-foundation/

    Vaughn Vernon
    @VaughnVernon

    The vlingo/PLATFORM 0.9.1-RC2 is released.

    https://twitter.com/vlingo_io/status/1193569177866571777

    Dmitry Ledentsov
    @d-led

    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!
    Vaughn Vernon
    @VaughnVernon
    :+1: You are welcome. Thanks for checking on snapshots.
    Shafqat Ullah
    @shafqatevo
    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!
    Vaughn Vernon
    @VaughnVernon
    @shafqatevo Our approach to actors is much different. If you need support for the vlingo/PLATFORM we are happy to help you.
    Shafqat Ullah
    @shafqatevo
    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:
    1. If it is not already, what's the timeframe Vlingo will be considered ready for production-grade use?
    2. Has there been any performance benchmarks done separately for Vlingo or comparing Vlingo with other comparable solutions (like Axon, for example).
    3. What are the known scalability limits, if any?
    Vaughn Vernon
    @VaughnVernon

    @shafqatevo Good questions.

    1. 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.
    2. 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.
    3. 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?
    Shafqat Ullah
    @shafqatevo

    @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.

    Shafqat Ullah
    @shafqatevo
    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
    Shafqat Ullah
    @shafqatevo
    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.
    Shafqat Ullah
    @shafqatevo
    Yes, we're using DDD and aggregates will be actors. IoTs will have digital twins. CQRS projections will feed an ML system. In fact, there is an AI component that currently uses an agent library, which can potentially run on actors (agent = actor), too.
    Vaughn Vernon
    @VaughnVernon
    @shafqatevo We had a sustained benchmark running for many hours. IIRC it showed more than 280K requests per minute (not extreme compared to 12K/second) against vlingo/http backed by Event Sourced appends
    Probably @kmruiz will have better recollection of this since he created the benchmark.
    Vaughn Vernon
    @VaughnVernon
    There is a JMH benchmark on our fastest mailbox. It shows consistently 18-20 million messages per second through an actor. See our vlingo-examples repo.
    Vaughn Vernon
    @VaughnVernon
    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.
    Vaughn Vernon
    @VaughnVernon
    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.
    Shafqat Ullah
    @shafqatevo
    Thanks for sharing all these insights @VaughnVernon ! The numbers are encouraging and will be sufficient for now I hope.
    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.
    Vaughn Vernon
    @VaughnVernon
    Regarding the "RealWorld" apps, it sounds like a great idea to try when we can dedicate a few developers. We are currently fully tasked in vlingo development on 1.1.0 - 1.3.0 and implementing real real world apps with vlingo.
    Shafqat Ullah
    @shafqatevo
    Yes, we're looking into xoom. It was a pleasant surprise to see Kenny join Vlingo. Learned a lot from his articles and talks.
    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.
    Vaughn Vernon
    @VaughnVernon
    We already support GraalVM. This is an effort that @kmruiz is driving and that I supported by fully eliminate the need for reflection (optional based on actor instantiation style). Kevin can explain the details.
    Shafqat Ullah
    @shafqatevo
    That's great to learn!
    None of the currently available message queues actually are designed for such scale otherwise needed to support actor mailboxes or publish channels.
    Vaughn Vernon
    @VaughnVernon
    I'm going to strongly suggest that you not use Kafka as an Event Sourcing aggregate store.
    Shafqat Ullah
    @shafqatevo
    Yes, we already realized that
    I have seen your talk where you discussed Geode
    Vaughn Vernon
    @VaughnVernon
    Not sure then about your Kafka comment on limited topics.
    Shafqat Ullah
    @shafqatevo
    I was just giving an example of how infrastructure components may pose scalability limits
    Vaughn Vernon
    @VaughnVernon
    Geode is also not good as an event store. @davemuirhead has gone to great pains to get transactional support across regions and it doesn't work well. Geode is good for scaled k-v and compute fabric.
    Shafqat Ullah
    @shafqatevo
    Thanks for sharing that