The solution could be improved by enhancing the message pooling size for persistent messages to handle both small and large messages effectively. Additionally, providing a comprehensive dashboard to display metrics such as message throughput, connection rates, latency, and automated alerts would be highly beneficial.
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.
Cloud Architect at a transportation company with 10,001+ employees
Real User
Top 5
2023-03-17T12:56:42Z
Mar 17, 2023
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.
Independent Technology Consultant - Financial Softwares at a tech services company with 51-200 employees
Real User
2022-06-26T13:37:00Z
Jun 26, 2022
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.
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.
Head of Enterprise Architecture & Digital Innovation Lab at Hewlett Packard Inc.
Real User
2020-06-21T08:08:00Z
Jun 21, 2020
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.
Senior Project Manager at a financial services firm with 5,001-10,000 employees
Real User
2020-06-16T08:37:00Z
Jun 16, 2020
Some of the feature's gaps with some of the open-source vendors have been closed in a lot of ways. Being more agile and addressing those earlier could be an area for improvement. Obviously, their movement to cloud and integration is there. There's a need to keep investing in that area to make sure that there's feature parity with their competitors and have that seamless burst to the cloud available like all the vendors that are out there. But from our perspective, if they can keep that feature parity, there'll be little appetite to move.
Managing Director at a financial services firm with 5,001-10,000 employees
Real User
2020-06-15T07:34:00Z
Jun 15, 2020
We have various items on the docket with Solace. We've pointed out some things with the DMR piece, the event mesh, in edge cases where we could see a problem. Something like 99 percent of users wouldn't ever see this problem, but it has to do with if you get multiple bad clients sending data over a WAN, for example. That could then impact other clients. In our current state, we've architected around that with Solace. We can see, in the future, with the event mesh DMR, that there is potential for several bad clients to cause problems for other clients. We actually had a design session yesterday with the head of engineering where we started working on how to solve that 1 percent "corner case." We're working on the basis that if it can happen it will, even if it's very unlikely. We design for those kinds of days as opposed to, "Oh, this will never happen." It's really about multiple streams and guaranteed messaging between multiple regions over WAN potentially causing one user a problem. We're trying to solve for that kind of stuff. It's very specific, but that's just how we think. Being a financial organization that is obviously regulated, we can't afford downtime. So we try to look at everything through that lens.
The storytelling about the benefits needs improvement. We have four major lines of business in our company. Our retail, capital markets, and internal corporate center lines of business along with technology operations, which is more of a cost center. Technology operations are not innovators, but more a keep the lights on arm of the business. One of the areas of improvement would be if we could tell the story a bit better about what an event mesh does or why an event mesh is foundational to a large enterprise that has a wide diversity of applications that are homegrown and a small number off the shelf. I wish we were better able to tell the story in a cohesive way to multiple lines of business, but that's more of a statement of our own internal structure and how we absorb or adopt new technology than it is about Solace or the product itself. It been a bit of a tough slog to try and get everybody to see event meshes are foundational in a multi-data center, multicloud landscape, when we're not there yet. Our company has most of our applications in two data centers that are close to each other. There is no real geo-redundancy, but everything we've ever done has been on-prem with only a small handful of Azure adoptions. Therefore, having folks see the benefit of an event mesh has been tough. I wish we could improve our storytelling a little bit. We have struggled in a sort of perpetual PoC mode internally. This is no fault of Solace's. It's just that the only executive looking to benefit here is our technology operations team, and they have no money for investments. They're a cost center internally, so they have to be able to make the case that we're going to improve efficiency by leveraging this tech. Thus, the adoption has been slow.
Technology Lead at a pharma/biotech company with 10,001+ employees
Real User
2020-06-10T08:01:00Z
Jun 10, 2020
Another product that I use very much in my current portfolio is MuleSoft. It's an API management platform, and also iPass, which is Salesforce's company now. Both these products have to work together to give an assured-delivery type of middleware platform. We felt that having a connectivity layer or a connector or an adapter already pre-built in Solace for platforms like MuleSoft, Dell Boomi — middleware especially — would be pretty interesting. It would make it a more authentic and credible connector as well. Today, we have to rely on JMS or a REST-based protocol but we have raised this request with Solace. While connectivity is definitely easier, at the same time, Solace needs to work on some of the connectors for industry-leading applications like Salesforce, Workday — multiple typical distributed applications that we might have. It is pretty good at this point but they can do better on that. Also, a challenge we currently have is Solace's ability to integrate with single sign-on in our Active Directory and other single sign-on tools and platforms that any company would have. It's important for the platforms to work. Typically, they support only LDAP-based connectivity to our SQL Servers. We have one critical step, from an IT security point of view. If there are any SaaS applications or cloud applications which are hosted out of our cloud platform, then the only way that we can do SSO is through a SAML-based or another specific protocol. Solace doesn't support them at this point in time and we have raised this as a platform request. I think it is on their roadmap. But currently, it supports only LDAP. That is an improvement area for them.
Lead Manager at a manufacturing company with 10,001+ employees
Real User
2020-06-09T07:44:00Z
Jun 9, 2020
We have requested to be able to get into the payload to do dynamic topic hierarchy building. A current workaround is using the message's header, where the business data can be put into this header and can be used for a dynamic topic lookup. I want to see this in action when there are a couple of hundred cases live. E.g., how does it perform? From an administration perspective, ease of use etc.? The second challenge is about skills and not related to product directly. Resource availability can be a challenge, e.g. if we have a lot of use cases for this and insufficient manpower, which comes from our partner companies and other IT companies, that will slow us down. This is an area that if Solace could do something, it would be good. If they could add some training or certification, that will be good. From a product perspective, so far in journey, it looks okay but time only will tell once we have put lot of volume and use cases on it. The topic catalog was actually a gap in the product about a year and a half ago when we started. It was not available in the basic platform, and we said, "This will become a challenge." Now, they have recently launched the Event Catalog and event visualization, where you can do an impact assessment if you change something, e.g., you can see the whole visual of impact. If you are publishing an event, you can see who are the subscribers, etc. It does look good, but we are in a very early stage. Therefore, we want to see it in action for a broader base and more use cases, before we say, "Yes, from administration perspective, this makes sense."
PubSub+ Platform supports real-time shipment tracking, IT event management in multiclouds, and connects legacy and cloud-native systems for application modernization. It's utilized for trading, streaming market data, and app-to-app messaging, enhancing event-driven architectures with reliable message queuing.Organizations adopt PubSub+ to efficiently transport events across hybrid and cloud environments, managing audit trails and long processing tasks. The platform aids integration through...
The solution could be improved by enhancing the message pooling size for persistent messages to handle both small and large messages effectively. Additionally, providing a comprehensive dashboard to display metrics such as message throughput, connection rates, latency, and automated alerts would be highly beneficial.
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.
The integrations could improve in PubSub+ Event Broker.
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.
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.
It could be cheaper. It could also have easier usage. It is a brilliant product, but it is quite complex to use.
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.
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.
Some of the feature's gaps with some of the open-source vendors have been closed in a lot of ways. Being more agile and addressing those earlier could be an area for improvement. Obviously, their movement to cloud and integration is there. There's a need to keep investing in that area to make sure that there's feature parity with their competitors and have that seamless burst to the cloud available like all the vendors that are out there. But from our perspective, if they can keep that feature parity, there'll be little appetite to move.
We have various items on the docket with Solace. We've pointed out some things with the DMR piece, the event mesh, in edge cases where we could see a problem. Something like 99 percent of users wouldn't ever see this problem, but it has to do with if you get multiple bad clients sending data over a WAN, for example. That could then impact other clients. In our current state, we've architected around that with Solace. We can see, in the future, with the event mesh DMR, that there is potential for several bad clients to cause problems for other clients. We actually had a design session yesterday with the head of engineering where we started working on how to solve that 1 percent "corner case." We're working on the basis that if it can happen it will, even if it's very unlikely. We design for those kinds of days as opposed to, "Oh, this will never happen." It's really about multiple streams and guaranteed messaging between multiple regions over WAN potentially causing one user a problem. We're trying to solve for that kind of stuff. It's very specific, but that's just how we think. Being a financial organization that is obviously regulated, we can't afford downtime. So we try to look at everything through that lens.
The storytelling about the benefits needs improvement. We have four major lines of business in our company. Our retail, capital markets, and internal corporate center lines of business along with technology operations, which is more of a cost center. Technology operations are not innovators, but more a keep the lights on arm of the business. One of the areas of improvement would be if we could tell the story a bit better about what an event mesh does or why an event mesh is foundational to a large enterprise that has a wide diversity of applications that are homegrown and a small number off the shelf. I wish we were better able to tell the story in a cohesive way to multiple lines of business, but that's more of a statement of our own internal structure and how we absorb or adopt new technology than it is about Solace or the product itself. It been a bit of a tough slog to try and get everybody to see event meshes are foundational in a multi-data center, multicloud landscape, when we're not there yet. Our company has most of our applications in two data centers that are close to each other. There is no real geo-redundancy, but everything we've ever done has been on-prem with only a small handful of Azure adoptions. Therefore, having folks see the benefit of an event mesh has been tough. I wish we could improve our storytelling a little bit. We have struggled in a sort of perpetual PoC mode internally. This is no fault of Solace's. It's just that the only executive looking to benefit here is our technology operations team, and they have no money for investments. They're a cost center internally, so they have to be able to make the case that we're going to improve efficiency by leveraging this tech. Thus, the adoption has been slow.
Another product that I use very much in my current portfolio is MuleSoft. It's an API management platform, and also iPass, which is Salesforce's company now. Both these products have to work together to give an assured-delivery type of middleware platform. We felt that having a connectivity layer or a connector or an adapter already pre-built in Solace for platforms like MuleSoft, Dell Boomi — middleware especially — would be pretty interesting. It would make it a more authentic and credible connector as well. Today, we have to rely on JMS or a REST-based protocol but we have raised this request with Solace. While connectivity is definitely easier, at the same time, Solace needs to work on some of the connectors for industry-leading applications like Salesforce, Workday — multiple typical distributed applications that we might have. It is pretty good at this point but they can do better on that. Also, a challenge we currently have is Solace's ability to integrate with single sign-on in our Active Directory and other single sign-on tools and platforms that any company would have. It's important for the platforms to work. Typically, they support only LDAP-based connectivity to our SQL Servers. We have one critical step, from an IT security point of view. If there are any SaaS applications or cloud applications which are hosted out of our cloud platform, then the only way that we can do SSO is through a SAML-based or another specific protocol. Solace doesn't support them at this point in time and we have raised this as a platform request. I think it is on their roadmap. But currently, it supports only LDAP. That is an improvement area for them.
We have requested to be able to get into the payload to do dynamic topic hierarchy building. A current workaround is using the message's header, where the business data can be put into this header and can be used for a dynamic topic lookup. I want to see this in action when there are a couple of hundred cases live. E.g., how does it perform? From an administration perspective, ease of use etc.? The second challenge is about skills and not related to product directly. Resource availability can be a challenge, e.g. if we have a lot of use cases for this and insufficient manpower, which comes from our partner companies and other IT companies, that will slow us down. This is an area that if Solace could do something, it would be good. If they could add some training or certification, that will be good. From a product perspective, so far in journey, it looks okay but time only will tell once we have put lot of volume and use cases on it. The topic catalog was actually a gap in the product about a year and a half ago when we started. It was not available in the basic platform, and we said, "This will become a challenge." Now, they have recently launched the Event Catalog and event visualization, where you can do an impact assessment if you change something, e.g., you can see the whole visual of impact. If you are publishing an event, you can see who are the subscribers, etc. It does look good, but we are in a very early stage. Therefore, we want to see it in action for a broader base and more use cases, before we say, "Yes, from administration perspective, this makes sense."
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.