IT Central Station is now PeerSpot: Here's why
Buyer's Guide
Enterprise Service Bus (ESB)
June 2022
Get our free report covering IBM, Software AG, Oracle, and other competitors of Mule ESB. Updated: June 2022.
610,229 professionals have used our research since 2012.

Read reviews of Mule ESB alternatives and competitors

AwaisOmer - PeerSpot reviewer
Senior Integration Engineer at Systems Limited
Real User
Top 20
The cheapest solution but the learning curve is steep
Pros and Cons
  • "Because we have been doing Red Hat Fuse projects for three years, and over time we have matured, we can employ similar use cases and make use of accelerators or templates. It gives us an edge when we deliver these services or APIs quickly."
  • "As its learning curve is quite steep, developer dependency will always be there in the case of a Red Hat Fuse development. This should be improved for developers. There should be some built-in connectors so the grind of the developer can be reduced."

What is our primary use case?

My current project is using OpenShift Container Platform (OCP), which is a container-based application run by Red Hat. We have deployed the Red Hat Fuse and 3scale applications, the API management stuff, and ESB stuff on OCP containers. In my last project, we were using on-prem enterprise systems and applications as well as the container version of Fuse. Now, it is SaaS-based.

It is deployed for our client organizations. 

One of my clients is a postal and telecommunications client. We do some internal systems integrating with them, some scheduled jobs from one system to another system, and data transfers. There are some of the data integrations, postal integrations, and their integrations with different banks on payments. Therefore, we are using Fuse ESB for this. On top of that, we use the 3scale API Management platform, which is also an acquired Red Hat, open-source, SaaS platform for the API management layer. This is basically the use case for data transfers and data transformations from one system to another. In every other project, the use cases are similar in nature.  

For some security layers on systems, we use OpenID. For integrations with banks, we always use SSO-based integrations.

Our client is using the private cloud with its own data center, but interim projects are managed by the client. The services run on 3scale, so the ESB is managed and supported by Red Hat. 

Red Hat Fuse offers hybrid, on-prem, and cloud versions. The cloud version is managed by IBM Cloud, which is well-supported, but you can set your infrastructure in any cloud version, such as GCP or AWS. Basically, Red Hat-managed infrastructure is on IBM Cloud.

How has it helped my organization?

Because we have been doing Red Hat Fuse projects for three years, and over time we have matured, we can employ similar use cases and make use of accelerators or templates. It gives us an edge when we deliver these services or APIs quickly. 

What is most valuable?

Red Hat Fuse is an ESB. The most important feature of any ESB is its connectivity to diverse systems or endpoints. This is one of the key features that every ESB provides. 

We can expose APIs and consume them.

Red Hat Fuse incorporates all the latest ESB features.

What needs improvement?

Red Hat has the latest, cutting-edge features, but the learning curve is difficult due to its configurations. For the client, it has a good cost, but for developers, it is a bit of a grind.

If a new company is doing Red Hat Fuse development for the first time, there is a bit of a learning curve. They will need to spend time on getting some things ready. 

As its learning curve is quite steep, developer dependency will always be there in the case of a Red Hat Fuse development. This should be improved for developers. There should be some built-in connectors so the grind of the developer can be reduced. 

Developers for Red Hat Fuse are scarce all over the world and the community is not well-built. That can be a problem for big companies.

For how long have I used the solution?

I have been using it for three years. At the start of my career, I did an integration on Red Hat Fuse. My current project is also on Red Hat Fuse.

What do I think about the stability of the solution?

It is stable enough and works on Java. We have implemented Fuse ESB for two or three clients' scenarios, and it is working totally fine. In the case of stability, Fuse ESB is good. 

What do I think about the scalability of the solution?

Scalability depends on the deployment model. If you are implementing it on IBM Cloud or any other cloud, the scalability is easy. In the case where you are using your own data centers or on-prem systems, then you will need to scale the data applications yourself, using local answers. That is also a type of grind on the developer or DevOps team.

Small- to medium-sized companies deploy Fuse in their environments because it is cheap. For example, a giant corporation in America that has a lot of money will not use Fuse services, they will use MuleSoft for their integration. 

In Asia and the Middle East, Red Hat Fuse and IBM are the market leaders. IBM acquired Red Hat, so they have two ESB solutions: an expensive one and a cheap one.

How are customer service and support?

Red Hat gives support for Runtime Fabric. 

In the case of clients, their support should be increased or more enhanced to encourage and attract bigger clients from the market.

