PubSub+ Platform Reviews

PubSub+ Event Broker is used to help manage architectures, such as real-time integrations of business processes and systems.

The most valuable feature of PubSub+ Event Broker is the scaling integration. Prior to using the solution, it was done manually with a file, and it can be done instantly live.

The section on observability pertains to understanding the functioning of an event crash. Instead of focusing on how the crash occurs, attention is given to the observable aspects, such as a memory pipeline where one person pushes messages and another reads them. However, this pipeline often encounters issues, such as the reader being unavailable, causing the system to become stuck and preventing the messages from moving forward. This can lead to the pipeline being permanently stalled.

More observing capabilities should be added.

I have used PubSub+ Event Broker within the past 12 months.

The solution is stable. We are informed about any outage that happens.

We have had times when messages were stuck and we have to flush the pipeline. There is a gap in the scalability.

We have two customers using this solution.

The initial setup of PubSub+ Event Broker is easy. We can simply connect the solution to an SAP S4/HANA. We had no difficulties.

To install SAP in the public cloud, we need to provide SAP with a basic configuration file, which is a straightforward JSON file. SAP takes care of the entire installation process based on the configuration provided by PubSub+ Event Broker. Therefore, most of the installation work is handled by SAP, and we only need to specify our requirements and the duration of the process. It's a relatively straightforward process.

We had a range of technical people involved in deploying this solution with a maximum of 10 assisting in the process.

The price of the solution is expensive.

I rate PubSub+ Event Broker a nine out of ten.

There was a challenge in the market that needed addressing. While some tools could serve as event managers, they were not proper event brokers. For instance, Kafka is referred to as an event broker but not a proper one. If you want to use it as an event broker, you would have to implement your event manager, which could be quite complex. The same can be said for Kafka, a text-based broker that stores events in a text file on disk and then consumes them. In other words, an event is just a message stored in a text file that is not reactive. If you introduce events into the system, you cannot react to them in any way. It creates a problem that needs to be addressed by implementing tools that can react to events or pre-defined topics. The way topics are created is also an issue. For instance, if you want to consume a specific topic, you have to create a new one, and you cannot filter events using the mechanism provided. If you wish to query events, there is no provision.

It is where PubSub+ comes in. It provides the option to query events and route messages from one topic to another, as well as clients, to facilitate this process. We primarily use PubSub+ for event-driven applications, where we react to and process applications based on those events. For instance, when we receive an order, we react to that event and create multiple other events based on it. This reaction is based on events, so we use PubSub+ Event Broker.

We mostly had a few teams, which were prototypes because we were planning for large-scale usage. But now, some domains have around fifty to sixty developers using PubSub+ Event Broker, and that's the teams using it.

PubSub+ Event Broker has a nice dashboard to see the domains and has good asynchronous API documentation. If you are a small or medium-sized company and not very rigorous on the compliance side, and you don't go for production issues on your own cloud, it's a very good tool to reuse.

One of the main challenges of deploying PubSub+ is integrating it with existing applications. The naming convention of PubSub+ can be confusing, and the way it handles producers and messages should be more like a channel where messages can be posted, and watchers can react to them.

PubSub+ Event Broker is a nice tool, especially if you want to deploy into on-premise data centers along with the cloud. It has a complicated architecture, but somehow it works. However, I don't think they have ever worked with very high-scale applications. There have been many improvements, but it still lags behind when compared to large-scale applications. It does not work out of the box and there may be confusion due to its complicated solutions. Nonetheless, it is still a good product to use.

I have worked with PubSub+ for the last two years. I am still working on it currently. We stopped using PubSub+ about two months ago.

PubSub+ Event Broker is stable.

There were several issues with the scalability of PubSub+ Event Broker, such as deploying it to their own environment and integrating it with their applications. They found that the naming convention of publishers and producers was confusing, and the process of creating a topic, making a queue, and making it work was complicated. PubSub+ Event Broker lacks the feature of a channel where someone posted a message and someone from the team reacted to it, which is present in AWS EventBridge. The dashboard to monitor events is missing in PubSub+ Event Broker, making it difficult to map domains and monitor events. The implementation is entirely in Docker, and to scale it, it must be deployed into a cluster queue or an ECS machine, which is costly and operationally intensive. The architecture of this distribution needs improvement.

