Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

Let's get meshy! Microservices are easy with Ev...

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.

Chris Suszynski

June 06, 2024
Tweet

More Decks by Chris Suszynski

Other Decks in Programming

Transcript

  1. 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
  2. Public Version 1.0 Agenda ➔ Transactional lie ➔ Eventual consistency

    ➔ Service Mesh fallacy ➔ CQRS ➔ Event Mesh ➔ Knative ➔ Demo! Show me the code!
  3. 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
  4. 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.
  5. 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
  6. 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!
  7. 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
  8. CQRS example Dividing the example into Command and Queries Commands

    / Events ➔ CompleteTransit ➔ UpdateDestination ➔ CalculateFee ➔ DriverFree ➔ RegisterMiles ➔ IssueInvoice Queries ➔ ReadTransit ➔ ReadAddress ➔ …
  9. 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.”
  10. 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
  11. is a Kubernetes extension that allows you to deploy modern

    serverless apps together with event mesh. Knative
  12. 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)
  13. Key takeaways 1 Don’t force transactional processing everywhere 2 Persist

    you events 3 Decouple apps 4 Event Mesh makes distributed apps “easy”