Building Event-Driven Microservices

🧠 Free Recall ❓ Quiz 🔍 Cues 🔮 Simulation 🥷 ShadowBox 📐 Encode Cards

Why EDA Microservices

Event-based communication is certainly not new, but the need for handling big data sets, at scale and in real time, is new and necessitates a change from the old architectural styles.

In a modern event-driven microservices architecture, systems communicate by issuing and consuming events. These events are not destroyed upon consumption as in message-passing systems, but instead remain readily available for other consumers to read as they require.

The services themselves are small and purpose-built, created to help fulfill the necessary business goals of the organization. may emit their own output events, provide data for request-response access, communicate with a third-party API, or perform other required actions.

This combination of event streams and microservices forms an interconnected graph of activity across a business organization.

Each event in a stream is a statement of fact, and together these statements form the single source of truth the basis of communication for all systems within the organization. A communication structure is only as good as the veracity of its information, so it’s critical that the organization adopts the event stream narrative as a single source of truth. If some teams choose instead to put conflicting data in other locations, the event stream’s function as the organization’s data communications backbone is significantly diminished.

Bellemare, Adam. Building Event-Driven Microservices (p. 27). O'Reilly Media. Kindle Edition.

Not all data must be shared, and thus not all of it needs to be published to the set of event streams. However, any data that is of interest to any other team or service must be published to the common set of event streams, such that the production and ownership of data becomes fully decoupled.

Applications can now access data that would otherwise have been laborious to obtain via point-to-point connections. New services can simply acquire any needed data from the canonical event streams, create their own models and state, and perform any necessary business functions without depending on direct point-to-point connections or APIs with any other service.

This unlocks the potential for an organization to more effectively use its vast amounts of data in any product, and even mix data from multiple products in unique and powerful ways.

Bellemare, Adam. Building Event-Driven Microservices (p. 29). O'Reilly Media. Kindle Edition.

Bellemare, Adam. Building Event-Driven Microservices (pp. 28-29). O'Reilly Media. Kindle Edition.

Bellemare, Adam. Building Event-Driven Microservices (p. 28). O'Reilly Media. Kindle Edition.

How EDA microservices

An event-streaming data communication structure decouples the production and ownership of data from the access to it. Services no longer couple directly through a request-response API, but instead through event data defined within event streams

All shareable data is published to a set of event streams, forming a continuous, canonical narrative detailing everything that has happened in the organization.

Bellemare, Adam. Building Event-Driven Microservices (p. 27). O'Reilly Media. Kindle Edition.

Events are the data; they are not merely signals indicating data is ready elsewhere or just a means of direct data transfer from one implementation to another. Rather, they act both as data storage and as a means of asynchronous communication between services.

All business and application logic must be encapsulated within the producer and consumer of the events. Data access and modeling requirements are completely shifted to the consumer, with consumers each obtaining their own copy of events from the source event streams.

Bellemare, Adam. Building Event-Driven Microservices (p. 28). O'Reilly Media. Kindle Edition.

Bellemare, Adam. Building Event-Driven Microservices (p. 27). O'Reilly Media. Kindle Edition.

Tax

The microservice tax is the sum of costs, including financial, manpower, and opportunity, associated with implementing the tools and components of a microservice architecture. This includes the cost of managing, deploying, and operating the event broker, CMS, deployment pipelines, monitoring solutions, and logging services. These expenses are unavoidable and are paid either centrally by the organization or independently by each team implementing microservices. The former results in a scalable, simplified, and unified framework for developing microservices, while the latter results in excessive overhead, duplicate solutions, fragmented tooling, and unsustainable growth.

Paying the microservice tax is not a trivial matter, and it is one of the largest impediments to getting started with EDM. Small organizations would likely do best to stick with an architecture that better suits their business needs, such as a modular monolith. Larger organizations need to account for the total costs of both the implementation and maintenance of a microservice platform and determine if the long-term roadmap of their business can accommodate the predicted work efforts. Fortunately, both open source and hosted services have become far more available and easy to use in recent years. The microservice tax is being steadily reduced with new integrations between CMSes, event brokers, and other commonly needed tools. Be sure that your organization is prepared to devote the necessary resources to pay these up-front costs.

Bellemare, Adam. Building Event-Driven Microservices (p. 57). O'Reilly Media. Kindle Edition.

Unstarred

Dunk (exclude from study)

Building Event-Driven Microservices

Review Questions

Todos

Sensemaker