The technical support team responded on time.

Positive

We stopped using AWS EventBridge because they had some issues with the API specifications regarding how to design the governance and other features. Even though it is a very good tool with all the necessary mechanisms, it does not offer an easy replay function. The dashboard to monitor events is missing in PubSub+ Event Broker. The solution is also complicated and not easy to use, making it difficult to map domains and monitor events. The implementation is entirely in Docker, and to scale it, it must be deployed into a cluster queue or an ECS machine, which is costly and operationally intensive. The architecture of this distribution needs improvement.

First, we experimented with an on-premises model and then we tried the cloud model for production. However, we encountered some issues. The cloud model is successful and does not have these kinds of issues because it's in its own ecosystem. But when you move to your own cloud, you want to manage the security and everything yourself.

The problem is that you have to deploy and recreate a VPC, and they will manage the VPC. You will not manage the VPC and the security of the system. This is a compliance risk that no management team would allow, where a third party manages your own or else account. There are solutions like creating a separate account and then keeping it there, but still, it's deployed in our own cloud, and we can manage the network or security of the whole account in which it was deployed. This is a tradeoff. The main challenge of using PubSub+ Event broker was deploying it to their own environment and integrating it with their applications.

The first deployment challenge is deploying it into Kubernetes. When it is only, it is the only model that they offer. So, in our teams and our company, we are not fond of using Kubernetes unnecessarily because it adds overhead to the Kubernetes cluster. Then you have to hire people who can manage this complexity, and there are many complexities inside. It's a huge thing to deal with. And even PubSub+ is also one of the complicated solutions. So you must manage two complex solutions in one place, working together. So it was too much operations work for the team.

It is one thing. And then after that, keeping this ECS content thing, so it's like one ECS, small ECS content cannot run it. You need to have a very heavy ECS cluster that can connect to the broker. Otherwise, if you have a very large-scale application, this federal will die, and then after that, you will lose the connection to the PubSub+ Event Broker. So you must keep one extra layer of a very heavy ECS cluster that can communicate with the broker. And then, after that, it can forward the requests to the APIs or the targets. And this ECS cluster also costs extra money for this.

We had a devOps team who was responsible for maintenance. But it was not a go-ahead and deployed on a large-scale solution. So we had a few problems with it. Specifically, we were still figuring out whether we should go for it. We had piles of issues that we liked to pile up in a matter of time. Every second week, we had something new coming up. Then it became when we solved all these problems and had a conversation with the team; we found out that they have a small team managing things and were really slow in managing things. 

The ROI was good initially, but we eventually found that it would cost too much in recurring operations cost to maintain. So while I don't remember the figures, it wasn't worth it. And if you compare it with other solutions like Kafka, they are much cheaper and easier to maintain than PubSub+.

We paid around thirty-five or thirty-eight thousand euros for it. It was for a medium-sized deployment with two nodes.

My advice is mainly technical. If you're a big corporation with thousands of applications running, then PubSub+ is a good choice. But if you're a very small or mid-range start-up, it may not be necessary if your application doesn't require high computing or compute-intensive operations. However, it's important to consider the investment required, including licensing and operations costs. For example, even just for basic connections, the server cost for 100 or 250 connections can be around 100,000 euros.

Overall, I would rate the solution a seven out of ten.

The way we can replicate information and send it to several subscribers is most valuable. It can be used for any kind of business where you've got multiple users who need information. Any company, such as LinkedIn, with a huge number of subscribers and any business, such as publishing, supermarket, airline, or shipping can use it.

It could be cheaper. It could also have easier usage. It is a brilliant product, but it is quite complex to use.

I have been using this solution for several years.

It is a very stable product.

It is scalable. We have a couple of hundred users.

Their technical support is very good.

We just used MQ before this. We found out about PubSub, and we started using it as well for its benefits.

It is a bit complex, but you get instructions. Once you know what to do, it is fairly straightforward. The installation takes about 30 minutes, but configuration takes a long time. After you gather all your data, it could sometimes take a day or two.

I have done it myself. We have around 50 people for maintenance.

It could be cheaper. Its licensing is on a yearly basis.

