Composing Software - Avoiding the distributed monolith

Move cross cutting concerns from code into infrastructure

Transcript

1. Avoiding the distributed monolith
2. Roger Johansson Akka.NET and Proto.Actor Founder Solution Architect - Betsson Group Twitter: @rogeralsing Github: rogeralsing Mail: rogeralsing@gmail.com Github.com/rogeralsing/presentations http://Proto.Actor
3. Went all in on actors four years ago, porting Akka to .NET. I’ve seen a fair share of ”actor all the things” abuse since. I have an interest in IT strategy; Trade-offs, exit strategy, adoption, direction of the industry How can we build distributed systems without the framework lock-in?
4. How do we deal with concerns such as: • Concurrency • Stateful services • Elasticity • Streams • Service Discovery • Fault tolerance • Cluster Management
5. Infrastructure e.g. Load balancer, Docker Swarm, Kubernetes etc ”Platform” / Framework e.g. Akka, Microsoft Orleans, OTP Middleware e.g. Kafka, Consul, Rabbit etc. Service A Service B
7. source worker2 worker1 worker3 Cluster Network Whatever you have here Is also here
8. source worker2 worker1 worker3 Cluster Framework specific protocols For example, all of the major Actor Model frameworks and languages have their own specific homegrown protocols Erlang OTP, Akka, Akka.NET, MsOrleans, none of them can talk to eachother using their own cluster protocols. Network Homegrown, non standard, framework specific protocol (OTP is a special case)
9. source worker2 worker1 worker3 Cluster Network But Akka can talk to Akka.NET, no?
10. Exit strategy, how do you step by step migrate off your current platform? What if the framework is no longer maintained, or there is a top level decision to move to another platform? Total cost of ownership, what is the cost of re-writing most or all of it?
12. Stateless Easy to scale out Stateful Harder to scale out State needs to move around when nodes fail. Everyone need to agree on what node owns the state. The more state you have, the heavier it is to move around. High consistency Easier Harder Concurrency control High availability Easier Harder High Availability
13. Infrastructure e.g. Load balancer, Docker Swarm, Kubernetes etc ”Platform” / Framework e.g. Akka, Microsoft Orleans, OTP Middleware e.g. Kafka, Consul, Rabbit etc. Elasticity and concurrency should it be handled here? Here? Service A Service B Or here? Or maybe here?
14. Cluster producer consumer consumer consumer Embracing The Unix Philosophy What if we instead shrink the responsibility of the cluster? Instead of encapsulating everything, including business logic, we can limit the scope to data transport and cluster semantics only.
15. source worker2 worker1 worker3 Cluster producer consumer consumer consumer Cluster consumer The cluster mechanism is separated from the components. The Components only need to agree on the protocols and contracts of the cluster, or use a prebuilt tool for this purpose, e.g. Apache Kafka, RabbitMQ, Consul etc.
16. source worker2 worker1 worker3 Cluster producer Elasticity by partitions (Kafka) We start out by having a higher number of partitions than consumers. partition partition partition consumer partition partition partition partition partition partition consumer consumer
17. source Cluster producer partition partition worker1 consumer partition partition partition worker4 consumer partition partition worker2 consumer partition partition worker3 consumer Elasticity by partitions Once a consumer is added, the partitions are rebalanced across the avaiable consumers. This allows consumers to scale up to the same number as the avaiable partitions. Sticky partitons coming to Kafka in v 0.11.0.0
18. Cluster partition partition worker1 consumer partition partition partition worker4 consumer partition partition worker3 consumer Partition to State affinity By partitioning events based on some form of unique identifier, e.g. CustomerId, Region or similar, we can make sure all events that belong together end up on the same partition. Once the events are assigned to a specific partition, it’s easy to build a stateful system behind the worker consuming this partition. Stateful worker2 source producer partition partition consumer
19. Cluster partition partition worker1 consumer partition partition partition worker4 consumer partition partition worker3 consumer Stateful worker2 source producer partition partition consumer Partition to State affinity This is conceptually similar to Akka Cluster Sharding and MsOrleans in the sense that developers do not need to care where objects are placed.
20. Chose your own abstraction Unlike opinionated, prepackaged frameworks, you are now free to chose your own abstractions. Use Actors, Reactive Extensions, DataFlow, or just simple objects. Cluster partition partition worker1 consumer partition partition partition worker4 consumer partition partition worker3 consumer worker2 source producer partition partition consumer TPL
21. partition partition worker1 consumer partition partition partition worker4 consumer partition partition worker3 consumer worker2 source producer partition partition consumer Summarising • Platform agnostic, can be polyglot • Abstraction agnostic, pick the right tool for you • Message order guarantee • Message delivery guarantee • Automatic placement of actors/channels/objects • High Availability • Horizontal Scaling • High throughput • Low latency Platform agnostic Abstraction agnostic Message order, Message delivery guarantees High Availability, Horizontal Scaling Automatic placement Excellent performance
22. Code?, Platform?, Infrastructure?
23. Infrastructure e.g. Load balancer, Docker Swarm, Kubernetes etc ”Platform” / Framework e.g. Akka, Microsoft Orleans, OTP Middleware e.g. Kafka, Consul, Rabbit etc. Service Discovery and cluster membership should it be here? Here? Service A Service B Or here? Or maybe here?
25. Code?, Platform?, Infrastructure?
26. Infrastructure e.g. Load balancer, Docker Swarm, Kubernetes etc ”Platform” / Framework e.g. Akka, Microsoft Orleans, OTP Middleware e.g. Kafka, Consul, Rabbit etc. Cluster Management should it be here? Here? Service A Service B Or here? Or maybe here?
28. Code?, Platform?, Infrastructure?
29. Infrastructure e.g. Load balancer, Docker Swarm, Kubernetes etc ”Platform” / Framework e.g. Akka, Microsoft Orleans, OTP Middleware e.g. Kafka, Consul, Rabbit etc. Retry mechanisms? Here? Here? Service A Service B Or here? Or maybe here?
30. Per server Network Proxy Retry on failed request Circuit breakers https://github.com/containous/traefik
31. A Resilient Service Mesh Retry on failed request Circuit breakers https://linkerd.io/
33. Lightweight Actor Model Toolkit: • Built on standards • Platform independent • Actors and Virtual Actors • Ultra fast Proto.Actor
34. Lightweight Actor Model Toolkit: • Built on standards – Protobuf, HTTP/2 Streams, Consul • Platform independent – C#, Go, Python, Javascript, Kotlin • Actors and Virtual Actors – Akka, Microsoft Orleans • Ultra fast – 65 times faster than Akka.NET over network Proto.Actor
35. The End Roger Johansson Twitter: @rogeralsing Github: rogeralsing Mail: rogeralsing@gmail.com Github.com/rogeralsing/presentations http://Proto.Actor