Why Actor-Based Systems Are The Best For Microservices
2 likes952 views
The document discusses why actor-based systems are well-suited for microservices architectures. Actor models use message passing for communication between loosely coupled components, avoiding tight coupling issues of HTTP/RPC APIs. Message queues provide lightweight pub/sub messaging that is scalable, available, and promotes eventual consistency over tight synchronization. Actors represent message-driven processes that handle incoming messages asynchronously, supporting natural distributed and concurrent processing. Their built-in failure handling, routing, and back-pressure capabilities make actors a simple and high-level abstraction well-aligned with distributed, message-driven microservices.
![Technical Overview
[Client]
[Date]
Why Actor-Based Systems Are
The Best For Microservices
Yaroslav Tkachenko
Senior Software Engineer, Lead at Mobify
@sap1ens](https://image.slidesharecdn.com/yaroslavtkachenko-170428142948/85/Why-Actor-Based-Systems-Are-The-Best-For-Microservices-1-320.jpg)
Why Actor-Based Systems Are The Best For Microservices
- 1. Technical Overview [Client] [Date] Why Actor-Based Systems Are The Best For Microservices Yaroslav Tkachenko Senior Software Engineer, Lead at Mobify @sap1ens
- 4. “Easy” way – HTTP / RPC API POST /foo service-x.example.com
- 5. § Destination – where to send request? § Service discovery § Tight coupling § Time – expect reply right away? § Failure – always expect success? § Retries and failure handling § Back-pressure / circuit breakers
- 6. But wait… How about Netflix, Twitter, etc.?
- 7. Yes, it’s possible to build reliable systems with HTTP/RPC APIs! But: § Are you ready to invest a lot of resources § Do you really need it?
- 8. Reactive Revealed: Resiliency, Failures vs Errors, Isolation, Delegation and Replication by Jonas Boner
- 9. Surviving Micro-services by Richard Rodger
- 10. So, let’s try to: § Use message queues for communication § Use actors as publishers and subscribers
- 11. - Send … - Receive … Another way - Messaging - Send … - Receive … queue.events
- 13. Kafka Connect
- 14. So, why message queues now? § Not ESBs! § Lightweight pub/sub instead § Low coupling § Promotes eventual consistency § Highly scalable and available § Built-in discovery, retries, tracing, etc. § Serverless!
- 15. By the way, I don’t think that ALL your communication should happen through the message queues. But it’s something that you should strive for!
- 17. External request (HTTP)Write Always asynchronous using messages Read Alternatives to blocking call: - Caching - Denormalization - Different routing
- 20. “Macroservices” External APIs New user!
- 21. “Macroservices” External APIs New user! User created
- 22. EIP was published in 2003 and it contains 65 patterns
- 24. Patterns from the example: § Publish – Subscribe Channel (“Broadcast”) § Durable Subscriber § Idempotent Receiver
- 25. So, have I convinced you that messaging patterns are great?
- 26. But why actors? I can just use a message queue and a bunch of consumers/producers
- 27. It’s all about semantics
- 28. An actor is a computational entity that, in response to a message it receives, can concurrently: • send a finite number of messages to other actors • create a finite number of new actors • designate the behavior to be used for the next message it receives.
- 29. Actors are known for concurrency, but let’s focus on message passing instead
- 30. Actors in Scala/Akka and Erlang
- 33. ActiveMQ message listener in Java (just kidding)
- 34. ActiveMQ message listener in Java (zoom-in)
- 35. Actor-based (Akka) message listener in Scala + Camel
- 36. Receiver Handler onMessage(Message) ??? Receiver ActorSender Actor Mailbox Message VS
- 37. I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages... OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late- binding of all things. Alan Kay, one of the fathers of the idea of object-oriented programming
- 38. Actors over message handlers: • Semantically natural message processing that ”feels right” • No difference between local and remote communication • Straightforward state management • Mailbox, routing and back-pressure • Built-in failure handling (supervisors)
- 39. Actors in general: • Simple and high-level abstraction for distribution, concurrency and parallelism • Asynchronous, non-blocking and highly performant message-driven programming model • Very lightweight message-driven processes
- 41. Instead of a summary: Everything is a trade-off!