What is our primary use case?
We're a capital markets organization, so we primarily use it for our trading algos order management, streaming market data, and general application messaging. Those are our key use cases.
Our other use cases are for more guaranteed messaging-type or things where we absolutely need to have the resiliency of every message for higher performance streaming market data, meaning, millisecond latency-sensitive algorithm operations that are running as well.
We also use it for general messaging and to displace some of our legacy messaging applications such as MQ, EMS, and things of that sort. We are standardized on Solace PubSub+; it's an architectural standard at our company.
How has it helped my organization?
Our standpoint is, Solace has been tremendously successful in allowing for businesses and cross-business synchronization to be able to share data across application teams and across business verticals. It's been the success and the uptime stats that Solace has been able to provide that have allowed for more and more users to use the system.
Going from something where we had outages and capacity issues constantly to a system that was able to scale with the massive market data and messaging spikes that happened during the initial stages of the COVID crisis in March, we were able to scale with 40-plus percent growth in our platform over the course of days. We never had any outages and never had any issues despite those massive spikes. The system was able to cope. There are things that we needed to do and work off to make sure we had headroom and then we were able to scale out, but we can do that seamlessly without our users even knowing.
It has increased application design productivity compared with competitive or open-source alternatives. From my pursuit of the "secret sauce", I found that Solace really is, for us, the service and the partnership that we have with the company. Having the level of expertise and the subject matter knowledge available to us is second to none. It's not just that Solace is entrenched at my company, is the standard, and it would be too hard to roll off. It's more that the level of performance and the level of service we get from Solace precludes that. I'm looking at where other vendors are and I just can't see them getting to the level that Solace is at for us, to really make an impact. Again, there's a small use case here and there where potentially it could be of use, but for the most part, it's not something that's going to get too much traction, given the success of the platform currently.
What is most valuable?
Performance and stability were a absolutely key areas for us. Having a rock-solid appliance-based architecture with the support that goes behind it from Solace is the most valuable aspect of this solution. From our perspective, it's the background of Solace as certain network devices that have very low error. Tolerances are key for us. What separated them from other vendors, at least initially, was that the appliance option versus the commodity hardware was definitely a very important distinction for us. From a management standpoint being able to have a system, we can manage internally, and have access to keep that within our engineering group is key. We isolate it from our standard infrastructure and commodity hardware group.
If we had to deploy to a messaging platform that uses commodity hardware or converged infrastructure, the costs would be much higher for us, especially due to the certain internal cost. The appliance-based architecture is, at least initially, absolutely a big advantage for Solace. And on the other side, the support that we experienced with Solace as a company has been very positive.
Our background is primarily on the market data side where we deal with a lot of different vendors from Reuters, Bloomberg, very big systems as well as vendor appliance hardware. The support we receive from Solace is by far much better. It is the top of the market. The level of expertise in troubleshooting or identifying issues is absolutely key.
Our messaging platform is the largest thing on our internal network, as the last messaging spike was close to 10 billion messages a day. We're very large consumers on the network. We need to have key exposure to everything that's going on within our platform. And when we do need to get Solace on the line, they know more than our network team does about troubleshooting; where our constraints are in the system and what's going on. I think those are the key advantages for us. Solace support is the best that I've experienced amongst any of the vendors that I deal with. The competitors I am referring to are TIBCO, Kafka, MQ, and EMS. They are messaging platforms that are on the ultra-low latency side, like Dell. We have various small installations and pockets of those various technologies everywhere, but compared to other vendors and database companies, Solace's response time is better. The depth of knowledge and the consistency of knowledge are far and away better than any other vendor partner that we deal with.
In terms of the ease of management, we have a very large deployment. We've globally deployed dozens of appliances in various data centers across North America, Europe, and Asia Pacific. Being able to manage that, we do require an organized team, good infrastructure, and support structure. Solace, as a partner, helped us in the initial installation to get to the point of doing the leg work and initial analysis to give us space to be successful with our deployment. It's a complex messaging platform. It is not a simple thing to do, but the tools and the support you get from Solace definitely enable you to be successful with that installation.
The topic hierarchy in terms of how dynamic and flexible it is is one of the initial definite benefits of Solace compared to other legacy systems. The ease of doing in-service upgrades and in-service deployments without affecting the environment was less key, coming from more legacy platforms where deploying any new topics, topic structures, and publishing structures wouldn't be allowed. It would force you to do system-wide restarts and involve every user on the platform. Whereas, with Solace being able to not only deploy up-to-date changes without any issues but being able to do so without impacting clients is an advantage. Similarly, upgrades and patches and things of that sort are much more seamless compared to the legacy systems that we supported in the past. Reuters to EMS were the systems that were displaced by Solace.
In terms of the granularity of the topic filtering feature, Solace was heavily involved from a professional services standpoint to help us define our topic structure and our topic hierarchy with ourselves and our architects for the initial deployment, being able to get that structure and helping define that structure. Only recently did we make some structural updates to enable more agile, cross-business sharing. But for the most part, it's been a very successful deployment of the topic hierarchy. It is flexible enough to allow us to use subscriptions and publishers. We have a strong process to make sure that folks are conforming to those topic structure formats but Solace was involved in the development of that structure initially and we have been pretty successful with it.
We do have Kafka deployed to serve some use cases in capital markets. We've evaluated it and continue to evaluate it. But from our perspective, the performance and scale that we have in Solace preclude a large scale deployment. It's also a platform that requires a significant commodity hardware installation along with that we are always going to be licensed while we use open source software and platforms. We always make sure that we're fully licensed from the support perspective. From a regulatory and risk perspective, it's something we always operate. It doesn't make a lot of sense to move there, also, given the layer of investment and performance that we have currently. In cases where certain vendors have out-of-the-box plugins with Kafka, we build connectors to allow them to publish onto our platform and that's worked seamlessly for us.
What needs improvement?
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.
For how long have I used the solution?
We have been using Solace since 2012 or 2010. We've had them for quite some time so it has gone through multiple interfaces and many iterations of product names but we're using direct event messaging, Solace caching, their VMR, or the other PubSub+. We use all of their products that I can think of, so we have had a pretty large installation of Solace for quite some time.
We're primarily on-prem. As we're a bank, the biggest installation is for some privacy concerns, but we have primarily deployed appliances. With some of the Event Broker software and some of the virtual appliances, the majority are for them in that regard. We have deployed both in internal data centers, as well as colo data centers for connecting us to certain trading and market use cases.
How was the initial setup?
We started the deployment in the fall. The bulk of the fixed income use cases was rolled out within around three months for the initial use case. At that point, to fully migrate every last legacy publisher over, probably took another year or two, but that's really not on the vendor side. It's more that application teams and legacy systems are slow to move away, but we were able to fully remove every trip publisher, EMS publisher, and few publisher with capital markets and were able to fully migrate over to Solace.
We have roughly 200-plus applications across capital markets and over 1,000 client end-user subscribers. That doesn't even count the clients on the application side as well. Our large applications have a billion messages across our global architecture.
What was our ROI?
ROI would be hard to calculate but just talking from a storage perspective, we've been able to use Solace storage appliances. We've been able to say that would have cost around $2 million a year in storage costs to half that amount as an initial investment. We've been able to pay that business casework off in year one, whereas three years would be perfectly acceptable from a cost-savings perspective. And that's just on the storage side. We can pay up to $10,000 and $20,000 a year for internal charges per server versus just paying for rack space costs for our infrastructure. It's a significant amount when you consider that often you'll need many commodity hardware servers to replace a single appliance pair. It's a significant cost saving.
What's my experience with pricing, setup cost, and licensing?
In terms of pricing, you need to take into account the internal infrastructure chargebacks, monitoring, and service chargebacks that you get from using your internal hardware versus what you get by deploying via an appliance. In many cases, the cost is your service costs for having your infrastructure manage your underlying hardware, and the monitoring and service costs can quickly spin costs. Storage can spin costs to be much, much higher. Whereas, sitting on an appliance-based software where you can manage that internally within your own engineering team, has been much more cost-effective for us. The amount of internal chargebacks we've been able to avoid is significant.
It's really the reason we're able to pseudo have a cloud-based costing model by using appliances, which is fine. Everyone's going cloud. It's a cost-play as well as an agility play, but we get that cost play by using the Solace appliance model on our side. I think many people that deal with similar large infrastructure teams are trying to get the same sort of process.
What other advice do I have?
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.
Which deployment model are you using for this solution?