The response time is a problem in the case of Red Hat Fuse. Most of the Red Hat Fuse technologies are new to the market. For example, if we take 3scale, the API management product that is also a product of Red Hat, it is missing the API management layer on top of Red Hat Fuse. It is a relatively new product for Red Hat. 

Sometimes, Red Hat engineers do not understand what the problem is and we have to sit with them for hours to detect a problem. Once the infrastructure is on their side, it is their duty to figure out what the problem or issue is, but they are saying that they don't know what the issue is because it is a new product. One of the support members even said, "It's a new product. I don't know what the issue is."

Their support and documentation need to be enhanced. When IBM acquired Red Hat two or three years ago, it improved the documentation. However, the documentation needs further improvement. They need more demos on the Internet and blogs as well as build up a developers' community, where the questions can be answered immediately.

There are some critical issues in the community that have no answers to them. That is why the learning curve is steep. This is where, as a Red Hat Fuse developer, I face problems. I go to the community page and post a question there. But, if I get answers after two or three weeks, then that is a problem for me because of time to market.

I would rate Red Hat's support for Fuse as five or six out of 10.

How would you rate customer service and support?

Neutral

How was the initial setup?

The initial setup is of medium complexity. However, compared to MuleSoft, it is the most straightforward thing. You need to do minimal installations. You just need to set up Java on your system and install Anypoint Studio to work on. 

In the case of Red Hat Fuse, you need to also ensure that you have Java installed and will need to install CodeReady Studio. There might be some dependency issues, which you will need to resolve. That is why it is of medium complexity to set up. 

Red Hat Fuse deployments are time-consuming, because of the learning curve.

If you are not implementing CI/CD, the deployment time will be minimal. If you use hot deployment methods, you can copy your JAR file or WAR file to the on-premises' host folder, then it will deploy immediately. Or, you could use some CI/CD stuff for deploying them, where you are running tests and using pipelines to check in from the source control management systems, but that will take some time. 

The deployment time does not matter. Every other tool is basically built on Java. In the end, all the deployables are running on a JAR or JVM. So, the time is the same for every other ESB.

Compared to other ESBs, the delivery time will not be faster. The delivery time will be more in the case of Fuse, depending on the use case. With a complex use case, you need to do more custom development for Fuse. It is a give-and-take scenario because it is the cheapest ESB available in the market. 

What about the implementation team?

You can follow any of the API or SOA architecture. In our case, we use API-led connectivity, which is proposed by MuleSoft and Red Hat Fuse mimics that API-led approach. So, you can decouple your services and make an application for the same thing, e.g., we are taking the MuleSoft-proposed model and implementing it on Red Hat Fuse. It is easy.

What's my experience with pricing, setup cost, and licensing?

The most important feature of Fuse is the cost. It is open source and a cheap option for an ESB. So, most of the clients in the Middle East and Asian countries prefer this ESB. Other ESBs, like MuleSoft and IBM API Connect, are pretty expensive. Because it is open source, Red Hat Fuse is the cheapest solution, providing almost every integration capability.

Which other solutions did I evaluate?

This solution is similar to other technologies with one main difference. IBM Integration Bus, IBM API Connect, or MuleSoft give us the built-in capabilities and connectors to do different architectures as well as asynchronous or synchronous calls. In the case of Red Hat, we always have to handle the asynchronous calls and stuff inside the Java code and do some custom development, which is a bit of a grind for the developer. However, everything that we can do in the latest, most expensive tool can also be done in Red Hat.

If we take good, expensive ESBs, like IBM Integration Bus or MuleSoft, they will have built-in connectors. Therefore, their time to the market and delivery time will be minimal. In the case of Red Hat and open-source stuff, the delivery time is a give-and-take scenario and the development time is more.

MuleSoft is the best ESB tool in the market. The delivery time for MuleSoft API into the market is minimal. With a medium-complexity-type API, it will take you a week or five days for its development and deployment on production. The same API in Red Hat Fuse might take two or three weeks for a medium-complexity API or service. However, if a company implementing Red Hat Fuse has already developed some accelerators or templates, and they have professional developers as well, then the delay can be minimized.

MuleSoft pricing is huge. If the business has critical integrations and their budget is low, we will propose Red Hat Fuse to them. Everything that can be done in MuleSoft can be done in Red Hat Fuse, but the delivery time and learning curve are a bit of a problem. Whereas, MuleSoft is the best solution in every aspect, except cost. Overall, my rating for MuleSoft is higher than Red Hat Fuse.

