API Management, Meet Event Management

A big part of REST’s ascension into mainstream popularity was a robust ecosystem of enablement tools created by the open-source and vendor community. In fact there’s an entire category of tools called API Management made up of components such as portals, catalogs, gateways and policy/analytics tools. It’s a big piece of the puzzle, and one for which there’s no equivalent in the world of events.

Key Functions of API Management

Enough people have asked me about “API management for events” that I thought I’d break down the value prop of API management platforms and see what it would look like to apply those same capabilities to the eventing world. To that end, let’s dive into what API management does for RESTful APIs.

• API gateways handle the runtime proxying of service requests and responses. They enforce security policies and perform mediation and transformation. They’re typically stateless, a reflection of the fact that REST is an inherently stateless protocol. While useful in the runtime context, API gateways aren’t user-friendly without an API portal.
• API portals are effectively an integrated development environment (IDE) for APIs. They let developers create the API interface definitions using OpenAPI and push them to the gateway. They also generate documentation that supports prospective users’ ability to discover and write applications that utilize the service. Many portals provide a “try me” function that lets users interact with the API before deciding whether or not to write code that consumes it. Finally, API portals manage the lifecycle of APIs, and enable the existence of multiple concurrent versions.
• API policy management: Given an API interface definition, fine-grained security policies can be used to make sure clients have access to invoke APIs and resources they are entitled to, and only those APIs and resources.
• API analytics tools help organizations understand which APIs are most frequently invoked, and who is invoking them. Such information can help organizations focus on the most useful and popular APIs, and potentially monetize them in the case of externally exposed APIs.

When becoming familiar with the world of events, people familiar with these tools very quickly ask what their equivalents are. The answer is complex because the event-driven ecosystem is way less advanced in some regards, so let’s map the API management components to what should exist for this new capability and call it an event management platform.

A Model for Event Management

The world of events introduces a number of things APIs don’t deal with, such as guaranteed delivery which requires both statefulness and persistence, the gateway, portal and policy management/analytics components which still must exist to facilitate development, and discovery and lifecycle management. As such, I’ll explain what each component should do in the context of eventing:

• Event gateway: In the world of events, the role of gateway is played by an event broker – the stateful, runtime infrastructure that supports asynchronous publish/subscribe, queueing and streaming interactions. Just like the API gateway, it enforces security policies and is not inherently developer-friendly in and of itself. But unlike an API Gateway, it does not typically do mediation/transformation since applications and microservices can hang off the event broker and do that work asynchronously (vs. having to do it inline with the request/response like in the API world).
• Event portal: Unfortunately there isn’t anything that meets this need today (not even the Kafka Avro Registry), which is bad news for developers and enterprises aspiring to become event-driven given the obvious need to a) define events, b) define the way applications send and react to events, and c) discover events. Ideally, an event portal would let developers and architects easily define events and application interfaces using AsyncAPI, automatically generate documentation that can be used to discover and understand events, and lifecycle manage events with support for change impact analysis.
• Event policy management: Again, not much tooling really exists in this area, even though the ability to understand which events are going to which clients is key from a security and auditing perspective.
• Event analytics: In addition, stats about events and the applications consuming them is incredibly important when designing a client application in the eventing world. Unlike in the API space, where API invocation is handled by the client, event consumers are invoked by the event broker, so you need to know the scale and rate of incoming events to know how to design your app. Finally, just like APIs, it’s important to know which events are being used how much and by which applications to focus your resources on the right events.

Conclusion

Event management platforms that provide functionality and value similar to API management platforms will help the asynchronous eventing paradigm achieve the same level of prominence as API-led initiatives. APIs aren’t going anywhere, of course, they’re still ideal for many use cases. But as a developer or architect you should be able to use the right pattern (command, query or event) and protocol (HTTP, AMQP, MQTT, REST, WebSocket) for every use case. Event management will also accelerate development cycles and eliminate the need to build and train dedicated development teams that specialize in event-driven interactions.

Solace recognizes the need for and potential value of event management, and is working to accelerate and simplify the entire event lifecycle, from design and development right through operation. It’s innovative, disruptive, and customer-centric, and it’s the right thing to do!