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.

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.

Make it open source :-) with limited features so that this is not a barrier for using the technology in some places where they will only use open source technology despite then just paying for support (and paid features) on any used open source technology in the organization, as its a misnomer in my view the amount of large companies claiming to only use open source but then using products that are paid versions with additional features included. Solace should give this further thought how they can address this. 

Feature-wise, it has almost everything that I can ask from an architect's point of view. 

For improvements, I would suggest increasing the max payload size to a limit of 100MB or more. The current max payload size is limited to 5MB. 

"Events" are supposed to be small in size, yet, as the name suggests for "broker", a broker should be capable of handling large payloads as well. Even Confluent Kafka provides bigger payload size support for enterprise usage licenses. 

The integrations could improve in PubSub+ Event Broker.

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.

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.

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

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

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. 

The licensing and the cost are the major pitfalls.

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 product should allow third-party agents to be installed. Currently, it is quite proprietary. It doesn't allow third-party agents to be installed.

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.