When we started with Red Hat, we were using AMQ for asynchronous messaging between different applications. We began using 3scale and Fuse but these days, these solutions are packaged as one product called Red Hat Integration. They are bundled and you cannot acquire them separately. Now that this is the case, we use the entire package.
Vaguely, Red Hat AMQ is a wrapper over Apache Kafka and ActiveMQ, made and supported by Red Hat. There are plenty of use cases. Essentially, we use it for whatever use case you can think of for asynchronous messaging.
As an example, it is responsible for populating data lakes with relevant data.
Red Hat AMQ supports hybrid cloud deployment, and while we have an on-premises deployment at this time, this feature is important to us because we are planning to transition to the cloud. We expect that if not all, at least the majority of our applications to be on the cloud within five years.
It is very important to us that Red Hat Integration includes transformation, routing, connectors, and a distribution of Apache Kafka, all built to run on Kubernetes. All of these features are supported by Red Hat, which means that the maintenance and currency of this solution are assured. We used to question why we would buy a wrapper over an open-source product, instead of just using the open-source directly. Now, we see that the distinguishing point that gives us value is maintainability. With the full support of Red Hat, it takes much less effort and resources.
Red Hat integration enables developers to serve themselves what they need via APIs and event streams. It's a baseline technology that we build upon it for our use cases. It includes plenty of mechanisms for interacting with other systems.
The toolchain is okay but it's not great. They have enough for developers to start using these technologies effectively. However, in some cases, they are not as mature as we would like. For example, Fuse uses Apicurio. It's a different open-source product that visualizes the flows of the API implementation, including the transformations and everything that's happening inside the component. This is a feature that can be much better.
From the support perspective, they are supporting it to the maximum of their ability, but they do not have any SLAs connected to it yet because it's not their product. They're just using it extensively alongside the whole bundle.
With regards to the toolchain, they do have Fuse plugins for major IDEs. All of the interaction with 3scale goes through the web interface. Configuration-wise, the versioning is okay.
In general, the other products are a bit more mature when it comes to the toolchain. The Red Hat product allows it but requires a bit more seniority from the first adopters to get used to it, and then transfer this knowledge to others. This is in contrast to MuleSoft, where you can take junior to intermediate developers and they will make their way through. Here, it's a little bit different. You definitely need to have good Java experience at the senior level to quickly grasp how to work with all of the tools and technologies.
Also, the graphical presentation of all of the tools and flows is not as mature as you would expect from this type of framework. Because of this, a good developer, intermediate to senior level, will need to get used to these tools, and then, it'll be much easier to transfer the knowledge. That said, it was all good enough for us to get started with.
The other products have much better visualization tools available that integrate well with the platform. This gives you an opportunity to build something visually and then it will convert the code. You see more or less what's going on. With AMQ, you have the same capabilities but you need to write plenty of code.
Using this solution helps us to deliver new services faster. Fuse has prebuilt components that communicate with AMQ, which gives us an upper hand from a productivity perspective.
AMQ has definitely reduced our developer dependency on the IT department. Our DevOps engineers take care of the application infrastructure and they work with developers to resolve whatever issues they have. As an example, consider the case where we use 3scale to configure throttling or other aspects. If you compare the level of effort to configure, deploy, and maintain the API against when we were not using 3scale, it is much less when we use the Red Hat solution. This is true not just for maintaining the API gateway and API management platform, but in general.
From the build perspective, when you know the product well, it will take less time to create API products that are simple to medium level of complexity. From the AMQ perspective, 3scale and Fuse help to eliminate the headache of maintaining the platform that enables your asynchronous messaging.
The event-driven architecture enables us to decouple services from each other, and our developers can do their own integration. This is a benefit to using the event-driven architecture patterns, which can be used with any product that enables asynchronous communication.
