What advice do you have for others considering PubSub+ Event Broker?

I have utilized PubSub+ Platform's event replay feature when we were debugging issues, and it definitely helps me understand how or where things broke, quickly enabling us to upgrade the codebase and add additional fixes. I think the documentation for PubSub+ Platform is pretty good and neat, so I would rate it an eight. I would rate this review an overall eight.

I have experience working with Kafka, PubSub+ Platform, and IBM MQ, all three of them. We are customers, meaning my company uses Solace. We use it and customize it based on our needs. Based on my experience, I would recommend other people use PubSub+ Platform. Interested parties can contact me if they have any questions or comments about my review. I rate the PubSub+ Platform a 9 out of 10.

I recommend considering Solace due to its enterprise-level features, high throughput, cloud integration, and security. It is a top competitor among similar products and offers significant benefits in reliability and scalability.

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

We use approximately four people for the maintenance of the solution. My advice to others is this solution has high throughput and is used for many stock exchanges. For business critical use cases, such as processing financial transactions at a quick speed, I would recommend this solution. I rate PubSub+ Event Broker an eight out of ten.

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.

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.

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.

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).

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).

The key is defining the topic structure and working with Solace, the pro serves, and engineering team to define a flexible and also defined and extensible topic structure. It's also important to put a very defined process around application onboarding. Do proper monitoring post-onboarding to make sure that as application publishing subscription, and behavioral changes occur you can be on top of it, be aware of it, and monitor for it. Initially, the key is to set up for a very good governance structure for onboarding, and then go back and make sure you monitor onboarded applications for changes. Know your clients, your applications, and their behavior and be on top of that. From our perspective, Solace has been a true partner in a sense. We work with not only our sales, engineering teams, and support teams to make sure we're aware of all the processes, but we also make sure to keep on top of the product roadmaps. We're constantly talking about what we're doing, sharing with other clients and learning about what they're doing at different customer events. But really, it's being a true partner, having transparency into what's going on, on the platform, what's coming down the pipe and then that world-class support that are the key takeaways from Solace as a company. I would rate it a ten out of ten.

If I was coming into this cold, and knowing what I know today, the one thing we would do differently is we'd have the network team involved throughout the whole process of bringing it into the bank. Bring your network team on that journey with you, because if it's going to become like it has with us — the biggest thing on the network — then you want to have the network team at the table from day one. That way, networking knows things are coming. We're putting these huge things into the data centers and they're going to send huge amounts of data around. That team needs to be ready, so they need to be at the table. In terms of the onboarding and governance processes, fortunately we did think ahead and plan that stuff. But I speak to other customers that didn't and they're struggling with having the right onboarding processes and the right governance around things. At the end of the day, if you've got 95 billion messages going around, if you don't have a good onboarding and governance process, you could just have a 95-billion message mess. We don't have that because we had a good governance and a good architecture to begin with. As I mentioned, I've suggested to Solace that they shouldn't sell their products without enforcing a bit of the architectural piece to begin with. The problem is that everyone has their own budgets and thinks, "Oh, I don't need you guys to help me, and I don't want to pay for it," figuring that Solace is trying to push its Professional Services a bit. But that small investment in Professional Services, when you first stand it up, could be hugely involved in the success of your platform. The Solace Professional Services that we've experienced, and the general value out of that, is worth the dollars you pay for it. From a maintenance point of view, every time Solace releases a new version of the API, we review what has changed in that and whether it affects us in any way. Sometimes a release is for something specific that another client has asked for and that doesn't have any value to us. We don't force applications to upgrade every time a version changes. We tend to do a yearly request of the application teams to upgrade their API to the latest one that we vetted. It's like a yearly maintenance to update the API. And to do that work, to integrate the new API version, it's generally not more than half an afternoon's work to put it in. It might take longer than that to QA, test, and validate your application to put it into production, but the actual coding piece takes an hour or two at most. It's not a huge overhead to be able to do that. In terms of the event mesh feature, we're a bit of a "halfway house." They have multiple things. One is called dynamic message routing (DMR) and another is multi-node routing (MNR). We use the multi-node routing piece. We are testing out the DMR piece of it, which is their newest function for public cloud use. We're in a proof of concept with them around using that for expanding out into Azure and AWS. Internally, we're using their MNR so it's all an event mesh and everything is automatic. If you publish a message in Sydney and you want us to scribe it in New York, we have to do nothing to get that message from A to B. You subscribe and it gets there. Depending on which terminology you're using around event mesh, we consider ourselves to be on event mesh, but we have not deployed that for guaranteed messaging for our general population. We're still using their multi-node routing, which means direct messages fly on demand, and we have to bridge guaranteed messaging. The clustering feature is really designed around trying to make things easier for clients on configuration, so that you don't have to look at things as an HA pair in a DR device, by representing that as a cluster node. This is all work related to trying to make things easier from a support perspective. Today, if you make a change on an HA pair, you can then force-sync that to DR. It automatically happens to the HA box so you only make a change on the primary; it syncs to the backup. You can then choose whether you want to sync that to the DR device or not by putting it into a cluster node. They're just making it simpler for people. It's definitely a positive. We've actually been involved in helping them design that because we were one of their first and one of their bigger customers. We sit in with their engineering at least every six months and they walk through things they've got coming down the road and we talk about how they go about implementing stuff. As for the free version of Solace, at the time, 10 years ago, the free version — that's the software version — didn't exist. With the software version there are limits to the number of messages, something like 10,000 messages a second. We're doing 1,000,000 messages a second. We could run lots of 10,000 messages-a-second instances, but then we would need a lot of commodity servers to run them on. If you are a small company that has some messaging requirements and you are looking for a good way to do that, the free version is absolutely an option. It doesn't come with any support either, obviously. You can pay for support on top of that version, but it's only going to do you 10,000 messages a second. At the scale we have, that wouldn't work. For non-production, giving that to a developer to run on their machine, to play around with, absolutely. So we don't really pay for any of the Dev stuff that we have. We're only paying for the physical production appliances and the reason we need those is just the scale of messaging that we do.

