Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Why Actor-Based Systems Are The Best For Microservices


Published on

Nowadays microservices are widely adopted in the industry, but we're still trying to understand the best practices for building and maintaining successful systems. HTTP/RPC synchronous communication is very popular in microservices, but it has a lot of challenges like service discovery, retries, back-pressure, etc. From the other side, microservices can be build to communicate asynchronously using messages. This approach also has its pros and cons, but I'm confident that most of the businesses can benefit from it. Also, messages are natural way to exchange data in actor-based systems, so it should be possible to leverage actors for building great microservices environments. I want to share my experience and show how Enterprise Integration Patterns can be used to design and build fine-grained microservices with asynchronous communication using actors.

Published in: Software
  • Be the first to comment

Why Actor-Based Systems Are The Best For Microservices

  1. 1. Technical Overview [Client] [Date] Why Actor-Based Systems Are The Best For Microservices Yaroslav Tkachenko Senior Software Engineer, Lead at Mobify @sap1ens
  2. 2. Monolith Microservices
  3. 3. “Easy” way – HTTP / RPC API POST /foo
  4. 4. § 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
  5. 5. But wait… How about Netflix, Twitter, etc.?
  6. 6. 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?
  7. 7. Reactive Revealed: Resiliency, Failures vs Errors, Isolation, Delegation and Replication by Jonas Boner
  8. 8. Surviving Micro-services by Richard Rodger
  9. 9. So, let’s try to: § Use message queues for communication § Use actors as publishers and subscribers
  10. 10. - Send … - Receive … Another way - Messaging - Send … - Receive …
  11. 11. Enterprise Service Bus?
  12. 12. Kafka Connect
  13. 13. 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!
  14. 14. 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!
  15. 15. External request (HTTP)
  16. 16. External request (HTTP)Write Always asynchronous using messages Read Alternatives to blocking call: - Caching - Denormalization - Different routing
  17. 17. Example: integrations
  18. 18. “Macroservices” External APIs
  19. 19. “Macroservices” External APIs New user!
  20. 20. “Macroservices” External APIs New user! User created
  21. 21. EIP was published in 2003 and it contains 65 patterns
  22. 22. Enterprise Integration Patterns
  23. 23. Patterns from the example: § Publish – Subscribe Channel (“Broadcast”) § Durable Subscriber § Idempotent Receiver
  24. 24. So, have I convinced you that messaging patterns are great?
  25. 25. But why actors? I can just use a message queue and a bunch of consumers/producers
  26. 26. It’s all about semantics
  27. 27. 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.
  28. 28. Actors are known for concurrency, but let’s focus on message passing instead
  29. 29. Actors in Scala/Akka and Erlang
  30. 30. Actor ActorMessage
  31. 31. Actor ActorMessage queue
  32. 32. ActiveMQ message listener in Java (just kidding)
  33. 33. ActiveMQ message listener in Java (zoom-in)
  34. 34. Actor-based (Akka) message listener in Scala + Camel
  35. 35. Receiver Handler onMessage(Message) ??? Receiver ActorSender Actor Mailbox Message VS
  36. 36. 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
  37. 37. 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)
  38. 38. 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
  39. 39. Instead of a summary: Everything is a trade-off!
  40. 40. Questions? @sap1ens