Akka vs Baratine (Benchmark Included!)
To understand the differences in programming model between the two, you first need to understand the purpose of why Caucho has spent so much time creating Baratine in the first place.
Concurrency, parallelism, or something more?
The principles of SOA have always been sound. They have revolved around the ideas of:
• Explicit boundaries
• Shared contract and Schema, not class
• Vendor independent
• and more
While these principles should have led to very agile programming, the reality is that the implementation has never able to meet these requirements. The complexity of data modeling and business requirements forced data to be abstracted away from business logic operations and placed into separate entities: databases. The resulting databases struggled to maintain high throughout and were often the cause of many bottlenecks within distributed applications. While distributed caches were able to provide faster content, they also introduced complex cache invalidation logic into an application. Besides the numerous components that make up a software stack, underlying frameworks have also been a point of contention with SOA. Multithreading throughout different portions of the application have been the cause of many thread deadlocks, starvation, & race conditions.
We believe that many of these misfortunes were cause by a fundamental flaw within the SOA model. By failing to address data locality and thread execution as principles that must be addressed within a SOA service, many implementations functioned as freeways without lanes. That is, the ability to block or break an application was available by any portion of the application as threads were free to operate outside of a given “lane” of execution.
An Evolution of SOA?
Baratine is a reworked solution, from the thread and data level up. It is designed as a framework that does not have any inherit bottlenecks or limitations when accessing data. Baratine is able to do this because it defines an abstraction level that merges thread execution with the service data. This allows services to call out to other services through serialized message passing, allowing for greater thread affinity within an application. The result is that these services can then be scaled independently while serving millions of requests per second per instance.
What’s more is that Baratine abstracts away the low level details including sharding, batching, message construction, and synchronization providing developers with an API and Object Oriented framework they are familiar with without having ever programmed in it directly. When programming in Baratine, developers are tasked with writing method calls to coordinate business logic throughout an application. This is precisely the object-oriented programming they have been doing for years, just not on a framework that allows groups of methods to function at the millions of operations/sec.
Baratine is not Akka… Akka is not Baratine
Akka handles distributed concurrency through its unique thread abstraction utilizing actors as passing messaging queues. It turns everything asynchronous, allowing for actors to route requests, parallel the execution of the requests. Great for execution, and can answer using futures and observables to decide what action should be taken.
Actors do not merge the persistence/locality of data and the execution of that data into a single entity. Untyped actors mean message types are not being enforced around the system, which results in hard to trace callbacks of failed services. Most developers are using actors to move data through an execution pipeline very fast while integrating an outside entity like Spark for managing the analytics/processing of the data. The execution of threads is handled by Akka at cost of pushing data into a separate entity.
Baratine manages both. This allows for coding that stays at the method level abstraction, has a cleaner handle on threads, and introduces no integration points of contention or failure.
Both models are looking to answer: how can we get more out of distributed concurrent programming? We know that greater concurrency will allow us to have more portions of our application functioning at once, so how can we handle this? Currently, you can try managing your own thread pools, futures, lambdas, etc, but still be stuck with an underlying framework that will use blocking techniques. Baratine and Akka have the ability to free you from a blocking framework… but at what cost? The cost is complexity.
Because Baratine addresses the data locality (including persistence & transactions) as well as the thread execution (batching & synchronization) the amount of code in a full blown application in Baratine is significantly less than Akka. The level of understanding is also much higher: a junior developer can comb through the code of a Baratine program and begin contributing services immediately.
The costs are where the fundamental differences within Baratine and Akka appear. Although both models are unfamiliar to developers, if you have built a object oriented program in Java or any given language before, you already know 90% of the Baratine framework.
Because the two frameworks are attempting to provide solutions for the same space, we thought it important to ensure high performance at the base level implementation. We benchmarked Akka and Baratine in a batching message passing service within a single JVM & within a local machine. The results we achieved are as follows:
within jvm Akka baratine
batch-size-1 1.0m 2.9m
batch-size-4 2.2m 3.7m
batch-size-16 2.6m 4.8m
batch-size-64 2.7m 5.2m
within local machine
batch-size-1 4.5k 12.5k
batch-size-4 9.0k 43k
batch-size-16 11k-13k 120k
batch-size-64 13k-15k 230k
Our results showed an impressive 2-3x performance advantage held by Baratine over Akka! While message passing is a fundamental focus of Akka, Baratine handles message passing for you ( as batched method calls ), making it not just easier to build a simple messaging service, but an entire asynchronous applications such as the Single Page Auction Application.
If you have built a fully functioning message based app only, then the actor model of Akka will make sense to you. However, handling callbacks, parsing untyped messages from actors, implementing your own batching and most importantly, touching actual data is difficult. Akka is not actually a data store, it is closer a control flow for many messages going through it. Baratine is for all types of services: cloud based, mobile, REST, HTTP, & more.
Head over to Baratine’s Homepage to explore more about this powerful framework!