It is a brilliant product, but it is quite complex to use, so you need a deep understanding. There is good information. They have thought of everything and noticed what the customers tell them. In every release, there is something better in it. I would definitely recommend this solution to others.

I would rate PubSub+ Event Broker a nine out of ten. 

We are using Event Broker to publish data across the enterprise, then share the transaction data updates in real-time across the enterprise, and also in some cases the telemetry data.

We do use event mesh, but our use is limited. The reason for that is we have our publishers and consumers on-prem while have our applications on AWS, Azure, and SaaS. It's a multicloud hybrid infrastructure, but the majority are still on-prem. We are slowly moving to AWS, Azure, and SaaS. As we expand to AWS and Azure, then event mesh will be a key feature that we would like to leverage.

We are using the latest version.

When publishing a product, it updates across the enterprise. We have 100 to 200 consumers, which are basically the applications interested in product changes in real-time. We could publish these product changes to Solace Event Broker with one update. Then, all 100 to 200 consumers could be listening to this topic or queue. Any time a change happens, it's pushed to this topic. They have access to it and can take whatever actions based on those changes. This all happens in real-time.

We used more point-to-point integration in the past. This solution reduces the latency to access changes in real-time and the effort required to onboard a new subscriber. It also reduces the maintenance of each of those interfaces because now the publisher and subscribers are decoupled. Event Broker handles all the communication and engagement. We can just push one update, then we don't have to know who is consuming it and what's happening to that publication downstream. It's all done by the broker, which is a huge benefit of using Event Broker.

With the event mesh feature dynamic message routing across the enterprise, you could have an event getting published from on-prem and consumers in the AWS public cloud. The publisher doesn't have to know where the consumers are. The publisher will publish it to the event broker, which could be on-prem, and the broker will have the intelligence to route the events to wherever these consumers are, whether it's AWS or a broker. If there's another broker in agile, then it will have the intelligence to route it dynamically so the publisher doesn't need to know where the consumers are. Event mesh's ability to have brokers installed across a diverse multicloud on-prem infrastructure gives us the flexibility to support applications across our enterprise. That has a big advantage.

If you just have one broker trying to do all this routing of events to different subscribers across different infrastructures, it will have a huge impact on performance. With Solace, events are routed based on the load of the broker. It can dynamically adjust the burst capacity and scale based on the events being pushed as well as events that aren't getting consumed. The logic about how to manage the routing and scaling happens dynamically between brokers. 

• The ability to publish data events in real-time to the broker.
• The ability to add multiple subscribers seamlessly to topics and queues using different formats and protocols.
• The Solace Admin Utility is pretty intuitive and flexible.

E.g., if you have to configure these manually, then the publisher of each event would have to manually configure these events to the topics, provide access, and do monitoring. All these activities would have to be done manually without a Solace Admin. The Solace Admin provides you a UI where any publisher with appropriate access can create their own topics and queues. It can also provide access to subscribers so they can administer their own events.

There is another feature where subscribers can easily discover different topics to consume. If they can find it, then they can, get access to it through the workflow in the Solace.

An advantage of Solace is the way they define their topic hierarchy. With the whole filtering on the topic, we are able to publish data to multiple systems without creating new topics fragments. For instance, if you didn't have that flexibility of the topic hierarchy and ability to do filtering, then you would have to create new topics for a different combination of data sets. This filtering ability creates a lot of flexibility in creating generic topics, where subscribers can just do a filter and consume whatever data they need. That's a powerful feature.

It's very granular. If you can define your topic schema with some order, then you can pretty much do whatever data set at the lowest level. It does provide a lot of flexibility that way without making any changes upstream.

The solution’s topic filtering, in terms of the ease of application design and maintenance, provides us flexibility. The solution makes it easier to consume data on same topic but also change the logic or filtering. E.g., if you want column one, two, and five from a topic schema today, but then you may decide the next day that you need column four and seven.

The solution's event mesh has the ability to make a network of brokers look/seem like a single broker. E.g., if you have consumers in on-prem, AWS, and Azure, along with some SaaS providers, external customers, or partners, you could have brokers deployed for AWS, Azure, and outside for external customers, respectively. If the publisher is publishing an event from on-prem, then they just publish the one event to the broker deployed on-prem. The on-prem broker will route the request to the AWS broker, Azure broker, and the external broker seamlessly. This is transparent to the publisher and consumers, which is a positive feature.

