Recently Amazon announced the general availability of the Schema Registry capability in the Amazon EventBridge service. With Amazon EventBridge Schema Registry, developers can store the event structure - or schema - in a shared central location and map those schemas to code for Java, Python, and Typescript, meaning that they can use events as objects in their code.
Amazon EventBridge is a serverless event bus that allows AWS services, Software-as-a-Service (SaaS), and custom applications to communicate with each other using events. The service has been generally available since July last year and received a new capability with the schema registry announced in preview at re:Invent 2019. This functionality is now generally available.
EventBridge Schema Registry allows developers to discover, create, and manage OpenAPI schemas for events on EventBridge. According to the documentation, they can find schemas for existing AWS services, create and upload custom schemas, or generate a schema based on events located on an event bus. Furthermore, EventBridge enables developers to generate and download code bindings for all event schemas in order to help quickly build applications that use those events.
With the GA Release, Amazon also introduced the support for schema registry resource policies, allowing enterprises to share a schema repository across different AWS accounts and organizations. The policies provide developers on different teams with the benefit of sharing, searching for and using any schema that another team has added to the shared registry. As Danilo Poccia, chief evangelist (EMEA) at Amazon Web Services explains in his blog post about EventBridge Schema Registry:
Each team is using their AWS account to develop their application. Using EventBridge, the teams can implement the following architecture:
- The frontend CreateAccount applications are using the Amazon API Gateway to process the request using an AWS Lambda function written in Python. When a new account is created, the Lambda function publishes the ACCOUNT_CREATED event on a custom event bus.
- The backend FraudCheck Lambda function is built in Java and is expecting to receive the ACCOUNT_CREATED event to call Amazon Fraud Detector to estimate the risk of that being a fake account. If the risk is above a certain threshold, the Lambda function takes preemptive actions. For example, it can flag the account as fake on a database, or post a FAKE_ACCOUNT event on the event bus.
Source: https://aws.amazon.com/blogs/aws/new-amazon-eventbridge-schema-registry-is-now-generally-available/
Having a schema registry in place, Amazon’s EventBridge further evolves as a service and is now a competitive service in comparison with other cloud vendors that provide similar services. Microsoft offers EventGrid, which has been GA since the beginning of 2018, and received several updates including advanced filtering, retry policies, and support for CloudEvents. However, the service lacks a schema registry capability. Moreover, the same applies to Triggermesh’s EveryBridge. This event bus can consume events from various sources, which developers can use to start serverless functions that are running on any of the major cloud providers as well as on-premises.
Markus Wissing, practice leader enterprise architecture at TecAlliance, said in a tweet:
The schema registry acts somewhat like digital yellow pages for events. We used it to consume @zendesk events. Simplified our solution a lot.
Currently, the EventBridge schema registry is available in the same AWS regions as Amazon EventBridge. Furthermore, the pricing details of Amazon EventBridge is available on the pricing page.
