This post outlines the event-driven and message-driven architectures that are foundational for micro-service communication in an enterprise level business application. There are different kind of messages that you can send to others are fall under these architectures. It also describes the standards on CNCF Cloud events.
Message-Driven Architecture flow
Command – you expect someone else to do something. Transfer – you take a file and transfer to someone else; you have a Job that eventually being done. Command, Query, Job and Transfer share something common i.e., these messages carry expectations. you send a message and expect someone to do something. These are Intents. Message-driven all about relationship and basically an imperative flow with pre-determined actor roles. work is assigned, executed and completion reported.
Event-Driven Architecture flow
Report – you tell someone about something happened. Notification – Hey something happened These messages are about telling someone something happened, but you mostly leave it to them what they want to do about it. These are Facts. Events are typically partitioned by context, time ordered, analyzable and actionable. They can also report a condition of a system. Events are an extensibility enabler, simply reactive extension of a service.
An event is a manifestation of an occurrence somewhere, something happens we capture that fact, and we make that known. some consumers might not care you publish messages and in case if someone interested in then they will subscribe and use that information to perform some actions. No pre-determined execution plan or actors. work is volunteered, reacting to events and completion is shared. changes or extensions are local to the actors.
Complex enterprise applications require both architectures in different areas. Event driven is for extensibility and Message driven is for core and pre-defined operations. Everything is always in application not necessarily be an event driven or Everything always been RPC imperative. If you look at AWS, Google or Microsoft they follow same kind of service as shown in following picture
They take events and distribute those events in push style to a server less or messaging infrastructure. Infrastructure go and call the web-hook for you. why do they exist? if destination is down or busy then infrastructure helps to get that event delivered. Exclusive ownership is top feature of the queue. it’s not the order. Queue keeps tracks of life cycle of every message where event infrastructure is not
Event streaming is not modern, and Queues are not “traditional”. Both are patterns of state-of-the art in messaging infrastructures. Modern apps use events and queue-based messaging. core functions of service require direct, point-to-point RPC. Event stream is sequence of events that are belong to the same context.
Events Parallelization Matter
As soon as the raw events arrive then you may want to process, analyze, archive and visualize them in parallel. Event streams solve a particular problem in timeliness, in many event streams – fresh-ness of data is matter. Event data value is high when it is fresh.
What is CNCF cloud EVENT?
Cloud event is an information model that event has an identifier. It has time at which was created. It has a type, and it has a source where it came from, and it has subject what it is about. It then carries the data. Event data is often hoped multiple-routes and often using different protocols and including intermediaries that are not often under one single party control, so we need standards.
Cloud events then define data formats (Avro, Protobuff, JSON, AMQP etc) in which an event can be expressed, and protocol bindings used for transportation. for instance, with HTTP – we are able to take a cloud event and map that cloud event straight onto an HTTP message where the attributes of the cloud event become headers in HTTP., which mean you can take any application and make it Cloud Events aware. by adding extra attributes. Google, SAP and Microsoft started thinking about defining a message structure for events.
schema registry used to define these encoded data structures. CNCF now standardizing the schema registry by separating the encoding data structures to external files. These data structures need to be visible to both producers and consumers. CNCF trying to standardize this Schema registry through API and also defining patterns or templates for messages. Eg: here is the service and these are the 5 events that it is raising. At present there is no formal way to represent them in event stream engines. Following picture outlines the discovery and message catalog standardization
Following AZURE resources helps you to implement the above outlined architectures if you choose using Microsoft AZURE as hosting platform
AZURE provides a fleet of Messaging services that include
Each messaging service suites for a particular scenario and they share common principles and provides the compossibility. If you are specifically interested in asynchronous messaging patterns, then you can refer the following resource. There is a misconception in treating Apache Kafka as message queue. Kafka is not a message queue. If you call Kafka topic as queue, then you are wrong. Kafka does not have individual management of life cycle of messages. You cannot query the length of the queue and messages in topic are not exclusively consumed by one consumer. Consumer group can scroll back and forward over the message stream in topic. There are no queue features in Apache Kafka. Kafka is an event stream engine but not a queue boat.
