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

You need Event Mesh, not Service Mesh [Voxxed D...

You need Event Mesh, not Service Mesh [Voxxed Days Luxembourg]

You’ve heard about microservices, right? It’s likely you know a service mesh (such as Istio) can help? Most likely, that’s an antipattern! Instead, what you need is the Event Mesh. With it, you can architect your apps into a distributed CQRS-style solution, which would reconcile state eventually.

In this session, you'll learn why you should avoid using blocking API calls when building your microservices, and instead use the CQRS architecture to separate commands and queries. Your architecture for commands should be implemented with asynchronous events, which are processed whenever possible. We'll take some inspiration from the Kubernetes architecture, and how you can model such a reconciliation loop within your own enterprise microservices. All this on top of the Knative framework, as an excellent example of event mesh implementation.

Chris Suszynski

June 21, 2023
Tweet

More Decks by Chris Suszynski

Other Decks in Programming

Transcript

  1. Public Version 1.0 You need Event Mesh, not Service Mesh!

    Chris Suszyński @ksuszynski +krzysztof-suszynski
  2. About me 2 Chris Suszyński ➔ Senior Software Engineer at

    Red Hat ➔ Work on OpenShift Serverless ➔ 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 ➔ Kubernetes reconcile loop ➔ Event Mesh ➔ Knative ➔ Demos, show me the code!
  4. Transactional - a lie, trap 1 Real transactional are rare

    2 We overuse it massively 3 Distorts the business logic 4 Slow and error-prone
  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. Extension type Memcached struct { Spec struct { Size int32

    `json:"size"` } Status struct { Nodes []string `json:"nodes"` } }
  10. Reconcile loop import ( ctrl "sigs.k8s.io/controller-runtime" cachev1alpha1 "github.com/example/memcached-operator/api/v1alpha1" ... )

    func (r *MemcachedReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) { // Lookup the Memcached instance for this reconcile request memcached := &cachev1alpha1.Memcached{} err := r.Get(ctx, req.NamespacedName, memcached) ... }
  11. 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.”
  12. 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
  13. is a Kubernetes extension that allows you to deploy modern

    serverless apps together with event mesh. Knative
  14. 21 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.29 (Knative 1.8)
  15. Key takeaways 1 Don’t force transactions 2 Persist you events

    3 Decouple apps 4 Short event queue FTW
  16. Resources ➔ github.com / wavesoftware / passless-operator ➔ github.com /

    cardil / cabs-usvc ➔ developers.redhat.com ➔ bit.ly / knative-tutorial