In a recent conversation on the Akka User Google Group, we came across an interesting conversation which contained some really straightforward answers to questions that architects ask when deciding to adopt a tool or not––in this case, Akka. The responses below are from Justin du Coeur, a long-time fan of Actors (even before Akka was created) and the creator of Querki. Querki is still in beta, and represents is a new way of organizing your personal information powered by Scala, Akka, Play and Scala.js. As a one-man show, Justin wears many hats, which makes him an ideal candidate for cutting to the root of matter with these six questions for architects. You can read more about Justin and the Querki project on the project’s development blog and his personal blog, which artfully blends conversations about software, science-fiction, SCA and gaming.
The next part has been adapted from a conversation in which Akka was suggested for production use. We’ll include Justin’s original comments and any supplementary links and comments from us at Lightbend.
Lots, I believe. My small company scarcely counts, but is one data point. But you'd have to ask around more for numbers.
Of our 50 case studies and community stories, 39 of them (78%) are using Akka in production–happy clients include Walmart, Hootsuite, Huffington Post, WhitePages, Gilt, and Ticketfly. I invite you check out some of these stories for more details, and share with your management team if you think it’ll help in decision making.
EXAMPLES OF AKKA IN PRODUCTION
This is kind of the point, really. Indeed, the evolution of Akka in recent years has in large part been focused on removing the bits that *didn't* cluster well (such as the in-memory transaction system) and adding deep clustering support. Proper clustering is the primary focus of what I see from the Akka team these days, and at this point it's getting pretty sweet. At this point, Akka's clustering tech is increasingly rich, with tools such as:
Akka Cluster Sharding - contains built-in mechanisms to deal with spreading heterogeneous Actors around the cluster, and letting clients communicate with them without needing to know where they are located
Akka Persistence - a robust persistence model for Actors, so that the cluster can be rebalanced easily and automatically and Actors can be passivated safely
Multi-Node Testing - so that you can build a single unit test for Actor Systems clustered across multiple JVMs or multiple hard nodes
Justin’s description covers this pretty well—what's also worth mentioning is the Akka Distributed Data module, which provides resilient and scalable, eventually consistent and composable data types like Maps, Sets, Counters, Registers etc, based on CRDTs (Conflict-Free Replicated Data Types).
Lots–indeed, the Lightbend stack is focused on making it stupid-easy to try out various scenarios quickly and easily, with embedded tutorials. I routinely pull up an Activator sample when I want to learn a new aspect of the system–it only takes a couple of minutes, and is a great way to see various modules in action, kick the tires and experiment with them.
Well, it's a proper Actor system. Supervision is at the heart of everything. Indeed, Akka per se largely *started* when Jonas Bonér took a look at the existing Actor implementations back around 2007 and pointed out that their big weakness was not taking supervision seriously enough. So supervisor hierarchies are baked into the soul of Akka, and have been from the start. By now, that's very, very mature.
It's worth noting that "Let it Fail" is the motto of the Akka project–the fundamental assumption is that failure *will* happen, even in the best code, so the important part is handling it properly.
Expanding upon Justin’s comments, I’ll happily reuse some content from our Akka webpage. As Justin said, with Akka you get resilience for free as part of the model though native fault-tolerance based on supervisor hierarchies. Every Actor can create other Actors, which it will then supervise—making decisions if they should be resumed, restarted, retired or if the problem should be escalated.
Instead of trying all things possible to prevent an error from happening, this approach lets you embrace the reality of unplanned errors. It means you can adopt a pragmatic philosophy that welcomes frequent and graceful failures with the confidence that the impacted components will be reset to a stable state and restarted upon failure. Oh, in case you're wondering how expensive failures are for organizations with 250+ employees, Gartner and Avaya did a study on that:
HOW EXPENSIVE IS FAILURE? (GARTNER)
Not my area of expertise, but AFAIK Akka is solidly good. Since most folks working on Akka are doing so with clusters, there's been a steady evolution towards making the system more and more deployable; nowadays, there are things like plugins to spit out Docker images and stuff like that. The Lightbend team did a thousand-node deployment for test purposes last year–you don't do that without good tool support.
In the Operations world, we’ve recently launched ConductR 1.0, a commercial technology specifically designed to let Ops conveniently manage and deploy distributed, Reactive applications using Java or Scala and built with Lightbend Platform technologies Play, Akka and Slick. This platform is available to use for free in development; however, if you’re planning to deploy commercial applications to production, our Lightbend Platform Subscription offers a growing set commercial-only features for Play, Akka, Lagom, and Scala, plus training, consulting and 24/7 support for production users of our technologies.
For example, the Akka team at Lightbend is working on a new, commercial-only, feature called Akka Split Brain Resolver (SBR), which is designed to manage network partitions and help Ops define a system’s available actions when nodes in a cluster become unreachable, thus enabling Ops to find the best way to address the nature of a failure and select a recovery path. More on that soon :-)
That's subjective, but I've found the public support from the community and from the team to be quite good for a number of years. The commercial support from Lightbend is *very* strong, but again, that costs real money...
From the open source community perspective, the Akka community is vibrant and growing, supported by an internal, dedicated team at Lightbend and connected with the other communities like Scala, Play Framework and Spark as well. The Akka project on Github has over 14,500 commits by 195 contributors, and has been forked almost 1200 times. The Akka User Google Group has over 7000 topics to review.
From the commercial support perspective, Akka is part of Lightbend Reactive Platform and available to use in development for free; however, serious enterprises deploying commercial applications have significantly benefitted from our subscription, which in addition to curated community resources includes one-on-one personal interaction with Lightbend experts, commercial-only features for Lightbend Platform technologies, plus training, consulting & up to 24/7 support for production systems.
There's some learning involved in using Akka effectively -- it's a different way of structuring your code. But having a clean, efficient framework, that scales gracefully from one small node to a big cluster without the usual headaches from threading and bottlenecks, is a huge win for any serious project. Querki wouldn't have been possible without it.
Justin, thank you very much for your thoughtful and educational responses on the Akka User Group and your support over the years–and good luck with Querki!
At this point, all we have left to say is that if your organization is looking to use Akka (or Play, Scala, Java or Spark) for commercial applications intended to make your customers happy, we’re happy to discuss what Lightbend can do for you. Contact us directly here
