Which is better, an actor system handling requests and registering to a network or a microservice? That question is probably not asked often enough. This article examines this question from a theoretical standpoint prior to deployment in a production system.
Benefits of Microservices
We often decide to incorporate microservices simply because they have been the go to for quite some time, forgetting about the actor model all together. In understanding our debate, we need to layout the benefits of the microservice.
- Allow for flexibility by allowing code to change in an application
- Allow different applications to scale autonomically based on need
- Allow for different teams to focus on different tasks without needing to know the implementation of another team’s tasks
However, they also:
- Can grow complicated and not take into account interaction between services directly, slowing the system down
- Require more knowledge of other team’s APIs (a poor con)
- Require a layer of abstration that leaves them somewhat vulnerable and are often implemented insecurely
Benefits of Actor Models
Actor models are fast, efficient, and have benefits as well. In particular, they:
- Allow flexibility by allowing a node to change behavior or state
- Allow different parts of a system to scale automatically based on need
- Take into account different interactions between services
- Tend to be more secure. Think of block chain as a database version of an actor system. It maintains state and is contained.
- Simplifies different components (both a pro and a con)
However, actor models:
- May or may not require knowledge of the implementation produced by other teams
- Require a great deal more work to become as flexible and abstract as microservices
- Are more difficult to change
- Tend to perform blocking requests poorly
- Require extra work to stabilize
Microservices are clearly great for company wide tasks but what about internally to each team where microservices can complicate matters significantly due to their inherent complexity. This is where actor models shine. For instance, if we want to manage different machines in a non-blocking manner to kick off different tasks, actor models perform well. Perhaps we are creating a set of nodes in the system to manage celery workers and producers. This is the debate going on in my open source CeleryETL system at the moment.
Feel free to comment!