The discovery part needs improvement. E.g., if I have a topic or queue, I want a common place to look at all the different subscribers who are using them. I think they have added this to the Event Portal, but it's not live yet. If they could have the ability to discover events and the relationship between publisher and subscriber for each topic, that would be a very powerful feature. 

I would like them to design topic and queue schemas, mapping them to the enterprise data structure. We have recommended this feature to Solace. 

About eight months.

It's very stable. There's high availability. The architecture is pretty robust and can fade over. It's pretty much a NonStop platform as long as it's architected the right way. 

We have a small team who is responsible for monitoring the alerts. However, they're not dedicated to Solace as they also look at other platforms. The maintenance is low because you can pretty much automate all the alerts. In a lot of cases, you can also resolve them systematically. 

You can scale it across multiple instances seamlessly. You can add instances without really disrupting operations. It's obviously not on multiple environments so you can easily add hardware or resources as required. It's very robust in that sense.

We have about eight people using the solution. Their roles are mostly cloud architects and integration architects, as well as some integration developers. 

Right now, we have about 25 applications using Solace, but we anticipate this to increase significantly as we onboard more data sets. By the end of this year, there should potentially be about 100 applications using Solace.

We have used their technical support as well as their professional services. 

• They have a very strong support team. 
• Some improvement is required with Solace professional services. The professional services really needs to drive the solutions for the customers and share best practices. They also need to guide the teams through the right things.

We use Apache Kafka, which is more of an API gateway. For us, events is a new concept. We do more request/reply, API-based integration patents. We also have typical event-driven architecture. This is still a new concept for us that we are trying to evolve.

The initial setup is straightforward. One of the good features about Solace is their documentation and onboarding scripts are very intuitive, easy, and simple to follow.

The broker took three to four hours to deploy.

We had an implementation strategy before we actually deployed it. In terms of:

• How are we going to create this event mesh across the organization? 
• Where are we going to deploy this broker? 
• Which applications are going to onboard as a publisher, or which events? 
• Defining the topic schema. 

We did spend some time planning for that process in terms of how we were going to do the maintenance of the platform.

We have seen ROI because we started with the free version. Even now, we have a basic enterprise license and are getting the business value from its cost.

We have seen at least a 50 percent increase in productivity (compared to using Kafka) when using Solace for the following use cases:

• Sharing changes in real-time.
• Onboarding new subscribers.
• Modifying data sets.

The pricing and licensing are painless. Having a free version of the solution was a big, important part of our decision to go with it. This was the big driver for us to evaluate Solace. We started using it as the free version. When we felt comfortable with the free version, that is when we bought the enterprise version.

For simple use cases, the free version works. Because we wanted the maintenance and access to the technical support, we went with the enterprise license which is pretty cost-efficient compared to other commercial products. Licensing-wise, it's pretty much free if you want to start off with the basic version, then you can expand to other additional features as you feel comfortable and confident. You have that flexibility from a licensing perspective.

Once we decided to go with Solace, we then evaluated Kafka and also looked at RabbitMQ. However, this was mostly to ensure we were making the right decision.

Some of Solace's key differentiators versus Kafka and RabbitMQ are its free version with the ability to deploy and try the product. It's very easy to implement the broker and create the topics and queues. It also has helpful documentation and videos.

Kafka has some admin features, but not like Solace Admin or Solace Portal. It has limited UI features, as most of it is through a CLI. The key difference would be that you need a specialized skill set to be able to administer and maintain an event broker, if you are using an open source.

This solution has increased application design productivity compared with competitive or open-source alternatives. The key is it's a concept that is not obvious. Event-driven architecture is still evolving, as people are still comfortable with the traditional way of designing these products. If you purely compare it with open source, this solution has a lot of advantages. In our case, the adoption is still slow. Primarily, that is because of the skill set and maturity of our architecture.

The solution management productivity increased by 50 percent when compared to using Kafka.

Compared to Kafka, with our internal use cases, Solace is definitely the right solution now. If we use the telemetry IoT use cases, such as real-time streaming and analytics, then Kafka would probably have an edge. However, for our use cases and the volume that we have, Solace is good for us.

