Microservice archtecture comparision


#1

We are evaluating multiple options to building our target started architecture using reactive microservices and orchestration.
We compared heavyweight bpm products as well as light weight like camunda and recently zeebe looks very promising. We also want to look into Akka a well.

Can you provide some comparison of Zeebe with Akka when building reactive microservices?
can we integrate Zeebe with Akka in some scenarios?


#2

Hi @shashi, what do you mean by “reactive microservices”?

Take a look at these blog posts:

Zeebe itself is written using the Actor model - see: https://github.com/zeebe-io/zeebe/issues/635

You can write your task workers using Akka. But again, much of what Akka brings to the table are solutions for classes of problems that Zeebe side-steps for you architecturally.

How you pitch this depends also on what your existing tech stack / dev team looks like.

If I were pitching it to a company with Akka already implemented, then for sure I’d be pitching Zeebe + Akka. If there were no existing Akka investment, however, I would be making a table of scenarios that we needed to address with the system, and then sketching out the solutions to each one using various techs.

With Akka you get a programming model for distributed concurrent systems, and libraries that implement the primitives. Then you have to roll the whole thing.

With Zeebe you get a God Service written using the actor model that is light-weight and scalable, that allows incredible flexibility in your system design, and provides you with executable BPMN diagrams that document exactly how your system works, along with powerful operational monitoring.

It’s basically a large chunk of an Akka system pre-written, with the strongly-held opinion that there should not only be a God Service, but a Come-to-Mt-Olympus service that materialises knowledge of the architecture and centralizes running state.


#3

Actors are a fundamental model for concurrency, but there are common patterns where their use requires the user to implement the same pattern over and over. Very common is the scenario where a chain, or graph, of actors, need to process a potentially large, or infinite, stream of sequential events and properly coordinate resource usage so that faster processing stages do not overwhelm slower ones in the chain or graph. Streams provide a higher-level abstraction on top of actors that simplifies writing such processing networks, handling all the fine details in the background and providing a safe, typed, composable programming model.

From https://doc.akka.io/docs/akka/current/guide/modules.html#streams

Basically, this is Zeebe - with BPMN.

A Zeebe-based system is a hybrid that brings the best of both worlds: monolithic application - a single materialized view of the system; and microservices - decoupled, stateless, independently scalable workers.

A significant portion of Istio and Akka are solutions to deal with the impedance mismatch caused by trying to implement a stateful system purely with decoupled stateless services. As soon as you distribute you have to deal concurrency. Although your services are independently stateless, your business process is not. So you have to do a dance to deal with having state while trying to get the benefits of not having state.

Instead of pushing the complexity of the state/stateless dichotomy into the services, Zeebe acknowledges the existence of state and puts it in one place. So your stateless independent microservices can be just that.


#4

Here is another useful presentation: https://qconsp.com/sp2018/system/files/presentation-slides/3commonpitfallsmicroservicesintegrationqconsp2018camunda-180510165746.pdf