You need Event Mesh, not Service Mesh [CodeEurope]

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.

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. Example Overuse of Transaction
6. Eventual consistency
7. 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
8. 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!
9. 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
10. CQRS example Dividing the example into Command and Queries Commands / Events ➔ CompleteTransit ➔ UpdateDestination ➔ CalculateFee ➔ DriverFree ➔ RegisterMiles ➔ IssueInvoice Queries ➔ ReadTransit ➔ ReadAddress ➔ …
11. Kubernetes reconciliation loop
12. Extension type Memcached struct { Spec struct { Size int32 `json:"size"` } Status struct { Nodes []string `json:"nodes"` } }
13. 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) ... }
14. Demo
15. Watch out! Kubernetes' reconciliation loop relies on ETCD watch feature. It works until a point, ~100k records.
16. Event Mesh
17. 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.”
18. 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
19. based on Knative OpenShift Serverless
20. is a Kubernetes extension that allows you to deploy modern serverless apps together with event mesh. Knative
21. 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.28.0 (Knative 1.7)
22. Demo
23. Thanks! Chris Suszyński @ksuszynski +krzysztof-suszynski Questions?
24. Resources ➔ github.com / wavesoftware / passless-operator ➔ github.com / cardil / cabs-usvc ➔ developers.redhat.com ➔ bit.ly / knative-tutorial