This is, of course, a bold statement if nothing else. However, it’s based on a few years of building production level serverless systems here at Trek10. More interestingly, this isn’t just about the technology introduced, it is the partner integrations and the statement made by AWS bringing them into the native serverless ecosystem.
AWS EventBridge is at its core a traditional Event Bus. A service that services or applications can publish events to and subscribe to streams of events from. This pattern itself is nothing particularly new, CloudWatch Events was introduced in 2016 with features added to the service at steady rate since.
Amazon EventBridge can be considered a rule-driven event router as well. It allows you to define event patterns based on the actual content of the events to decide what targets (subscribers) receive each event passing through the bus. Event targets can be everything from Lambda functions to Kinesis streams, SQS queues, or even other Event Buses in different AWS accounts. This opens up compelling patterns for multi-service, even multi-departmental decoupled communications. My co-worker Forrest wrote about these patterns in depth on the AWS Blog.
This pub/sub event pattern is something that can be driven with all sorts of other services in AWS, each carrying their own features or tradeoffs. Kinesis has ordering guarantees, but it isn’t entirely usage-based pricing and doesn’t automatically scale to demand. SNS scales practically infinitely, but filtering is limited to attributes, not event content and order isn’t guaranteed.
The establishment of partner integrations means that AWS is investing in the idea that EventBridge and event-driven integrations are the future of SaaS and service integrations within your AWS infrastructure. With a few bits of configuration, various SaaS products like Zendesk and Datadog can start publishing all sorts of events. You can then leverage these now native events to power your own business workflows.
For instance, at Trek10, we have a significant amount of logic built up around webhooks from Zendesk. We use AWS Lambda to automate reactions to various ticket updates and statuses, sometimes there may be multiple processes that care about a particular update. We may even have branching logic based on the event's content and context. With AWS EventBridge, we can move toward more intelligent routing of these events directly to the business logic that cares about it.
This also elegantly solves some of the traditional challenges with webhooks. You don’t have a singular endpoint for ingress to babysit. Instead, you leverage a managed service, so uptime is strictly on Amazon, who I trust a heck of a lot more than running my own ingress point. Adding new logic for events as they ingress is simply the addition of a rule. It requires no code updates to any other running system.
For example, deciding to store all of the events for machine learning is as easy as a new rule archiving event streams to CloudWatch logs for further insights later on. You can easily extend your use-cases in a decoupled fashion without impacting any other business logic reacting to those events.
Your services are just internal producers
Amazon EventBridge offers the best of all worlds in many of the frequent cases of inter-service communication. Not only is it great for the partner provided integrations, but you can use it between your own services.
If you are following recommendations of segregated AWS accounts for various services or departments, Amazon EventBridge natively handles shuttling events around to entirely different AWS accounts. This can happen within custom Event Buses, where each of your services provides their events. Your other services can manage their own targets and business logic to selectively react to those events.
CloudFormation is not yet fully supported for EventBridge. "AWS CloudFormation is supported for Rules and EventBusPolicy resources. Event bus and event source resources are not yet supported." Other details in the Service FAQ. This notice will be removed when it is available.
Establishing Amazon EventBridge as your standardized services integration point makes it easier to set best practices and expectations for anyone consuming or building a new service within your organization. A word of warning though, events on a bus are hard for consumers to use without having some kind of event schema registry. This makes it possible to search for an event type and to version the schemas so consumers and publishers understand what they are working with.
I personally can’t wait to see the event and partner ecosystem grow up around AWS EventBridge, and the evolution of features in EventBridge to make it one of the go-to solutions in serverless architectures.