Mostly, the cost factor is the deciding factor when businesses consider using Red Hat Fuse. There is a huge cost difference in subscriptions between Red Hat and MuleSoft. Red Hat Fuse is significantly cheaper than MuleSoft.

What other advice do I have?

If your integration needs are not that complex and you have plenty of time for your integration projects to go live, then you can go with this cheap ESB. It does everything that other ESBs do.

On a scale of one to 10, where 10 is best, I would rate Red Hat Fuse as seven.

Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
Flag as inappropriate
RohitSingh1 - PeerSpot reviewer
Integration Lead at a wellness & fitness company with 5,001-10,000 employees
Real User
Top 20
Robust, fast development process, easy to create connectors, and it supports managed file transfers
Pros and Cons
  • "The development is very fast. If you know what you're doing, you can develop something very easily and very fast."
  • "The UI for the admin console is very old. It hasn't been updated for years and is pretty much the same one that we started with. This is something that could be refreshed and made more modern."

What is our primary use case?

We have a lot of use cases for this product. Initially, when we bought this product from Software AG, it was only for a specific project. But, we did watch for other opportunities where it could be used for integration and that's what happened.

Our business model has many verticals, so it's used across the enterprise. The main function is to provide application integration within the company. We have more than 60 applications and at the moment, it's talking to more than 30 applications and integrating them. In this context, it is used by our sales team and in a lot of automations.

Our second use case is to provide Write as a Service. We write any custom service using webMethods and then expose it to others as a REST service.

Another thing that we use this solution for is managed file transfers.

We have this solution deployed in a hybrid environment. It is available in our private cloud, where it is installed in AWS, and we also have it in our data center.

How has it helped my organization?

This solution has improved our productivity and efficiency in pretty much all of our applications. There are some currently-running automation projects where we are going to have to transform data and at the moment, it is being done manually. This is another case where we will implement webMethods to improve productivity.

We automate our sales cycle using API orchestrations. When sales come through, for example, we register them and enroll them in the policy. All of this is done within webMethods and it works well.

With respect to the comprehensiveness and depth of connectors that are available, they have a lot of traditional ones available. They are constantly adding new ones, which is good to see. However, what we found is that we can develop them very easily. Nowadays, pretty much everything is REST so it is easy to develop your own. We do not have a license for many of the connectors. One of them that we have is Salesforce, which was what we had originally envisioned.

Then, what happened when we needed another connector is that we reasoned that rather than buying additional ones, we would instead create our own. Ultimately, we found that it was quite easy to do and in my experience, it is always better to use your own because the out-of-the-box connections have limitations. This is what we found with the connector for SuccessFactors; we were better off building our own because there are no constraints when we do it that way.

This solution encompasses a range of features, which is important to us. We use it heavily for application integration and APIs, somewhat less for data integration, business to business communication, and we are trialing microservices. Although we do not yet heavily use the microservices feature, we do like that it provides it.

We plan to expand our usage of microservices because, in the AWS world, we want to make things auto-scalable. This is what we are playing around with and although we do not yet have it in production, the plan is to use it more.

Modifying and redeploying integrations is easy to do. This has made us more agile and the fact that we can churn things quicker has helped the business.

What is most valuable?

There are a few things about this product that we definitely like. It is very robust. If you build it nicely, you can't go wrong with it. It's rock solid.

The development is very fast. If you know what you're doing, you can develop something very easily and very fast.

What needs improvement?

For the latest services, the product is lacking in terms of connectors. For example, there are a lot of SaaS providers and if you look for the connectors out-of-the-box, they are definitely not going to be there. They have a lot of traditional options but they are basic. If you have an advanced use case then you are better to build your own.

For the most part, this solution supports the latest standards and makes it possible to plug in modern tooling and third-party products for automation and innovation. However, there are some things that it doesn't support and we find ourselves having to wait for a newer version. For example, when we were using version 9.10, it did not support OAuth.

In general, I would like to see the vendor release newer features sooner. Or, it would be helpful if we can use a newer feature but don't have to upgrade the entire product.

The UI for the admin console is very old. It hasn't been updated for years and is pretty much the same one that we started with. This is something that could be refreshed and made more modern.

For how long have I used the solution?

We have been using the webMethods Integration Server for almost six years.

What do I think about the stability of the solution?

I would rate the stability very high. Once it is running, it's very stable.

The webMethods Integration Server is a tier-one application and if it's down, impacts pretty much everything. When it runs, no one knows about it but if it goes down, everyone screams. It is very crucial.

What do I think about the scalability of the solution?

