Still with Spring? 9 reasons to Akka
As a niche consulting and development organization we end up in a lot of enterprises who would like to modernize, would like to build web-scale products but they are not ready to look beyond Spring. It is a strongly debated topic and there are reasons for still going the Spring way but the reasons are less and less as we go ahead.
For starters, this is what Eugene had to say
Spring was great for Java in its day but you can achieve far more with Traits and “Cake Pattern” instead of IOC/DI (Scala you do not need Spring framework). Akka concurrency + parallelism is more better than Spring. Even if you can have Spring employing Akka — your microservice would perform better with less bloat.
and on the same thread, Vlad mentioned
Now Akka vs Spring. It is 2017; Spring should not exist. It was born out of incompetence, misunderstanding and misery, and belongs to Java world of the past.
Anyway, let us try to get into some objective analysis of some of the parameters which matter the most
I) Reactive
- Akka: fully resilient, elastic and responsive and message-driven; the model for the Reactive Manifesto
- Spring: as of Spring 5, being advertised as “reactive”, but new asynchronous capabilities do not equal reactive, traditional pre 5 spring highly synchronous and blocking, state of the art in building monoliths
II) Modeling
- Akka: think in terms of actors, representing things, mapping to domain driven design;
- Akka presents your cloud as a virtual supercomputer, fitting billions of actors, across many nodes
- Spring: think in terms of objects, operating in an MVC world, limited to a single node
III) Application State
- Akka: persistent actors, distributed across a cluster, contain in-memory state and the ability to make real-time decisions without contention; share events and keep state private
- Spring: the state is contained in the database, represented as CRUD; contention between spring nodes against the state in a central database can be a big issue
IV) Resilience
- Akka: actors are resilient and have failure strategies, clustered nodes are resilient, actors will be moved to healthy nodes; Akka separates failure logic and makes it a first class citizen
- Spring: try/catch spaghetti
V) Persistence
- Akka: persistent actors uniformly shard across the cluster, enabling singleton, non-replicated behavior, backed by the immutable event log
- Akka: persistence store backed by many plugins
- Spring: limited to CRUD, against your choice of database
VI) Elasticity
- Akka: seamless horizontal and vertical scaling
- Spring: roll your own solution to scale with additional stateless nodes, no ability to be elastic with the current running footprint
VII) Standards
- Akka: modules default to event sourcing, CQRS, domain driven design, and eventual consistency, utilizing a reactive programming model
- Spring: none of the above standards is a natural fit and would need to be built in the endpoints, in other words, someone will be in the framework business once you incorporate all of this in Spring
VIII) Integrations
- Akka: reactive systems paradigm using asynchronous, non-blocking service to service communication, fully decoupled
- Akka: Alpakka library for asynchronous integrations
- Spring: service to service real-time callout heck-fire, brittle with chained failures
IX) Learning Curve
- Akka: medium/high, mostly associated with the move to a reactive programming model
- Spring: medium/high for Spring 5, which is a significant change over previous versions
To be fair to Spring, let us give some points where it deserves
Developers availability
This is where Spring would win hands down. There are tons of developers doing imperative Java and if you want to be building legacy code today then that is a choice that you have to make.
Originally published at blog.knoldus.com on November 14, 2018.