It would be good to think through your event-driven architecture, roadmap and design.

It is very easy for architects and developers to extend their design and development investment to new applications using this solution. Compared to the legacy integration pattern, there has been mindset shift because the changes are coming in real-time. The solution has the ability to consume those events in real time, then process them. While there is a learning curve there, it's pretty easy to consume changes. 

Biggest lesson learnt: Think through the whole event-driven architecture and involve other stakeholders. Prepare a good business case and have a good MOC before getting started.

I would rate this solution as an eight (out of 10).

We use it as a central message bus to interconnect all our applications as well as for the transportation of market data.

We're using the 3560s for the hardware appliances and version 9.3 for the software.

It has helped a lot in the unified way of how we develop software. Having a common message processing protocol has helped a lot with maintainability and how software has been designed. It also removes the worries that the message bus is not performing well, e.g., the throughput rates are so high that it works very well.

The solution has increased application design productivity.

It is easy for architects and developers to extend their design and development investment to new applications using this solution. That's never been a roadblock.

PubSub+ capabilities make it all work. 

Guaranteed Messaging allows for us to transport messages between on-prem and the cloud without any loss of data.

The solution’s topic hierarchy is pretty flexible and works well. It does require some engineering thought in the beginning to ensure that the hierarchy works and you don't shoot yourself in the foot. But if that is architected well, it allows for very nice filtering and subscription based on what you are interested in. 

The topic hierarchy's application design and maintenance works very well.

The ease of management could be approved. The GUI is very good, but to configure and manage these devices programmatically in the software version is not easy. For example, if I would like to spin up a new software broker, then I could in theory use the API, but it would require a considerable amount of development effort to do so. There should be a tool, or something that Solace supports, that we could use for this, e.g., a platform like Terraform where we could use infrastructure as code to configure our source appliances.

Monitoring needs improvement. There is no way to get useful systems to test out the machine without having to implement our own monitoring solution.

I would like to see improvement in the message promotion rate for software-based brokers.

More than 15 years.

It is extremely stable. The amount of hardware-based interruptions that we have had from the Solace products are less than 10 in the last seven to eight years. It has extremely high reliability.

Since it is a hardware-based solution, what you buy is what you get. You can then upgrade it, but we have never had a need to upgrade and scale the solution.

It is used for all our applications. The whole company is using it, including traders, developers, and risk.

The technical support is very good. Our questions have always been answered and resolved in a very good way. They seem very knowledgeable about their product and can go into depth about how and why we should implement it in certain ways.

The initial setup was pretty straightforward.

The deployment was part of a larger rollout. For just the physical deployment, it took a day per site.

We had good support Solace during the deployment and the architecture phase of designing how we would use the product.

It has provided us with a return on our investment. It has enabled us to do what we do now.

The pricing and licensing were very transparent and well-communicated by our account manager.

There was no free version when we evaluated it.

We compared a few messages bus solutions, like TIBCO. At that point, Solace came out ahead, both in throughput and probably cost.

We haven't really used any competitors. I don't think there are many on the market still. I don't think the solution really compares that well with any of the open source solutions. Maybe the setup ease with MQ is similar to Solace, but then to keep it operational, Solace is much easier. It's a hardware appliance that you can install in a data center, which just keeps working. That is amazing. It is something that software or open source solutions don't offer.

It is a product that is more like a switch or router, where you install it, then it keeps on working. The operational maintenance is extremely low.

Read the documentation. Talk to Solace about any questions that you might have to find out the best implementation for whatever it is you need to solve.

I would rate the product as an eight (out of 10).

We use it as a message bus for our different systems to connect to Solace on a pub/sub basis. We have about 10 systems interfacing with it. It is used for our critical payment systems which are mostly online payment transactions. There are also messages for streaming and data warehouse info.

We are using the Solace PubSub+ 3530 appliance, and the AMI (Amazon Machine Image) version. We have a mixture of an on-premise deployment and a cloud deployment. The cloud part is more the AMI.

Because we use it as a message broker, it makes information flow very seamless.

When we do the setup we establish the naming conventions. So all we need to do is to tell our stakeholders who are interested in using Solace to follow the naming convention. That way, everybody can implement things according to their own timing and schedule. We decouple implementation from the various systems. We just publish things and whoever is ready to consume does so.