With our current licensing, it's very easy for us to scale. With our older licensing model, it was very hard. This is definitely something that I would highlight. I'm very happy with our current setup because we can scale and it's more of a constraint of your commercials rather than a product constraint when it comes to scalability.

How are customer service and support?

We purchased a premium support package but to this point, we have not greatly depended upon it. In our day-to-day business, we haven't had to deal with them very often, which is a good thing. We generally resolve things within our team and don't generally need to rely on others. There are only a few issues that we have contacted technical support about, such as when we were having issues with the upgrade. Also, if there is something that we can't find then we will contact them.

In general, when I compare their support with other vendors, I would not rate them high. The customer experience with support is an area that needs improvement. The reason I say this is that regardless of the issue you raise, even if it is not necessary, they ask a lot of questions.  

Which solution did I use previously and why did I switch?

Prior to webMethods, we were not using an integration solution. We were a .NET shop and we were using it to accomplish the same tasks. However, it was not to the full extent that webMethods is doing because its capabilities are less.

The reason we adopted webMethods is that a new project was coming and when we estimated the cost, we found that developing everything in .NET was cumbersome. At that point, we started to look for a tool and settled on webMethods.

We chose webMethods over MuleSoft because of how quick and easy it is for developing. It is simple and easy to use. The commercials is definitely another reason that we chose it. This was the product that was recommended after the technical evaluation was complete.

We also use webMethods.io, although that does not fall under Integration Server.

How was the initial setup?

The initial setup is of medium complexity, although it depends on your scenario. If you have a simple use case to just integrate, it's easy. The actual installation is very straightforward but we had some complexity because of the zones.

We had multiple DMZ zones and we have a PCI zone. This meant that there were a lot of firewall rules that needed to be created. It was a greenfield project, so we had to build everything in addition to the webMethods aspect. The project was definitely complex. However, the webMethods setup in isolation was very straightforward. If you just focused on, "Okay, this is the one that you have to install." It's straightforward. If you know what you're doing, it's easy.

Upgrading is something that we can't do in a very fast manner. It's not like we are going to upgrade every six months. We have to wait a while. On the other hand, that's where the microservices architecture is good because anytime something new is released, we can upgrade to the latest.

What about the implementation team?

We completed the initial setup in-house.

Which other solutions did I evaluate?

We evaluated MuleSoft and webMethods. There may have been others but these were the top choices. When we asked for demonstrations, these were the products that we looked at.

This product provides us with a single hybrid-integration platform for all of our integration needs. We do have another product but it is for a very specific use case, and it is separate because of the licensing. Otherwise, webMethods is our go-to for integration.

What other advice do I have?

On the topic of development time, this product can save you time but it depends on what you're comparing it to. For example, if you are comparing it to having no platform, where all of the integrations have to be developed from scratch, then this product will definitely save you a lot of time. The undertaking would be massive. If instead, you are comparing it to another product such as MultSoft, then it will be a different answer. It is tricky to estimate because it depends on the tool.

This is a product that the vendor keeps adding things to. Sometimes, we have to wait until the next version comes out before there is support for what we want to do, but there hasn't been anything major.

My advice for anyone who is implementing this solution is to spend some time thinking about how it will be used. I have seen instances where the product was being used and didn't work properly. If it is designed nicely then it will work wonders, so spend some time thinking about the design and how it will be used and it's never going to have any issues.

I would rate this solution a nine out of ten.

Which deployment model are you using for this solution?

Hybrid Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Amazon Web Services (AWS)
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Flag as inappropriate
Integration Architect at a tech services company with 201-500 employees
Real User
Top 5
Seamless and easy to use
Pros and Cons
  • "One of the most valuable features is how seamless and easy to use this solution is. This is a fantastic solution and a very measured product."
  • "There are a couple of things I want improved, but I think they have already touched upon all those things in the most recent version. I'm not using the most recent version—I use a version older than the most recent—but I'm sure that if I looked into and explored it, I would see more support on the CI/CD and more support for unit testing automation. I've read that they released all these things in the new version of App Connect. Once I explore the new version of this tool, I'll probably have a better idea of suggested improvements."

What is our primary use case?

My primary use case of IBM Integration Bus is for designing and developing solutions. We use App Connect Enterprise as a micro ESB and, in cases where we need rapid development, as a microservices platform as well. I'm currently dealing with an on-premises version, but it's deployed on an internal cloud. 

What is most valuable?

One of the most valuable features is how seamless and easy to use this solution is. This is a fantastic solution and a very measured product. 

