
Amazon EventBridge: The biggest thing since AWS Lambda - gilad
https://www.trek10.com/blog/amazon-eventbridge/
======
LaserToy
ESB is dead, long live ESB.

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

~~~
hestefisk
Except you had to use CORBA or JMS to invoke them, which was pretty
frustrating and expensive computationally.

~~~
devonkim
CORBA and the object mapping model (similar to the issues of ORMs) is what led
to the dreaded ClassCastException problems that required every service to re-
deploy at once which was completely broken and indicative of the architects
being engineers that hardly ever touched day to day production. The transition
off of syncing object representation in a monolith and God Service Schema /
Registry was necessary but by that point we had moved on to SOAP and screwed
that part up once again by needing to re-deploy JARs yet again constantly and
out of sync and also being unable to separately deploy and route components
off which led to either more ditch digging via OSGI or by going to REST
APIs... or if you didn’t get here you used earlier incarnations of object and
message serializations with protocol buffers. Only with these painful lessons
have we as an industry learned how to actually decouple our services’ business
boundaries well enough to call them decoupled, scalable services.

~~~
LaserToy
Did we learn the lesson? Protobufs are getting traction, and some rising star
companies started using them for data related purposes. The problem they are
facing - change in the protobuf is not automatically reflected in you data
schema (not like with avro), you have to recompile and redeploy pieces of your
stack + orchestrate deployment so data is not lost in processing. It can be
solved easily with avro, but “we want to use protos, Bla Bla Bla”

~~~
paulddraper
Protobufs are relatively good with backwards compatibility, no?

~~~
devonkim
Thrift, ProtoBufs, and Avro solve the messaging compatibility layer problem at
least (optional fields in a schema are all you need 99%+ of the time) and so
far nothing out there has managed to solve any data schema incompatibility
problem automatically because that’s pretty much intractable, but providing
tools that make finding problems earlier certainly helps with the reality of
SOA in its various incarnations.

------
zmmmmm
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?

~~~
arkadiyt
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/](https://aws.amazon.com/eventbridge/partners/)

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

~~~
zianwar
Yeah, I also thought of IFTT when I saw this:
[https://ifttt.com/services](https://ifttt.com/services)

------
ipodopt
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.

However, I suppose from an AWS cloud standpoint this great news :)

I would imagine this replaces a lot of SNS and SQS combo architectures in AWS?

~~~
kayoone
it looks like it only replaces SNS no? As some of the examples are Lambdas and
SQS queues that you can publish to. We have a small Go service that basically
maps endpoints to SNS topics which then publishes events to SQS or Lambda or
some other internal endpoint. Don't see how this is much different other than
provided integrations with popular services out of the box.

------
hartror
Everything old is new again!

[https://en.wikipedia.org/wiki/Yahoo!_Pipes](https://en.wikipedia.org/wiki/Yahoo!_Pipes)

But in all seriousness we've got half a dozen use cases for this just off the
top of my head.

~~~
dpacmittal
I loved yahoo pipes. Wonder why it never took off. You could do SQL style
query on dozens of different services.

------
grogenaut
Is this just Yahoo Pipes for Lambda? or IFTT for Lambda?

~~~
oliyoung
essentially, yes

------
ctulek
How do you test this in dev environment?

~~~
ec109685
By subscribing a dev AWS account to the EventBridge.

~~~
SomeOldThrow
Live subscriptions sound like like staging, not dev

------
ArtWomb
Just saw Amazon CTO Dr Werner Vogels present this at their Summit here in NYC.
He was very excited about it!

Their other big reveal was for new AWS CDK services allowing programmable
config at scale in a few lines of code

[https://aws.amazon.com/blogs/aws/aws-cloud-development-
kit-c...](https://aws.amazon.com/blogs/aws/aws-cloud-development-kit-cdk-
typescript-and-python-are-now-generally-available/)

------
magwa101
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."

~~~
outside1234
As people say in sports when someone is trash talking when they are losing:
“Scoreboard”

The AWS approach (and Azure) is clearly working. And the reality is that
people want multiple approaches, especially enterprises, which are typically
migrating applications to the cloud and can’t just rewrite everything for
Google’s random proprietary platform.

Also, I’ll note that GCP is pretty aggressive about EOLing platforms. Good
luck with that in the enterprise market.

~~~
brianwawok
You seem to have confused googles consumer platform policy and Googles
enterprise policy. They are very different.

That’s like saying AWS is low quality because you bought a fake widget off
Amazon.com?

~~~
outside1234
Google Cloud Messaging: [https://developers.google.com/cloud-
messaging](https://developers.google.com/cloud-messaging)

App Engine:
[https://cloud.google.com/appengine/docs/deprecations/](https://cloud.google.com/appengine/docs/deprecations/)

...

~~~
brianwawok
Several of those are showing multiple year deprecation policies. I think the
min from notice to shutdown is like 2 years?

If you really want to build something and never touch it again, you need to go
in prem. Good luck with being 5 years behind in security updates.

------
plumeria
It would be nice to see WhatsApp becoming a partner.

~~~
unixhero
And maybe Pushbullet

------
kayoone
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?

~~~
bshek
I have a very similar setup what you have. I think what event bridge offers,
is the ability to integrate with anything which can reproduces event. They are
trying to expand their base beyond AWS ecosystem. Datadog, Zendesk, OneLogin
are great services which could be helpful, to begin with. Still time will tell
how popular it gets.

------
zild3d
Big win for serverless, especially in price:

" _There is no charge for events published by AWS services_ "

------
vlucas
Am I correct in thinking of Amazon EventBridge as a competitor to services
like Zapier and IFTTT?

~~~
foota
I don't think so. More like ifttt for Enterprise.

------
charles_f
Is it the same as Azure EventGrid?

------
didibus
For those confused, I suggest you go read the official doc:
[https://aws.amazon.com/eventbridge/faqs/](https://aws.amazon.com/eventbridge/faqs/)
. Let me quote the important bits:

> 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.

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.

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.

What about SNS?

> 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)

> At launch, Amazon EventBridge is has limited throughput (see Service Limits)
> which can be increased upon request

> Amazon EventBridge is the only event-based service that integrates directly
> with third-party SaaS partners

> 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

Also, the targets are not exactly same yet. For example, only SNS can publish
to Mobile SMS, Email, or HTTP/S endpoints for now.

And SNS allows any type of payloads, while EventBridge forces you into JSON.

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!

Hope that helps!

------
xrd
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.

------
hestefisk
“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.”

But what is it?

~~~
didibus
It's PubSub with dynamic message routing, but where each AWS account will also
now be able to make themselves a consumer of events published by 3rd party
SaaS. Say you want to start a Lambda whenever a Zendesk ticket is opened, you
can now do that without having to setup any hosts or write any code.

------
CharlesW
Is “AppleEvents for Serverless” a reasonable analogy for this? It’s an inter-
process event bus?