Get folks in various stovepipes to recognize that their data is valuable to aggregate for the entire enterprise. The biggest lesson learnt for me in use case number one has been to get various support organizations to realize that publishing your data is not about pointing fingers and finding culprits. It's about efficiency of restoring service. The solution got us to look internally at how we operate and we behave as a split-brain support organization, where we have some of it on the inside and some of it outsourced. That has been a benefit to us. I would rate this solution as a 10 (out of 10).

There are two important things to keep in mind when considering this tool. The first is to know what kind of problem that you're trying to solve. If it is just about having a pub/sub, there are a number of other tools in the market — including Solace as well, which offers a simple, straightforward solution. But if you are looking at completely digitally transforming your company and bringing in event-driven architecture as a key factor in your integration strategy, then Solace is definitely a go-to tool. Knowing the end-goal that you're going toward, the objective that you're trying to meet, is very important. That is the first step one needs to be aware of and clear about. The second thing is the engagement model with Solace, whether it is the terms of the licensing model or the way you will work with their Professional Services team or their support team. All that has to be discussed and agreed with a clear customer-success plan in place. Thirdly, you want to clearly identify what architecture you want to implement because the mesh can span across anything. But you don't want to start a big-bang approach. Start small and then grow. So you need to know how your architecture is evolving. Start putting that simple MVP in place and from there you can grow it into multiple phases. That's what we are doing. Have the right people in place. Somebody who has a good background and experience in implementing Solace can turn things around quickly. We have four or five architects who use Solace, and we have two administrators of the platform, or platform architects. And we have about five developers now using it, but that will probably go up a little bit once we extend the mesh further. We also have two or three in support. I would rate the solution at eight out of 10. I don't want to give them full marks because there is a lot that they could improve on: the SSO front; there is also the community front, they are also changing their architecture depending on best practices of communities, the way the community works, and so on. There's a lot of work for them to do to re-invent their on-premise model for a Kafka container-based solution. I would give those additional two points, out of 10, if I had seen all of that in action. There is definitely thought leadership within Solace, so I'm assuming that it will come through at sometime.

Start with the simplest use case. Learn how Solace operates and about the ways it will work in your own internal organization. You will have to come up with standard guidelines, best practices, ways of working, etc. Once you understand all of these things, then start picking more use cases at the next level of complexity. Before you put anything directly into production, do a pilot run. Once you are pretty comfortable with this new technology, only then switch over to new technologies. We want to use the solution's event mesh feature, but we are not there yet. Currently, we have two instances of Solace that are connected in a small mesh, but this is a very basic thing. We have the software but did not go for the hardware part of the solution. I would rate this solution as an eight (out of 10).

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.