What needs improvement?

There are a couple of things I want improved, but I think they have already touched upon all those things in the most recent version. I'm not using the most recent version—I use a version older than the most recent—but I'm sure that if I looked into and explored it, I would see more support on the CI/CD and more support for unit testing automation. I've read that they released all these things in the new version of App Connect. Once I explore the new version of this tool, I'll probably have a better idea of suggested improvements. 

For how long have I used the solution?

I have been working in IBM for almost 17 years now. 

What do I think about the stability of the solution?

This solution is stable. It's a fantastic solution and a very measured product. We only need one person to maintain the DevOps pipeline, but we do have a team of 10 developers to deliver the work.

How are customer service and support?

IBM's technical support is fantastic. Their support process is very good. 

How was the initial setup?

This solution is cloud-based. We are using it in a container image, so the one time CI/CD setup is there, in the pipeline setup, and after that the process is very seamless. We just check in our code, and then the pipeline creates an image of it and deploys it onto our private cloud platform. So it's very seamless and there's no hassle involved. 

Initially, we needed about three people for deployment: one for administrative activities, one with DevOps knowledge, and one developer. 

What about the implementation team?

We implemented through an in-house team. I work as an architect, but we have a DevOps team that takes care of maintaining the pipelines and as-needed administration activities. 

What's my experience with pricing, setup cost, and licensing?

I generally do not get involved in the licensing or pricing because I'm a hardcore technical guy, but I'm aware of the fact that IBM is highly expensive, so not everybody can afford it. All the products are licensed. 

Which other solutions did I evaluate?

I have heard of MuleSoft, a platform that provides a solution for API management, ESB, everything. When it comes to ESB, they have a package or facility feature for unit testing as well, called MUnit or something. From an ESB development point of view, this is the complete package. I was lacking these features in App Connect, but I heard that the latest version includes things like unit testing, automation features, all those things. I also heard that they added AI—I'm not sure where, but IBM is pretty big on that, as well as on adding more and more features in that area. 

What other advice do I have?

I rate this solution a nine out of ten. This is a very measured tool and IBM has been doing a splendid job with this particular platform. Earlier, it was only possible to have an on-premises installation, but now that it's compatible with the cloud, it's a very seamless and fantastic tool. Especially with the current release, I really like this product. 

In terms of advice I would give to those considering implementation, I would say that there could be a problem with integration. Nothing to do with the tools, but from a resourcing point of view. I've seen that a lot of people with Java expertise can face problems when being introduced to this technology without proper training. When a Java developer gets into this particular technology and starts developing stuff, they may be unaware of certain best practices, certain standards, certain conventions that should be used. In my team, when we hire new resources, Java is an advantage for us and a person with Java knowledge is highly welcome, but when we look at their knowledge in the technology itself, there may be issues. This platform is complex and only a person with the right knowledge will be able to deliver. So my suggestion to those who are considering implementation: while resourcing, ensure that you've got the right knowledge on the architect side as well as the developer side. 

Which deployment model are you using for this solution?

Private Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

IBM
Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
Flag as inappropriate
Luis  Alarcon - PeerSpot reviewer
SOA Developer Solution at Xtensible Solutions
Real User
Top 10Leaderboard
Easy to develop and easy to run
Pros and Cons
  • "The features that I have found most valuable are that it is very easy to develop. Most of it is graphical, but we also have the option to add any custom call that you need."
  • "I don't know if the last version has the cloud option, but maybe that could be good. That could be something that is included."

What is our primary use case?

Our primary use case is to do integration with different applications - exposing web service, calling different applications from the customer, orchestrating the call to the service to be a process. There is an application that calls the website and the web service is going to different systems to grab the information, put it together, do the mappings, and send it back to the application.

I think we are using a previous version. I think it is 2019. It's on premises. It's not in cloud. I don't think this version has the cloud option, maybe the latest one does, but we didn't update.

What is most valuable?

The features that I have found most valuable are that it is very easy to develop. Most of it is graphical, but we also have the option to add any custom call that you need.

The runtime environment is scalable. You can deploy a service in one server and if the amount of traffic is increasing, you can deploy the same service in multiple servers so that you're escalating the service to support more calls.

What needs improvement?

I've been working with Aurea CX Messenger the last 14 years and I'm very used to it. I don't know if the last version has the cloud option, but maybe that could be good. That could be something that is included. I'm not sure if the latest version includes it but that is something that would be a nice feature to have.

