EventBridge is a rebranding of CloudWatch Events with some new additional features added (creating additional event buses and approved third-party integration).
I think what this article highlights the best is the fact that you can publish events directly to the event bus is the AWS SDK. It's not obvious since most people using CloudWatch Events/EventBridge use the AWS Console limits the utility of this service offering. So here in this article you can see the event being published:
What this article is lacking is showing you the tail-end of integration. If you open up EventBridge these are all your possible targets.
So you may be asking, why use the AWS SDK to call the EventBridge API only for it to call SNS or Lambda when you can directly invoke these using the AWS SDK.
The reason is that it's forcing you to conventionalize you're inputs and outputs as a data object (events) for better usability. So maybe you only want to use Lambda for the target today but if you force your output to event then tomorrow you might want to use something else.
I think one very important thing the article highlighted was the added latency. In my research, I couldn't figure out yet what additional latency.
The article suggestions 500ms which in my opinion is very high, so maybe that's "worst case".
Another consideration does EventBridge force you into vendor lock-in or does it make it hard to migrate layer or go cross-cloud. I'm not building events bus's on daily basis but I would think migration might not be bad. I could see a way of moving containerized microservices onto NATS.
The only thing I'm not a fan of the codebase is it's written using serverless.yml instead of a CloudFormation template. It's nitpicking of me, but since this is such an AWS specific implementation and there so little in the template as is, it's nice when these projects choose more vanilla options.
So here I did a bit of digging.
Looks like the is a limit of 50 per API call for SDK. You can increase it via Service Limits but being such a small number, looks the EventBus is low traffic for custom integration.
You can see using the Console with Event Rules and Schedule there are no such limits
Also, there is a throttling limit for invocations.
All very interesting. I'll have to give a thought on how the utility of this should work.
Lots of good considerations here! If you're looking for a CloudFormation version of this project, Adrienne Dreyfus at Stripe has recently ported this to use SAM (the Serverless Application Model extension of CloudFormation), so that we can have the best of both worlds:
EventBridge is a rebranding of CloudWatch Events with some new additional features added (creating additional event buses and approved third-party integration).
I think what this article highlights the best is the fact that you can publish events directly to the event bus is the AWS SDK. It's not obvious since most people using CloudWatch Events/EventBridge use the AWS Console limits the utility of this service offering. So here in this article you can see the event being published:
What this article is lacking is showing you the tail-end of integration. If you open up EventBridge these are all your possible targets.
So you may be asking, why use the AWS SDK to call the EventBridge API only for it to call SNS or Lambda when you can directly invoke these using the AWS SDK.
The reason is that it's forcing you to conventionalize you're inputs and outputs as a data object (events) for better usability. So maybe you only want to use Lambda for the target today but if you force your output to event then tomorrow you might want to use something else.
I think one very important thing the article highlighted was the added latency. In my research, I couldn't figure out yet what additional latency.
The article suggestions 500ms which in my opinion is very high, so maybe that's "worst case".
Another consideration does EventBridge force you into vendor lock-in or does it make it hard to migrate layer or go cross-cloud. I'm not building events bus's on daily basis but I would think migration might not be bad. I could see a way of moving containerized microservices onto NATS.
The only thing I'm not a fan of the codebase is it's written using serverless.yml instead of a CloudFormation template. It's nitpicking of me, but since this is such an AWS specific implementation and there so little in the template as is, it's nice when these projects choose more vanilla options.
So here I did a bit of digging.
Looks like the is a limit of 50 per API call for SDK. You can increase it via Service Limits but being such a small number, looks the EventBus is low traffic for custom integration.
You can see using the Console with Event Rules and Schedule there are no such limits
Also, there is a throttling limit for invocations.
All very interesting. I'll have to give a thought on how the utility of this should work.
Hi Andrew,
Lots of good considerations here! If you're looking for a CloudFormation version of this project, Adrienne Dreyfus at Stripe has recently ported this to use SAM (the Serverless Application Model extension of CloudFormation), so that we can have the best of both worlds:
github.com/adreyfus-stripe/stripe-...
Enjoy! :)