After reading it I can't understand how EventBridge is different to just using SQS or any old messaging service? It just sounds like a message system layered on a messaging system. Can anyone elaborate why this is significant?
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.
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:
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).
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
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.
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.