Another issue, which again, I'm not aware if they already have because we have not updated to the latest version, but all the DevOps features would be nice to have because right now they are using their own deployment features. I am not aware if they already implemented DevOps. That could be something good to have.

For how long have I used the solution?

I have been working with Aurea CX Messenger for the last 14 years.

What do I think about the scalability of the solution?

It's very scalable.

Let me put it this way - this company has a web page. It is a public company. Every single customer that goes to get his information or tries to ask for his information, his payments, are using the ESB.

Additionally, most of the integrations that the company is doing include the ESB, it is the core of the integration.

Obviously, in this is company it is very useful.

How are customer service and support?

They are good. There are some times where there is a bug that is taking some time to figure out, but in the end they always figure it out. Most of the time it's a very quick response.

Which solution did I use previously and why did I switch?

I used to use Mule ESB sometimes a very long time ago.

How was the initial setup?

The initial setup is not complex.

What's my experience with pricing, setup cost, and licensing?

I have been working with this tool for the last 14 years, so I've been seeing how it has evolved. What I'm seeing is that it is less expensive than other options, but I am not too involved in that.

What other advice do I have?

My advice to anyone considering Aurea CX Messenger is just try it. Take a shot with them. From my experience, it is very easy to deploy, very easy to develop and to implement in production. Just give them the chance.

On a scale of one to ten, I have to give Aurea CX Messenger the best, a 10.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
Andile-Hlongwane - PeerSpot reviewer
Engineer at a financial services firm with 10,001+ employees
Real User
Top 20Leaderboard
Easy to use, plenty of functionality, but expensive
Pros and Cons
  • "The solution is straightforward and for large organizations, it functions well."
  • "IBM DataPower Gateway is quite big for smaller organizations, looking at different types of clients who are virtually assisted in this, I would say it's not really a good product for smaller firms."

What is our primary use case?

We're using IBM DataPower Gateway for API management more than anything else. When I started in 2018, it was being used in conjunction with IBM Integration Bus. We were doing all the integrations on the IIB then when it comes to API management and all the other gateway operations, including security, that does not have anything to do with APIs, we're are using IBM DataPower.

What is most valuable?

The solution is straightforward and for large organizations, it functions well.

What needs improvement?

IBM DataPower Gateway is quite big for smaller organizations, looking at different types of clients who are virtually assisted in this, I would say it's not really a good product for smaller firms.

For how long have I used the solution?

I have been using IBM DataPower Gateway for three years.

What do I think about the stability of the solution?

IBM DataPower Gateway is quite stable if you know your way around.

We have four customers that are using this solution. We have millions of users using this solution.

What do I think about the scalability of the solution?

The scalability is a bit of an issue when you are a smaller firm because it can be quite expensive. If you are using an on-premise version, it's not as scalable because you need to buy the hardware devices. If you are using the virtual version, it's a little bit easier to scale.

How are customer service and support?

The technical support is always available and I think it's one of the options they are charging us for. They are well-informed agents. You better know your way around the solution, otherwise, you're going to rely on technical support for a whole lot of things.

Which solution did I use previously and why did I switch?

We have previously used Microsoft BizTalk Server. I've also worked with webMethods and a little bit of MuleSoft.

How was the initial setup?

The installation is not that easy. 

I would rate the ease of installation a six out of ten.

What about the implementation team?

The number of staff that we need for the implementation of the solution depends on the scale of the environment, but you certainly need a couple of engineers for the support and management. IBM has a set amount of people that are required.

What's my experience with pricing, setup cost, and licensing?

IBM DataPower Gateway is quite expensive to get resources to work on this product. If the price could be cheaper, I think that will make it a little bit better and easily accessible to smaller clients. Then it could compete with other solutions that are available in the market. There's a whole lot of other solutions available that work well and are cheaper than IBM's products.

They have to reconsider the price of the solution. It's way too expensive. I don't think it's going to last that long in the market right now. There's a lot of other solutions that are out there that are doing the same job, or even better, with a cheaper price. Soon enough, IBM is going to run into trouble when comes to the price.

Which other solutions did I evaluate?

I have evaluated many other solutions.

What other advice do I have?

I would not recommend IBM DataPower Gateway because there are other solutions that are better.

I rate IBM DataPower Gateway a seven out of ten.

Which deployment model are you using for this solution?

On-premises
Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
Flag as inappropriate
Buyer's Guide
Enterprise Service Bus (ESB)
June 2022
Get our free report covering IBM, Software AG, Oracle, and other competitors of Mule ESB. Updated: June 2022.
610,229 professionals have used our research since 2012.