Event Driven Architecture — Eventarc on GCP

Event-driven architecture is defined as a software design pattern in which decoupled applications can asynchronously publish and subscribe to events via an event broker (modern messaging-oriented-middleware).

Event-driven architecture is a way of building enterprise IT systems that lets information flow between applications, microservices, and connected devices in a real-time manner as events occur throughout the business.

By introducing a middleman known as an event broker, event-driven architecture enables what’s called loose coupling of applications, meaning applications and devices don’t need to know where they are sending information, or where information they’re consuming comes from.

Why use event-driven architecture?

The value of knowing about a given event, and being able to react to it, degrades over time. The more quickly you can get information about events where they need to be, the more effectively your business can react to opportunities to delight a customer, shift production, and re-allocate resources.

That’s why event-driven architecture, which pushes information as events happen, is a better architectural approach than waiting for systems to periodically poll for updates, as is the case with the API-led approach most companies take today.

With event-driven architecture:

• Everything happens as soon as possible and nothing is waiting on anything else.
• You don’t have to consider what’s happening downstream, so you can add service instances to scale.
• Topic routing and filtering can divide up services quickly and easily — as in command query responsibility segregation.
• To add another service, you can just have it subscribe to an event and have it generate new events of its own — there’s no impact on existing services.

Event-Driven Architecture Use Cases

The benefits of event-driven architecture covered above are especially relevant in use cases where a single change can have huge consequences, rippling all the way down the chain. One of the most common questions people have is “When should you use event-driven architecture?” The answer lies in what you are trying to accomplish with your data.

The top 4 use cases for event-driven architecture:

• Integrating applications
• Sharing and democratising data across applications
• Connecting IoT devices for data ingestion/analytics
• Event-enabling microservices

The 6 Principles of Event-Driven Architecture

1. Use a network of event brokers to make sure the right “things” get the right events.
2. Use topics to make sure you only send once and only receive what you need.
3. Use an event portal to design, document, and govern event-driven architecture across internal and external teams.
4. Use event broker persistence to allow consumers to process events when they’re ready (deferred execution).
5. Remember this means not everything is up to date (eventual consistency).
6. Use topics again to separate out different parts of a service (command query responsibility segregation).

Event Mesh

An event mesh is created and enabled through a network of interconnected event brokers. It’s a configurable and dynamic infrastructure layer for distributing events among decoupled applications, cloud services, and devices by dynamically routing events to any application no matter where these applications are deployed in the world, in any cloud, on-premises or IoT environment.

Event Driven Architectures on GCP — Eventarc

Eventarc lets you build event-driven architectures without having to implement, customize, or maintain the underlying infrastructure. Eventarc offers a standardized solution to manage the flow of state changes, called events, between decoupled microservices. When triggered, Eventarc routes these events to various destinations, while managing delivery, security, authorization, observability, and error-handling for you.

Events

An event is a data record expressing an occurrence and its context. An event is a discrete unit of communication, independent of other events. For example, an event might be a change to data in a database, a file added to a storage system, or a scheduled job.

Event providers

Events are routed from an event provider (the source) to interested event consumers. The routing is performed based on information contained in the event, but an event does not identify a specific routing destination. Currently, Eventarc supports events from the following providers:

1. More than 130 Google Cloud providers. These providers send events:

Directly from the source (for example, an update to an object in a Cloud Storage bucket or a message published to a Pub/Sub topic)

Through Cloud Audit Logs entries

2. Third-party providers. These providers send events directly from the source (for example, third-party SaaS providers such as Datadog or the Check Point CloudGuard platform).

Event destinations

Events are routed to a specific destination (the target) known as the event receiver (or consumer) through Pub/Sub push subscriptions.

Cloud Functions (2nd gen)

All event-driven functions in Cloud Functions (2nd gen) use Eventarc triggers to deliver events. An Eventarc trigger enables a function to be triggered by any event type supported by Eventarc. You can configure Eventarc triggers when you deploy a Cloud Function using the Cloud Functions interface.

Cloud Run

You can build an event receiver service that can be deployed to Cloud Run.

GKE

Eventarc supports creating triggers that target Google Kubernetes Engine (GKE) services. This includes private and public Cloud Run for Anthos services running in a GKE cluster.

• For Eventarc to target and manage services in any given cluster, you must grant the Eventarc service account any necessary permissions.
• You need to enable Workload Identity on the GKE cluster that the destination service is running on. Workload Identity is required to properly set up the event forwarder and is the recommended way to access Google Cloud services from applications running within GKE due to its improved security properties and manageability.

Workflows

An execution of your workflow is triggered either by messages published to a Pub/Sub topic, when an audit log is created that matches the trigger’s filter criteria, or in response to various events inside a Cloud Storage bucket — object creation, deletion, archiving, and metadata updates.

Workflows requires an IAM service account email that your Eventarc trigger will use to invoke the workflow executions. We recommend using a service account with the least privileges necessary to access the required resources.

Eventarc triggers

Events occur whether or not a target destination reacts to them. You create a response to an event with a trigger. A trigger is a declaration that you are interested in a certain event or set of events. When you create a trigger, you specify filters for the trigger that let you capture and act on those specific events, including their routing from an event source to a target destination.

Conclusion

Eventarc lets you asynchronously deliver events from Google services, SaaS, and your own apps using loosely coupled services that react to state changes. Eventarc requires no infrastructure management — you can optimize productivity and costs while building a modern, event-driven solution.