Microservices are steadily gaining the ground these days. Naturally, there are a good many of tools and frameworks that can be used for building microservices architecture. Among them, Akka stands out with its actor model and claim to provide possibilities for creating reactive systems, which were defined in the Reactive Manifesto and have had much excitement surrounding them lately. Besides, Akka is a set of mature libraries with a really good knowledge base and extensive documentation, which means less time and efforts to start with. All these serve as a good motivation to consider its strengths and weaknesses for application development, which is exactly what this article is about.
Akka is a free and open-source toolkit from Lightbend, initially released in July, 2009 for building concurrent distributed applications. It was inspired by Erlang and originally written in Scala, but today also has API for Java application development. In 2015, Akka won JAX Award for “the Most Innovative Open Source Technology”.
As mentioned above, Akka is built upon the actor model. An actor is a set of code that communicates with other actors via messages. Actors are hardly something new for this world and were already described by Carl Hewitt in 1973.
For actors to be what they are, namely, completely independent units, each of them needs to cover processing, storage and communication. Actors only receive and send messages, while their internal logic always remains intact and cannot be accessed directly. Actors are not supposed to share any mutable states by default and they check all the incoming messages so that they don’t have any.
For managing the messages, each actor has its own mailbox. In the mailbox, a single thread of control enqueues all the incoming messages in a strictly fixed order and generates one message at a time to the actor.
Processing a new message, the actor can react in three possible ways:
There are also three possible ways for the actor to send a message:
Owing to the actor model, Akka looks similar to Erlang and Cloud Haskell, but offers many other beneficial features in addition, e.g. with Akka, you can create a singleton actor or assign roles for the actors and create a actor tree hierarchy.
Now we are ready to move forward and discover the good and bad about the use of Akka in Java application development.
Akka claims to allow building reactive miсroservices. Behind this plain term is a combination of microservice architecture and reactive systems principles – namely resilience, scalability, elasticity and message-driven character – mentioned in the famous Reactive Manifesto. Actually, one of the Akka’s creators, Jonas Bonér, is also one of the authors of the Reactive Manifesto. It seems, Akka was set to inherit some ‘reactivity’ at the genetic level.
So, how does it work? With Akka, microservices simply turn into actors and this brings the following ‘reactive’ bonuses to the system:
Meanwhile, the future users, in their turn, benefit from improved UX – as async streams make an application work faster and smoother, improved responsiveness – as in case of any outer or inner system problems there will always be a high-level actor that communicates response to a user not to leave them in the dark, improved performance – as the system is split into independent units and you can easily scale its performance, if needed.
However, everything comes with its trade-offs, and Akka is not an exception. The thoughtless use of Akka and lack of team’s experience with this framework may result in rather disastrous mistakes in a future product. The challenges, which you’re likely to encounter during application development employing Akka, involve:
Akka is an actor-based framework that claims to bring the principles of ‘reactivity’ into microservices architecture. To a certain extent, Akka’s actors can introduce significant benefits to the system, such as high-load tolerance, easy scalability, strong failure resistance and more efficient resources use. However, a sound experience is required to succeed with Akka reactive microservices architecture as there are many sharp edges you can come across at the development process (for example, too many actors, distributed transactions, shared mutable states) and insufficient competence in addressing these issues may lead as far as to a total project failure.