You need Event Mesh, not Service Mesh - Chris Suszynski [WJUG 301]
You've probably heard about building microservices-style applications, right? It's likely that you've heard that a service mesh (such as Istio) can help you achieve this. Unfortunately, in most cases that's an antipattern. Instead, what you need is the Event Mesh. Using the Event Mesh could help you architect your application into a distributed CQRS-style solution that would eventually reconcile system state. 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.
Recommended
More Related Content
Similar to You need Event Mesh, not Service Mesh - Chris Suszynski [WJUG 301]
Similar to You need Event Mesh, not Service Mesh - Chris Suszynski [WJUG 301] (20)
Recently uploaded
Recently uploaded (20)
You need Event Mesh, not Service Mesh - Chris Suszynski [WJUG 301]
- 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 Transactional are rare 2 We overuse it massively 3 Distorts the business logic 4 Slow and error-prone
- 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 ➔ …
- 12. Extension // MemcachedSpec defines the desired state of Memcached type MemcachedSpec struct { //+kubebuilder:validation:Minimum=0 // Size is the size of the memcached deployment Size int32 `json:"size"` } // MemcachedStatus defines the observed state of Memcached type MemcachedStatus struct { // Nodes are the names of the memcached pods 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 and manage modern serverless apps. 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
- 24. Resources ● github.com / wavesoftware / passless-operator ● github.com / cardil / cabs-usvc ● developers.redhat.com ● bit.ly/knative-tutorial