Let's get meshy! Microservices are easy with Event Mesh [KCD Czech & Slovak '24]

Building microservices is no walk in the park, especially when it comes to event-driven architectures and patterns like Event Sourcing. But, the traditional transactional coding approach often results in cumbersome code and distributed monoliths. What if there was a way to create loosely coupled, event-driven architectures without breaking a sweat?

Enter Knative Event Mesh, your key to architecting a distributed, CQRS style system that effortlessly reconciles data. You'll learn why saying goodbye to blocking API calls, lengthy transactions, and complex service meshes is the right move, and how CloudEvent based commands are a superior alternative. Inspired by the Kubernetes engine, we'll take you through a real-world example of refactoring legacy software.

Transcript

1. Public Version 1.0 Chris Suszyński @ksuszynski +krzysztof-suszynski Let’s get meshy! Microservices are easy with Event Mesh
2. About me 2 Chris Suszyński ➔ Senior Software Engineer at Red Hat ➔ Work on Knative in OpenShift ➔ Go, Rust and Java enthusiast ➔ 15+ years of experience ➔ FOSS contributor: ~80 original repos ➔ Happy father and husband
3. Public Version 1.0 Agenda ➔ Transactional lie ➔ Eventual consistency ➔ Service Mesh fallacy ➔ CQRS ➔ Event Mesh ➔ Knative ➔ Demo! Show me the code!
4. Transactional - a lie and a trap 1 Complex transactions are rare 2 We overuse it massively 3 Distorts the business logic 4 Slow and error-prone
5. Example Overuse of Transaction
6. Eventual consistency
7. Eventual Consistency Eventual Consistency is a guarantee that when an update is made in a distributed system, that update will eventually be reflected in all reads.
8. Try 1 Naive split into remote μ-Svc ➔ 12 remote calls to 5 remote μ-Svc! ➔ 99.99% uptime ^ 12 = 99.88% ➔ 1000% slower ➔ Possible data loss
9. Service Mesh fallacy The Service Mesh promises a safe layer for remote service calls. But, we shouldn’t do synchronous, remote calls apart from queries!
10. CQRS CQRS stands for Command and Query Responsibility Segregation, a pattern that separates read and update operations for a data store. Changes Command ➔ Asynchronous ➔ aka Events ➔ Do not lose it Read Query ➔ Synchronous ➔ Request, Response ➔ Safe to retry
11. CQRS example Dividing the example into Command and Queries Commands / Events ➔ CompleteTransit ➔ UpdateDestination ➔ CalculateFee ➔ DriverFree ➔ RegisterMiles ➔ IssueInvoice Queries ➔ ReadTransit ➔ ReadAddress ➔ …
12. Event Mesh
13. What is the Event Mesh? “An event mesh is a configurable and dynamic infrastructure layer for distributing events among decoupled applications, cloud services and devices. It enables event communications to be governed, flexible, reliable and fast.”
14. Event Mesh vs Service Mesh Service Mesh Event Mesh Similarities ➔ Flexibility ➔ Robustness ➔ Decoupling Differences ➔ Synchronous ➔ Request and response ➔ Better for queries ➔ Asynchronous ➔ Event ➔ Better for commands
15. based on Knative OpenShift Serverless
16. is a Kubernetes extension that allows you to deploy modern serverless apps together with event mesh. Knative
17. 17 Knative in OpenShift ➔ Knative is a CNCF Open Source project ➔ A community driven by multiple stakeholders https://knative.dev ◆ Supported by Google, Red Hat, IBM, VMware, TriggerMesh, SAP and more ➔ OpenShift Serverless: https://www.openshift.com/learn/topics/serverless ➔ Latest production-ready release: 1.32 (Knative 1.11)
18. Demo
19. Key takeaways 1 Don’t force transactional processing everywhere 2 Persist you events 3 Decouple apps 4 Event Mesh makes distributed apps “easy”
20. Resources ➔ github.com / cardil / cabs-usvc ➔ developers.redhat.com ➔ bit.ly / knative-tutorial
21. Thanks! Chris Suszyński @ksuszynski +krzysztof-suszynski Questions?