What is our primary use case?
One of our use cases at our global company went live recently. We have a lot of goods that move via sea routes. While there are other modes of transport, particularly for the sea route, we wanted to track our shipments, their location, and that type of information and generate some reports. Also, there are multiple applications which need this data.
With Solace, we are bringing information in every minute (almost real-time) from our logistic partners and putting it on Solace. Then, from Solace, the applications that want to consume the information can take it. E.g., we are generating some dashboards in Power BI using this information. We are also pushing this information into our data lakes where more reporting plus slicing and dicing is available. In future, if more subscribers want this information, they will also be able to take it.
We have both our private cloud and a version completely hosted on SaaS by Solace.
How has it helped my organization?
The base use case is that we wanted the shipment tracking information in multiple applications, like Power BI and data lake, for the more reporting, etc. If we would not have got Solace, then we need to extract this information multiple times from source application. Now, we pull this information only once and then put it on Solace. Anybody can take it from Solace because the information is readily available. We are generating the data only once.
Every organisation has exposure of their data with their devices being interconnected. We don't want to transfer the same data multiple times. Solutions like Solace can help us in publishing data only once, then anybody can pick it from there. This reduces costs of data transfer. It reduces the load on data sources, because we aren't asking them to generate the same data multiple times.
Our company is an SAP centred company. A lot of our key applications are using the SAP product suite. When we talk about transaction data and master data, that is where the real complexity comes into play. There are a couple of use cases that we have discussed with Solace for topic hierarchy. E.g., a product master might be sold by multiple channels, produced in multiple factories, and sold in multiple geographies, so creating a topic hierarchy for these could be challenging. When we started, we discussed this complexity with Solace. They helped us arrive at an initial topic hierarchy based on some similar use cases which have been implemented for other customers, sharing their insights.
Another point is their overall approach to topic building. They have very good documentation. It will be our own internal complexity that will drive the topic hierarchy. We are currently in the early stages, and so far journey has been good. Right now, we are comfortable with information and help we are getting from Solace along with the overall approach recommended for topic building. However, time will tell, especially after we generate very complex cases with Solace, how this topic hierarchy functions.
What is most valuable?
The most valuable thing for us is being able to publish a message, then have the ability to subscribe it on the fly. We want to democratize the usage of this going forward.
We are currently using the basic platform, and as we become more mature, I am particularly excited about using the Event Catalog. This was launched recently. There are certain features like event visualisation and event discovery which we want to see in action. It will take some time for us to make more events published on Solace.
The software has been very good because:
- You can spin off a Solace instance very quickly.
- Based on your requirements, there are various size levels, similar to t-shirt sizing.
- When we went to add another installation in our private cloud, it was easy. We received support from Solace and the installation was seamless with no issues.
After publishing, we have seen the solution’s topic filtering go into approximately six levels, which is quite granular. These many levels are good enough. Also, the business payload lookup is supported.
What needs improvement?
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."
For how long have I used the solution?
We have been using the solution close to a year. Our use case recently went live. Now, we are working on a couple more projects.
What do I think about the stability of the solution?
So far, we haven't seen any downtime or issues. We are in our initial journey, but we don't see any such challenges of instability at all. In fact, during the platform setup or during initial test cases, we never encountered any issues of services not working or downtime etc.
What do I think about the scalability of the solution?
As far as the SaaS solution is concerned, this solution is available in the t-shirt sizes. On the fly, it can be added to the existing subscription. Scalability should not be a challenge.
We keep on looking at our usage and approach. When we reach 70 percent usage, thats an indication of need of further scaling up. By the time we reach 85 or 90 percent, we would have already added capacity to your solution.
Our users are IT teams, not business users. Our use case originates from the supply chain, then the integration team manages Solace. We have around five to six IT users who interact with the platform to develop the solution. Once it has gone live, they support it in the production environment.
How are customer service and technical support?
The technical support helped us in all the aspects. So far, there are no complaints. We got really fantastic support from them. Their leadership is also very much committed. Their senior VP joins us in weekly review, which is the kind of commitment coming from them since their leadership is involved. Their technical teams are definitely involved and fully committed to our success.
A year and a half ago, the Event Portal was not available when we started our journey. This is a strong feature that they added based on feedback that they heard from us. This would not had been something that we could have requested with an open source, like Kafka. We would have had to outsource it to a partner for them to build it.
Which solution did I use previously and why did I switch?
Solace is a new product for us that changes the way we approach towards architecture. Solace is helping us to add some workarounds which will convert messages into event enabled messages. That is how we are using Solace right now. However, before this solution, we did not have anything.
How was the initial setup?
The initial setup was pretty straightforward.
The deployment took four to five weeks. When we got the first use case, we started understanding the requirements pretty well, then built the solution, did the testing, and made it live. After the solution is live, if anyone else needs data, that can be done very quickly. It won't take a couple weeks like first time. You can just connect, pull the data, and test it.
From implementation strategy perspective, we wanted a simple use case, e.g., just publish and subscribe. The easiest case could be a point-to-point where there is only one publisher and one subscriber. Things that are non-business critical, we wanted to put them first on Solace and see the performance, learn how they worked, their challenges, and dos and don'ts.
Later, we gradually wanted to move into business critical cases. The next set of our use cases, which are running on other middleware, we are trying replicating them on Solace. However, we will not be jumping to Solace directly. Rather, it is like a parallel solution, which is being built on the Solace layer. We want to see whether it is working fine. Gradually, we'll start switching from those scenarios which are running on other middleware to the Solace layer.
During this journey, we have also been targeting our topic building mechanism/approach, which will get firmly established. That is how we are approaching Solace overall. At the same time, we have also brought in our partners of other middleware - MuleSoft, Dell EMC, and SAP. These are some of our strategic partners. It is not just a big product which you take, then you forget. It's ability of that tool and how well it fits into your ecosystem as well. Solace can be a very good tool, but if other applications are not able to communicate with it, then it will be not of use to us. Therefore, we are also seeing that how Solace with Dell EMC, MuleSoft or SAP could create value for us. That's another thing which we are doing from a strategic perspective.
What about the implementation team?
The technical support partnered in creating the initial use cases and setting up the platform. Our IT team and infra network team from the back-end worked to install Solace on our private cloud.
When we did the first project, we worked with the Solace team. They were good people who helped us go into the smallest level of detail for the project requirements.
Our staff resources customize whatever work has to be done on the Solace piece. Once it goes live, they do regular monitoring. For a new onboarding project, we rely on these staff resources.
What was our ROI?
We have just started. The journey for us is new; we are not mature yet.
What's my experience with pricing, setup cost, and licensing?
Go for the best deal that you can get from Solace. Primarily, the licensing is dependent on the volume that is flowing. If you go for their support services, it will cost some more money, but I think it is worth it, especially if you are just starting your journey.
I don't think it makes any difference if somebody gives us a free version. That would be very small from a capacity perspective. For an enterprise organization that would not be sufficient, so we are not looking for freeware.
We are looking for something that will add value and be fit for purpose. Freeware is good if you want to try something quickly without putting in much money. However, as far as our decision is concerned, I don't think it helps. At the end of the day, if we are convinced that a capability is required, we will ask for the funding. Then, when the funding is available, we will go for an enterprise solution only.
Which other solutions did I evaluate?
Our journey to Solace was not very long. We started interacting with Solace leadership probably about a year and a half year back. That was the first time that we spoke with them about this concept and product. There were a few things that we asked for as part of product roadmap. Then, we moved to the product evaluation where we also brought in a couple of other competition tools. Finally, we selected Solace.
The challenge with open source is they give you a basic flavor, which is decent enough. However, when you look at enterprise level, you need the following:
- A good support mechanism available
- A distributed license, since there is talk about how to decentralize usage.
These are the challenges that come with an open source product. They do the basic thing well, but if you need to make the solution fit for purpose, you need to maintain the custom solution on your own. This becomes a problem from a resource and investment perspective, as technologies keep on changing.
If we talk about Solace, you see the value-add layer. I can say that Solace is a basic Kafka. But on top of that Kafka layer, they have added their own layer. That is really good, as this is where it adds value and why we went for it.
There are a lot of good things that made us decide to go for Solace. Looking at Kafka, the value-added monitoring, Event Catalogs, and visualization are not there. When we talk about Solace's competitors on certain aspects, we rank them a little lower. Overall, when ranking them, Solace was the one who has scored highest, so we went for it.
We do not use other competitor products, so we don't have direct experience with their ease of design. We also evaluated:
- A Microsoft solution: This solution was the closest to Solace.
- Kafka (open source)
- Also, two data stream solutions for high volume data.
The challenge with Kafka is you have to think of everything on your own. You have to build the complete service part of the solution on Kafka. Solace compared to Kafka was a no-brainer. Solace distinguished itself with topic building and scalabilty. When in cloud, you can quickly scale up.
With Kafka, the challenge comes when you design a solution that has topic management. How do you make a topic discoverable? How do you define the dependencies between one topic and a subscriber?
From a monitoring perspective, I also feel Solace has a better product. More than that, there are commitments which comes from the Solace product, such as improvements. They are open to hear what we were saying. If there are certain things which are not available, they said that they will try to plug those gaps.
What other advice do I have?
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).
Which deployment model are you using for this solution?
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)