From an application design perspective, it is quite easy for them to interface with it and they don't need a lot of rules. Solace has increased application design productivity. It has reduced dependency. Anybody can work with it based on their own timeline so, to a certain extent, there's no bottleneck when they use it.

We have also seen an increase in productivity when it comes to solution management, by about 30 percent.

It's very easy for architects and developers to extend their design and development investment to new applications using solace because it's quite standardized, as long as they follow the template when they do the design. They just have to publish according to the particular template. There is no need to redesign.

• Everything is good in this solution. We only use the PubSub feature. We use a minimum of topics to publish and they are consumed through the Solace message broker.
• We have a standard template for any new configuration, so it's very easy to manage.
• The topic hierarchy is pretty flexible. Once you have the subject defined just about anybody who knows Java can come onboard. The APIs are all there.
• Topic filtering is easy to use and easy to maintain. Sometimes we go into a lot of detail on the content and it can be affected at a higher level. So it's very flexible.

The product should allow third-party agents to be installed. Currently, it is quite proprietary. It doesn't allow third-party agents to be installed.

I have been using Solace PubSub+ Event Broker for three years.

The product is pretty stable. Since the time we set it up, there has been no need for us to reboot the appliance. We have had zero downtime.

It's quite easy to scale. We just have to build in another set.

We have plans to extend it into our warehousing systems — those are portals — so that the information can be shared.

They are very knowledgeable and their responses are pretty fast.

We did not have a previous solution. We went with it because we liked the features that Solace provides and, to date, it has delivered.

The free version allows people to do a proof of concept easily. It helps people when they want to see how easy it is to use. The free version helped us to decide to go with the solution.

The initial setup of Solace was straightforward. We just had to buy the product, install it, have a few templates, and that was it. We were already good to go.

Our deployment took about a week or so. After that, we did integration testing. Once that was okay we had to come out with a template for people to follow. The learning curve is quite small.

To administer Solace we only need two people. That's because it has role segregation.

In terms of dollar value we have not seen ROI, but in terms of availability, we have, because the product is very stable.

So far, we are okay with the pricing and the licensing.

We didn't compare Solace with competing solutions. 

It's a good product to go with if you are interested in uptime and availability, and ease of implementation.

The biggest lesson I have learned from using Solace is that once you get the design correct, everything flows very seamlessly.

An enterprise-grade event broker for mediation of events produced by a heterogeneous hybrid landscape of SAP and non-SAP systems at scale.

An event registry/catalogue and a user-friendly visualization of event flow.

The event portal and the diversity of deployment options in a hybrid landscape are the most valuable features.

The licensing and the cost are the major pitfalls.

I have been using the solution for almost two years.

It is a very scalable and robust solution. I rate it a ten out of ten.

We are generating stock calls and then those are given to various other processes.

As of now, the most valuable aspects are the topic-based subscription and the fanout exchange that we are using.

It was easy to set up and implement. 

As of now, it is satisfying all my requirements. There is nothing much that I am looking for or missing in the product. They could focus on the speed, or maybe something like error handling or resending those requests.

If you create one event in the past, you cannot resend it. You need to create it from the beginning.

They could always improve security.

I've used the solution for three or four years. 

We have three teams using the solution right now. There are about ten people per team using it. We have about 30 licenses. 

It's used on a daily basis. 

I can't speak to technical support. I've never reached out to them at all. 

We're also familiar with RabbitMQ. If you compare PubSub Event Broker and RabbitMQ, PubSub is more reliable. RabbitMQ requires a line to be installed, and it was a bit of a tedious process to get it installed. After that, it was smooth enough. My use case, whichever I use, is satisfied. I haven't explored either very deep beyond my own use cases. 

The solution is very easy to set up. It's straightforward. It's not overly complex or difficult.

The implementation was set up in-house. We didn't need any integrator or consultant support. 

I'm not aware of the exact pricing. 

I'd recommend the solution to other users, so long as it aligns with their use case. This product is more suited to a small to medium-sized company.

I'd rate the solution seven out of ten. If it was faster and perhaps had some security enhancements, I would rate it higher.