What is most valuable?
EventBridge is used for the whole cloud, and all areas of the cloud work on launching applications, scaling, and other problems internally, so we use EventBridge extensively. If you're using AWS cloud and EventBridge, you can imagine how much massive data is being processed through it. Additionally, when you create your account, there is a default EventBridge responsible for your whole account, which you can see in the other section.
They launched this for customers to integrate things easily. With EventBridge, we don't need a broker. The serverless and even the architecture is more straightforward. You design using an API and define your event structure in the schema. They also have a schema designer where you can allocate schema and match them. Then you put a rule that whenever you receive this kind of event, you do something which can be called to an API or a Lambda function.
You can define a very nice target, and it's straightforward, and it's just a few clicks on the dashboard. Even if you do the infrastructure as code, you can use CloudFormation, CDK, or other tools to integrate the whole ecosystem of EventBridge or Lambda function.
You can use your bridge and Lambda function to derive the whole gamification. You don't need servers, Kubernetes, EC2 instances, or anything. You need EventBridge and maybe an API gateway for some use cases, but you can live with two services of AWS, and EventBridge does not have any charges. It's free.
The biggest factor deciding factor is that when you go for Concept Plus or Craft, you don't need to pay to maintain or run it. It also scales inside, and it has everything inside.
When you design with, let's say, what we did, we had a very nice simple solution. The architecture is very, very simple. There was one API gateway, which was responsible for putting the events into EventBridge; the EventBridge was triggering some Lambda functions.
This Lambda function has all the necessary logic, so they were doing some processing. After processing, we want to store some data in a database, and there's F3 for storing files. That's it, and nothing else is required.
What needs improvement?
Amazon EventBridge doesn't have the feature of event replay. Let's say a customer reports an issue, and you want to reproduce the error. There is no source or feature where you can click on a button or put in a query and then try to reproduce the problem on a dashboard. So there is no such mechanism for that. The only way to debug it is to pass that particular event again and make it live to reproduce. That's not the only feature we need.
The second thing is about documentation, but they have improved it a lot now. They started it, but it still needs more improvement. They use open API specifications to document events, but Amazon EventBridge is an async model solution. Therefore, it should have async API documentation, not open API. Open API framework documentation works on rest methods like GET, POST, PUT, etc.
However, EventBridge does not work with REST methods at all, and it works with a source and target mechanism or a publisher and subscriber model. So there is a channel, publisher, and subscriber it uses.
And in open API, you don't find these things, and you can only find these things in the async API documentation. When you want to tell people about a particular model or schema that an event looks like, you write it in the documentation. Then, you can generate the code of the whole library.
For example, if you want to consume an event, you can prepopulate the classes and functions, and developers can easily work on it. These features are available in async API but not in AWS.
AWS provides the rest API, which requires a lot of customization. So I would say that's missing in the AWS cloud.
For how long have I used the solution?
I have been working with Amazon EventBridge since its launch. It's a native cloud solution, so you cannot deploy it into your own ecosystem. I'm still working with EventBridge for smaller projects.
What do I think about the stability of the solution?
What do I think about the scalability of the solution?
It's highly scalable because we used it for some US government projects. We are not currently using it in our organization, but in my US organization, I would say most of the hospitals in the US were using it.
How are customer service and support?
We haven't had any escalations for support regarding EventBridge, as their documentation is self-explanatory. It's a very stable platform, so you will only face issues with features rather than stability. There might be a feature or another that you have to figure out, but that's about it.
How was the initial setup?
With the deployment, there were no problems. You just need to go to the dashboard, click on the "create bus" button, and that's it. There is nothing else that needs to be done. It doesn’t need to require any specific maintenance.
What other advice do I have?
It doesn't matter if it's a smaller or larger project since it is scalable for both. If you have a small team or a low-budget company, you can start with it and go with serverless instead of microservice architecture. You can design it serverless and then integrate it completely with EventBridge.
Later, if you decide it's not scaling or your architecture has changed, you can go for another solution. But in the beginning, if you try, you can provide a simple solution that is scalable and cost-effective. Everyone should try this solution first if they can. It works with most projects, but people don't know how to use it. That's what I've seen with a lot of projects.
Overall, I would rate the solution an eight out of ten. The only reason I didn't give it a higher rating is because of the documentation and the implementation process. If EventBridge improves these aspects, I will give it a ten out of ten because there's nothing to complain about in terms of performance and other features.
