It has built-in integrations so you don't have to standup a service or API Gateway to receive webhooks from their list of partners. Their initial list of partners is [1]:

- Datadog

- OneLogin

- Pagerduty

- Saviynt

- Segment

- SignalFx

- SugarCRM

- Symantec

- Whispir

- Zendesk

and of course that'll grow over time - anyone that produces events can become a partner.

[1]: https://aws.amazon.com/eventbridge/partners/

So kind of an IFTT or Zapier piped directly into your AWS backend?

Yeah, I also thought of IFTT when I saw this: https://ifttt.com/services

Reminds me a bit of Apache Camel then - let's you easily route end points from all kinds of different protocols as if they are messages.

Maybe I never looked at it hard enough, but I couls never figure out what Camel was for.

It's one of those things that you don't know you need ... until you get half way to re-inventing it yourself and then you realise you needed it. Wrt this, probably the more relevant part is all the end point integrations:

https://camel.apache.org/components.html

So it makes it super easy to, say, connect an inbound email to an ftp server so that all the messages get saved as files.

Camel was libraries that codified the the Enterprise Integration Patterns (https://www.enterpriseintegrationpatterns.com/ - channels, messages, service activators, etc...) that allowed you to code against the abstractions rather than the underlying implementations (JMS w/ topics & queues, AMQP w/ exchanges, etc..)

Spring offered a competing set of libs with Spring Integration.

Those we mostly just libraries, though, so you have something running under them for distribution (like a message broker or service bus or, these days, a cloud managed service).

> so you have something running under them for distribution (like a message broker or service bus or, these days, a cloud managed service).

Actually Apache Camel doesn't really care if you have a message broker or not. You can set it up without one and still use half its functionality. (eg: connect a file arriving in a dropbox account to an outbound SMTP etc).

Eek! Missing Salesforce!!!

This looks similar to Azure Event Grid, which I'm more familiar with. If that's true, the value prop is that one event handler can be webhook based while another handler can be queue based, and you can add and remove these different kinds of handlers without making any producer-side changes. It's quite nice

So SNS?

And SQS rolled into one with lots of click and play integrations

Not a ton of outside integrations, but this library creates and maintains an esb using sqs and sns with just a few annotations in java. Uses json as the message and maps to pojo in the application.

https://bitbucket.org/pythagorasio/java-message-bus/src/mast...

Its also published on maven central. Io.pythagoras.messagebus

Disclosure: I’m the primary author.

How is this "SNS and SQS rolled into one"? What's the SQS-like part in this? This seems very similar to SNS, with some additional flexibility around event filtering, and the added bonus of various SaaS integrations that can replace traditional webhooks.

EventBridge is a PubSub system with different tradeoffs and operational constraints and behaviors.

The cool new features are: (1) It allows serverless dynamic routing based on message content which auto-scales to match usage. (2) It supports SaaS partner events. (3) It supports publishing events based on a scheduled configuration, which can be used to trigger cron jobs or other system processes.

So it is just a messaging system, but one that might be more appropriate to certain use cases over using SQS or SNS or Kinesis, etc.

The article thinks that the ability to have SaaS partner publish events will be a huge deal and is a killer feature of EventBridge.

Under the hood it's probably exactly that.