ESB is dead, long live ESB.<p>I think i’m getting old... was telling coworkers that their fancy micro services existed 15 years ago in the form of EJB and service bus was a thing. And look, here it goes again
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?
Pretty sure AWS is late to the party and just now achieving feature parity with Azure. Azure Event Grid came out at the beginning of 2018.<p>However, I suppose from an AWS cloud standpoint this great news :)<p>I would imagine this replaces a lot of SNS and SQS combo architectures in AWS?
Everything old is new again!<p><a href="https://en.wikipedia.org/wiki/Yahoo!_Pipes" rel="nofollow">https://en.wikipedia.org/wiki/Yahoo!_Pipes</a><p>But in all seriousness we've got half a dozen use cases for this just off the top of my head.
Just saw Amazon CTO Dr Werner Vogels present this at their Summit here in NYC. He was very excited about it!<p>Their other big reveal was for new AWS CDK services allowing programmable config at scale in a few lines of code<p><a href="https://aws.amazon.com/blogs/aws/aws-cloud-development-kit-cdk-typescript-and-python-are-now-generally-available/" rel="nofollow">https://aws.amazon.com/blogs/aws/aws-cloud-development-kit-c...</a>
Amazon is a logistics company, not a cloud company. Their product strategy is spray and pray. "You want a DB? We have 10!" GC has fewer, more stable, high quality offerings. Amazon is like their store "Want shoes? We got millions." Google is like their site "You want search, we do search."
We have a very small Golang service that exposes some endpoints and basically just forwards incoming events to SNS which then publishes to subscribers like SQS/Lambda/whatever. This small service basically never fails as it's only dependency is SNS. I don't really see how this EventBridge is much more than that?
For those confused, I suggest you go read the official doc: <a href="https://aws.amazon.com/eventbridge/faqs/" rel="nofollow">https://aws.amazon.com/eventbridge/faqs/</a> . Let me quote the important bits:<p>> EventBridge was formerly called Amazon CloudWatch Events. It includes new features that enable you to receive events from SaaS partners and your own applications. Existing CloudWatch Events users can access their existing default bus, rules, and events in the new EventBridge console and in the CloudWatch Events console. EventBridge uses the same CloudWatch Events API, so all of your existing CloudWatch Events API usage remains the same.<p>So EventBridge is CloudWatch Events. The difference is that now you can publish your own events and specify your own routing rules for them. As well as supporting 3rd party events from certain SaaS partners.<p>It is limited to 400 events per second, 5 targets per rule, and 100 rule per account. Consuming events is throttled at 750 per second. Events take about half a second to reach targets. Some of these limits can be increased by asking for higher limits. AWS published events, so existing CloudWatch Events don't count towards these and are unlimited.<p>What about SNS?<p>> Amazon SNS is recommended when you want to build an application that reacts to high throughput or low latency messages published by other applications or microservices (as Amazon SNS provides nearly unlimited throughput), or for applications that need very high fan-out (thousands or millions of endpoints)<p>> At launch, Amazon EventBridge is has limited throughput (see Service Limits) which can be increased upon request<p>> Amazon EventBridge is the only event-based service that integrates directly with third-party SaaS partners<p>> Amazon EventBridge uses a defined JSON-based structure for events, and allows you to create rules that are applied across the entire event body to select events to forward to a target<p>Also, the targets are not exactly same yet. For example, only SNS can publish to Mobile SMS, Email, or HTTP/S endpoints for now.<p>And SNS allows any type of payloads, while EventBridge forces you into JSON.<p>Finally, the reason this specifies serverless is because of the dynamic content based routing using configurable rules. This means you don't need to manage your own routing. So say you want to pair it with Lambda, you don't waste Lambdas starting then realizing the event isn't relevant for them, you can just setup rules for that. So it provides a serverless routing mechanism that auto-scales and is decoupled from producer and consumer. That's pretty cool!<p>Hope that helps!
I would really like to see how this compares to Firebase. It sounds really similar in that you subscribe to events and then AWS or Google handles the difficult tasks of routing to the right places.
“It re-establishes how the greater ecosystem of software integrates with your business logic, in addition to defining an excellent standard for your own services to leverage.”<p>But what is it?