Cloud-Native Architecture & Design — Event Mesh and Service Mesh architecture
Managing across a few microservices is easy and does not require any extra management layer but when microservices grow in your enterprises, you may face many challenges of managing services in a cloud-native environment.
Many loosely coupled services that are independently and frequently changing do promote agility but introduces a lot of management challenges. Some of these challenges are traffic management, communication security, communication failures, etc. Many of these challenges can be resolved directly by writing code in service but embedding these configurations in a code poses a lot of challenges because these configurations are complex and extremely error-prone.
There is two way you can handle these challenges without embedding code in service for APIs interaction and Event interaction across microservices, they are:
- Service Mesh
Provides connection-level routing and traffic management for synchronous communication (HTTP(s)) interaction through sidecar injection into Kubernetes pods. The service mesh is focused on routing connection between endpoints by hijacking the connection requests and overriding the connection requests from the microservices
- Event Mesh
Handles asynchronous event-driven routing of information between microservices. It intelligently routes events between the event brokers allowing the cluster or brokers to appear as a single virtual event broker.
The Mesh frameworks allow you to observe, secure, and connect microservices. these don’t establish connectivity between microservices but instead, have policies and control applications on top of the existing network to govern how microservices interact. These frameworks shift implementation logic out of microservices code and moves to the network.
The Service Mesh and Event Mesh are not mutually exclusive, and you may consider implementing both depending on the use cases.
Service Mesh
gateway centralizes the configuration and routes to the relevant microservices, and it can handle orchestration but with limitations.
The advent of cloud-native architecture and with use of container and microservices platforms brought the need for an orchestrator. The containers and orchestrators coupled with the microservices for their speed to market, and silos of the development pods, lead to service sprawl. The ability to run several distributed services brought the need for a service mesh.
A service mesh solves the problems where microservices communicate using APIs. A service mesh uses the sidecar pattern to establish communication between microservices and ensure that communication among containerized and often ephemeral application infrastructure services is fast, reliable, and secure.
Service Mesh Implementation
A service mesh will have a control plane to program the mesh and sidecar and serve as the control point for securing, observing, and routing decisions between services. The Control Plane transfers configurations to the proxies and each proxy intercepts all inbound and outbound traffic. By intercepting traffic, the proxies will inject behavior into the communication flows between microservices.
Following are the behavior will handle by Service Mesh:
- Traffic shaping with dynamic routing controls
- Resiliency support for service communication such as circuit breakers, timeouts, and retries
- Observability of traffic between services
- Tracing of communication flows
- Secure communication between services
In the above figure, all services A, B, and C are executed through sidecar proxies, by having communication routed between the proxies, the proxies serve as a key control point for performing a task such as initiating transport layer security (TLS) handshakes for encrypted communication with above behaviors.
Service mesh routes data based on the connection URL and the ability to redirect a connection based on the content routing rules against the URL and HTTP header information.
Services Meshes are one layer of your infrastructure and don’t provide all that you need. They do give you the ability to bridge the divide between your infrastructure and your application.
Advantages and Disadvantages of Service Mesh
The advantages of Service mesh offering distributed debugging, providing topology and dependency management, participate in application life-cycle management, and participate in service and product management, deeper observability, multitenancy, multi-cluster, cross mesh, and advanced circuit breaker with fallback paths, etc.
The service mesh provides simpler and offloading network configuration from microservices but with some radar, these are all:
- No support of the asynchronous event or stream processing
- Most traffic and network services only apply to synchronous communication and HTTP and grpc protocol
- Limited the connection-oriented routing and targeting of the transport connection, not the routing of actual data.
Microservices are using diverse message interaction patterns including publish/subscribe, point-t-point, push-with-reply, queuing, etc. in today’s world, the microservices require to need higher throughput and lower latency that you can meet by using Kubernetes clusters. It takes choreography rather than orchestration processing. In cloud-native architecture, the microservices require event-driven architecture because they require eventing capability, performance, real-time processing that spans beyond a Kubernetes cluster. Here, you require an Event Mesh.
Event Mesh
A cloud-native modern enterprise embraces event architecture and every driven application requires a robust central system to move events quickly, reliably, and securely from publisher to subscriber.
An event mesh is an architectural layer that dynamically routes events from one microservices to another irrespective of deployment location. The event mesh is a key enabler for event-driven architecture. An event mesh is a dynamic infrastructure that propagates events across disparate cloud platforms and performs protocol translation.
A single event broker can only handle a certain volume of requests and microservices, there are different to scale and one way is the Event Mesh.
In an event mesh, there is no underlying technology such as Kubernetes, and event brokers are designed to operate with or without a cloud. Event mesh routes data based on topics and is transported with the event payload. It is a dynamic infrastructure that propagates events across multi-cloud platforms and performs protocol translations.
The figure illustrates elements of an event mesh, events can flow bi-directional across the microservices irrespective of where they are deployed, whether it is in the same cloud or multi-cloud, or hybrid cloud.
Event mesh is configured along with event broker and it translates by any application with different languages and deployed in the different cloud will publishes an event and translates and let the subscriber of another application deployed in a different cloud subscribe to an event which is deployed in the different cloud and also can be different API altogether. This helps to separate the configuration from the business logic in microservices.
Characteristics of Event Mesh
Below are the characteristics of event mesh:
- Made up of interconnected event brokers
- Environment Agnostics can deploy in any public cloud, PaaS, or non-cloud environment
- Dynamic and intelligent routing.
- Security and WAN optimization
Event Mesh capabilities
The following are the Event mesh capabilities, and these are must require for modern-day architecture.
- Supports for publish and subscribe of events in various protocols such as Kafka, Knative, HTTP, AMQP, etc.
- Support for multi-protocol bridges between disparate events, microservices, and messaging platforms
- It supports on-premises and multi-cloud deployment to provide a uniform infrastructure
- Secure transmission of event messages
How Event Mesh works?
Let’s consider an example of Event Broker’s event routing capability. The producer of events connected to an event broker and publishes an event to the broker. In this below example, the Order service publishes a three event messages each with a different topic associated.
Subscribers of events connected to the event broker and register with the topic and configure the event type. When event messages arrive in the event broker, it routes them to the subscriber based on their subscriptions. In the above example, “/Inventory” would go to Inventory service, the event with /Payment would be routed to the payment service and the /dispatch event would be routed to the Dispatch service.
The consuming microservices like Inventory, Payment and Dispatch are processing asynchronously and potentially in parallel. Each service only uses processing overhead when the event broker forwards an event based on the subscriptions. Event broker abstracts the routing of events between publisher and subscriber. All event brokers persist messages and don’t need to be available when the event is initially published. The option of receiving events that were published while they were offline, but impacts the customer experience.
Event Mesh in a cluster of Brokers
I explained how the event broker manages the routing rules in a single broker, the complexity arises when you have a cluster of brokers and each message are subscribed in a separate event broker, how will you manage this, the one options are to embed code in your microservices or configure in event broker to manage in a cluster. This is where event mesh is useful to coordinate and collaborate across multiple event brokers to streamline the routing and publishing and subscription.
In this example, the Order Microservice sends a message to Event Broker 1 and asks for an Order from the location to check inventory, local distribution, and local dispatch. All four microservices are deployed in the separate cloud with respective event brokers for ex, the Inventory microservices ask for any order microservices to check a local inventory where the order is originated. All brokers are connected with the event mesh, so that subscription is forwarded to the other event brokers in another cloud. When the matching event is published to Event Broker 1, the event mesh will forward it to Event Broker 2, because no microservices are connected to another event broker for this request but other microservices are required to subscribe for other orders events once the inventory is confirmed. The Inventory microservices checked the inventory and publish an event to Event Broker 2 for availability and Event Mesh route to Event Broker 1.
Order Microservices confirms the order and publishes an event “confirm”, the Event Mesh routes to Event Broker 2 and Inventory microservices subscribes to “Confirm” events and update stocks and publishes an event “confirm with the item” to the Event Broker 2, the Event Mesh checks the 3 and 4 for event subscription, the Distribution microservices subscribes to “confirm with the item” and event mesh routes to Event Broker 3 and distribution microservices consume and ready for dispatch by publishing events to “dispatch” to Event Broker 3, Event Mesh routes to Event Broker 4 for dispatch. All these microservices and event brokers are deployed in multi-cloud environments and Event Mesh can route within the cloud or multi-cloud environment.
While each Event Broker provides its local routing table based on topics, the control plane of the event mesh dynamically and transparently extends that routing information among all interconnected event mesh broker nodes like the internet does for IP routes.
This is the way the event mesh makes many event brokers look like a single virtual event broker; it uses broker routing protocols so intelligently, dynamically, and efficiently route events.
Event Mesh’s Control Plane
Not all event brokers enable an event mesh. The clustering of event brokers to provide high availability or local horizontal scaling is not an event mesh. If the local cluster does not provide intelligent routing between other clusters then the event broker doesn’t constitute an event mesh. Every event broker that does enable an event mesh provides a control plane.
The event broker must provide the tooling and capabilities like Kubernetes for service mesh. The control plane must provide High Availability (HA) for event nodes and Disaster Recovery (DR) for broker nodes. The characteristics of the control plane are:
- Configuration and monitoring of event broker nods in a HA cluster
- Dynamic real-time updates for routing tables on all event brokers nodes and clusters
Conclusion
The Service Mesh and Event mesh works in different environments and for different use cases but both can collaborate in an application, for example, a few microservices are required to work in synchronous HTTPs or grpc protocol and few microservices required event-driven capability. In this case, the service mesh can be used for synchronous microservices and event mesh can be used for event-driven microservices