Explaining Eventbridge Amidst the Hype
Explaining Eventbridge Amidst the Hype
We move beyond the new tool hype and get to the bottom of what makes Eventbridge so special.
Join the DZone community and get the full member experience.Join For Free
In November 2014, the tech industry was the audience to an announcement that set off an illustrious trend in the domain of cloud computing known as serverless. That announcement was the release of AWS Lambda, presented by Werner Vogels at AWS’s re:invent summit held in Las Vegas. Since then, the industry has seen strides in the way we compute in the cloud, reshaping business and technological developments.
Five years later, almost in the poetic air of history repeating itself, AWS has done it again. This year July, in NYC, AWS announced its Eventbridge service, and the uproar and excitement that followed were the same as that seen five years ago. Almost every blog or report on the service that came out afterward depicted Eventbridge as the most important announcement after the release of AWS Lambda.
So why all this commotion? What is Eventbridge, and how is it to usher in a new era of serverless? Didn’t AWS already have similar services? How does the release of this service affect the industry? Well, that is what I plan to answer in this piece, hoping to shine light into the actual benefits of Eventbridge, how it will redefine the way we think of serverless architectures and differentiate it from the already existing similar services out there in the AWS stack.
The Difference Between the Bus and the Bridge
Pushing aside all the fanfare and ballyhoo surrounding Eventbridge, let’s jump into what it actually is. In short, Eventbridge can be loosely described as an enhanced version of AWS’s CloudWatch Events, but with a slight twist.
CloudWatch Events provides almost real-time streaming of events reflecting changes in a user’s environment. Essentially it is an event bus. Going into the core definition of what an event bus is, we can describe it as a channel that allows services to communicate messages, or in this case events, without being aware of the other services creating events or listening to events in the channel.
Using event buses means that we have loosely coupled services as they do not need to be aware of one another while communicating. Services can be replaced at the ends of event buses, as long as they can understand the events that are being passed through the event bus.
All of this is great, but how is EventBridge different from the event bus that is under CloudWatch? The greatest difference is the fact that now AWS services can communicate with third-party SaaS services via the event bus. During the summit in NYC, 10 launch partners were announced, including tools such as Zendesk and Datadog. It can only be expected that this list will grow further.
The introduction of integrated partners is part of AWS’s initiative to have their third-party SaaS complimentary tools sit alongside their native services. I am sure that we will see more of this in the near future, where AWS partner resources will be hosted alongside AWS’s own resources in the upcoming services.
Moreover, EventBridge allows the setting of rules upon incoming events to redirect them to different targets. What we have now is intelligent routing. These different targets could be various AWS services, integrated third-party SaaS tools, or different services in different AWS accounts. Yes, you read that right, different AWS accounts, a property inherited from the CloudWatch Events.
Also, did I mention it's serverless!? Yes, by building on top of a serverless platform, AWS gifted to the world a fully scalable and managed event bus. That means lower operational costs, infinite scalability, and the AWS guaranteed reliability.
So far, EventBridge sounds great, but what does that mean when building serverless applications? We already know that serverless applications mean event-driven architectures. Considering that EventBridge is an event-driven bus, that is fully scalable, fully managed, and allows communication with third-party SaaS tools, we can already think of the benefits.
Building serverless applications, usually mean thinking of microservices, or individual services all communicating with one another, with Lambda functions in the middle somewhere. An event from a cloud service is to generate an event that is going to trigger a Lambda function which in-turn will result in another event that will perform some action in another service. That is the over-generalized version of it all.
Considering that EventBridge allows event-driven communication between integrated partners and AWS services and accounts, one of the major benefits of hooking everything up with EventBridge is that we no longer need to worry about setting up complex web-hooks. Not setting up complex webhooks means reducing burdens such as security, network reliability, and coupling of interacting modules.
The smart routing, facilitated by the rule-based event forwarding capabilities of EventBridge also brings an added advantage. The branching logic that springs out of the rule-based routing means we no longer need to rely on a singular ingress point that comes with webhooks. No more issues of reliability and uptime as these are delegated away to AWS.
There are other similar services such as SNS, Kinesis, and as mentioned, CloudWatch Events. Nevertheless, these services do not have all the features that AWS EventBridge offers. For example, SNS demonstrates high reliability and scalability but lacks the event-based filtering on context and content. Additionally, it does not ensure order. Kinesis streams, on the other hand, do guarantee order, but cannot scale automatically. Finally, as mentioned CloudWatch Events lack the ability to allow communication with the third party SaaS tools that used in your serverless application.
Is the Hype Justified?
So, now the question is, does EventBridge deserve all the commotion around it? Yes! Of course, there are some limitations to EvenBridge, such as the number of EventBridge connections per account being limited to 100 and only 750 invocations per second before we see throttling kick in. However, just like the limitations of AWS Lambda, we too can expect these limitations to improve over time.
In conclusion, what we now have is a fully managed, fully scalable, and third party supporting event bus. This does promote event-driven serverless applications, and definitely does mean a new era of cloud computing and serverless in particular. It is only a matter time before the use-cases start coming in, and we see a new wave of serverless applications.
Published at DZone with permission of Sarjeel Yusuf . See the original article here.
Opinions expressed by DZone contributors are their own.