How Temporal differs to Akka and Lagom? Im looking forward on building more microservices but I’m still stuck on which stack to use.
cc @SergeyBykov since you seems to be an expert on Akka!
I see multiple dimensions here. So, it’s not easy to condense the differences into a short summary.
I think the most fundamental difference is that Temporal provides an abstraction of a persistent call stack. Every step of a business process is transparently persisted by the server, so that it can continue its execution after a failure, an unavailability of a dependency it is trying to call, or after a sleep. The server drives execution of workflows to completion, not application code. Actor systems typically employ the fail-fast approach, where instead of retrying after an error, they return such error or fail the actor altogether, and leave the decision to retry to the caller.
While one can implement a bespoke workflow framework on top of actors (by using storage and persistent timers), it’s a lot of work to build a general purpose workflow system that would be powerful enough, have a clean programming model, support all the edge cases, and be polyglot. Temporal provides a mature out-of-the-box implementation that focused on the workflow scenarios from the start, covers all those mainstream and edge cases well, scales horizontally, and has been battle tested by some of the most demanding workloads.
1 Like
Thank you Sergey for the proper reply
1 Like
With Temporal mentioning Actors as a primary use case, do you have sample application code to look at? I didn’t see much documentation other than the just the mention on the Use Cases page.
A workflow is a durable actor with all its state fully preserved. It can receive requests in form of signals and queries. Do you have a specific use case in mind?
Yes, I have described my use case and just gave a follow-up based on your feedback (thanks heaps!).
I intend to use Domain-Driven Design and that combines really well with an Actor Model. Vaugn Vernon presented a lot of information on such an architecture design. But where he advocates to turn domain aggregates into Actors, a better approach imho would be what Alexey Zimarev (who is collaborating with Proto.Actor founder Roger Johansson) proposes, and remove Actor dependency from the Domain layer and have an actor manage a domain aggregate in the Application layer. An advantage is that the actor, after retrieving the aggregate state from storage, can cache the aggregate in actor state for subsequent invocations, during its lifecycle.
Other than actors supervising domain aggregates I would have an actor hierarchy with a Server actor at the root, a Community actor, Federation actor, etc.
But I guess my response here was mostly to observe that for prospects that investigate actor systems for their tech stack, and bumping into Temporal it is not clear to see differences and similarities to the concepts they familiarized themselves with, and are e.g. comparing one-to-one to what the (very popular) Akka framework has to offer. It is not immediately clear what the subtle differences and implications of using Temporal are. Both in terms of characteristics and design patterns. While you can use it to model actor systems, Temporal has a different paradigm and needs to be ‘molded’ into that shape, as it were.
(Note that there’s other terminology that might lead investigators astray, such as Temporal’s event sourcing, which serves Temporal internally but (probably) does not fulfill ES requirements in an application design (with append-only logs in an eventstore, time-travel capabilities, etc.))
Today I found @SergeyBykov’s blog post The Curse of the A-Word that compares to design decisions made in Orleans. Maybe some blog posts like “Temporal and Actor System” or “Actors: Temporal vs. Akka” would be enlightening for prospects checking your product.
1 Like
Maybe some blog posts like “Temporal and Actor System” or “Actors: Temporal vs. Akka” would be enlightening for prospects checking your product.
I agree that a more visible comparison to Actors would be helpful for some newcomers.
In my experience, Actors has been an ever-present paradigm, but always ahead of its time. Until now?
I came here after reading about the polyglot, virtual Actors in Dapr, inspired by Sergey’s Orleans. (@SergeyBykov I nominate Active Object as that more serviceable synonym for Actor that you are looking for.)
Another article to link to this discussion: