What is our primary use case?
We are mainly using it for triggering data jobs. It does a lot of ITIL stuff and data movement from systems into Hadoop. We use it because it has the capability of dependency triggering or dependency running. That's the main idea behind it. Also, it helps us to centralize and organize jobs across the organization.
We use Tidal to run Hadoop backup system, SAP HANA, and SAP BusinessObjects. We also trigger a lot of jobs into SnapLogic, Salesforce, ServiceNow, Workday, and Tableau, along with a couple of dashboards. We run a couple of batches from our Unix and Windows machines: the stuff that the developers are working on and want to run in ITIL. But, SAP is the main thing.
The main goal is to use Tidal for managing and monitoring cross-platform, cross-application workloads. The ability to manage those loads is what they do well. I can put a job to run in SAP, and once the job ends successfully, I can run that job in Hadoop. Or, I can run that job in Salesforce.
How has it helped my organization?
Tidal enables admins and users to see the information relevant to them. We have something like 50 different teams working on our Tidal platform. We segregate between them using work groups. When a user logs into Tidal, they only see what they have permission for, not other projects. Data engineers are the users of this solution.
A user who comes into Tidal, develops his job, and creates their job in Tidal, then triggers the job or sets up a schedule. An admin is someone who keeps the lights on, making sure the platform is up and running. They maintain the solution and configure it, doing upgrades.
If I just want to monitor my job, that is something that the solution does really well because there is some constant job activity that you can login and see what has happened every day and every minute. That is pretty good. An admin can drill down to processes and data, but I don't think they are doing that.
The solution has helped to eliminate weekend hours. In the past, we had to schedule a job every Saturday. Then, someone had to login and run the job. Now, Tidal has the capability of event-driven jobs. For example, if a job is failing, we can do something. Or, if a job is completed abnormally, we can rerun the job. So, all of these features that they offer help us not to come into the office on a Saturday. We don't need to have a human person do those weekend activities and treat them. They also thought a lot of about outages in the product. You can set up an outage to an adapter or connection, to say, "Between these hours on the weekend, I don't want to trigger any jobs." That works very well.
What is most valuable?
The job dependency is something that you cannot have in a regular, simple cron job or simple scheduler dependency. The event-driven jobs are core for us, as we really need that. Therefore, we really need Tidal with its ability to run thousands of jobs per day.
What needs improvement?
We started to deploy Azure, and it's still not fully baked. We are struggling with it. It is not something that has worked out-of-the-box. We haven't installed Tidal in the public or private cloud. We have a problem with security. While we can install the entire platform in the cloud to handle separate work or an entity, if we want to centralize it, then it's a little difficult.
They don't have good reporting capabilities. From the user perspective, I have 6,000 jobs running per day, and I would like to track them to know exactly what is going on. E.g. if a manager asks me, "Can you bring me this data or can you do a dashboard or report?" I need to take a lot of actions in order to do that. It's not easy to compute that data.
We are now testing version 6.5. The speed of this console is much better than 6.2, where the speed has not been sufficient for me.
Most of my users are doing customer service review these days. So, we are asking the customers what they think about Tidal and what the vendor needs to improve. The number one that we are exploring is the user experience (UX). It has a lot of features, which is one thing that is great. On the other hand, the user experience is a bit old. It is hard to find what you're looking for. The UX is not intuitive for all users. So, if I'm a user, it might take me some time to know where I need to find my stuff.
It takes a lot of time to learn the product. I have admins and developers who are working on the products for the last three to four years and still don't know all the functionalities. Tidal has really great things about it, but people are focused on their day-to-day job and the solution is not intuitive.
We have internal training where we do two weeks of training for three hours each day. So it's approximately 30 hours of training. I cannot say after that users know everything. It takes about six months to ramp up on Tidal to be really good and professional.
For how long have I used the solution?
I have been using it for the last three years.
What do I think about the stability of the solution?
In version 6.5, it is very stable and works quickly. The UI works quickly too. Their services load pretty fast. If one of the servers reboot, they have a layout of the high availability. This means that from each component of the product you have two items. If one of them goes down, then the other one kicks in and starts to work. I really like that idea.
In terms of room for improvement, if one of the master goes down, then another one takes a minute to start. While it is not a big deal, when you commit on four nines, one minute is huge. So, I'm pushing the vendor all the time to be better on this.
They still haven't implemented the load balancing-oriented thinking. So, if I have two client managers, I cannot put them behind a load balancer. Or, I can put them there, but the load balancer will never have a health check. That is something that everyone is doing, building health checks, and they don't have health checks on clients for load balancing. Maybe this will come in the future. I submitted a request for having a health check for load balancers.
In version 6.2, they had a lot of problems. One of the problems is the Oracle support. We are using Oracle RAC and high availability on Oracle. If one of the databases would suddenly goes down, the entire system would crash. In version 6.5, we have tested this. They have done significant work and it's working perfectly. It's not crashing and working continuously without any issues. From this perspective, I am very happy with the new version.
What do I think about the scalability of the solution?
If you have enough memory, it is scalable. We are running 20,000 jobs. We just increased our memory. It scales really well.
How are customer service and technical support?
The North American technical support is very good. They go the extra mile for you all the time, and we are very happy them. We have had some problem in the past with the Asian support during IST time, while it is night in the North America. However, I think it's getting better. Overall, I'm very happy.
Which solution did I use previously and why did I switch?
We used local solutions, like scheduling for each platform, such as SAP Scheduler, SnapLogic scheduler, and cron jobs. We didn't have a centralized place.
How was the initial setup?
I was the architect of the initial setup. The initial setup was complex; it's not easy. They have a lot of settings and configuration that need to be done. There are a lot of small things that vary from environment to environment, and they fail to consider every situation.
The deployment takes a couple of days.
With our first environment, we tested it in a sandbox. I let my admin play with it to see how it behaved and what are the downsides. Then, we created a document. While I know that they have a document for installation, every time that we go to install, we are finding new issues.
I'm behind a firewall and we are in a limited environment. Our infrastructure is built differently from what they probably tested on their environment. So, it's a bit different from what I need to install. I first put it on the sandbox to see all the issues that we are facing, document step-by-step what we did, and then I go and do it in stage. Now, stage is the place where the developer come in and develop their jobs. Once they are ready, we move the jobs into production.
Stage is really almost production. If stage wasn't available, then the developer could not work nor deliver. We see if it works for at least three weeks. If we don't have issues during that time, then we deploy to production.
They do a better job in version 6.5, which we are testing now.
What was our ROI?
We have seen return on investment.
What's my experience with pricing, setup cost, and licensing?
BMC is really expensive. The other solutions are about the same price. I think Tidal is even cheaper than the others, such as CA, Stonebranch, and JAMS.
Our licensing model for Tidal is on an annual basis. It is very good and works well for us. Tidal's licensing is very transparent and simple. It lets you know, for the amount you use, that's the price that you pay. So, we buy X number of licenses, and we know that this is where we are. I'm very happy with that. I saw the licensing modules on other platforms, and I didn't like them. Other companies and solutions would calculate the connections, adapters, and instances. I think that's the reason that BMC was pretty expensive: They just didn't understand what our needs are.
The solution has no hidden costs. It helps me to plan forward into the future. I know that I can add another 100 or a thousand jobs, and that's how much it will cost me today.
Which other solutions did I evaluate?
We did evaluate other schedulers. This was the best solution.
I was not the one who selected it in the first place. I was the one who asked to evaluate a replacement at some point. There was a time when Cisco was the owner and we felt like Cisco was not delivering the product like we wanted. We sought to move to a new solution and assessed different solutions: BMC, CA, Stonebranch, and JAMS. We installed all of them, running all our tests. It took us six months to do our evaluation. Eventually, we found out that they are very similar from the infrastructure side. I could not see any advantage using the other solutions.
We discovered that we are good with Tidal and what we have. Then, a new company acquired Tidal from Cisco and they promised a lot of things to be better. We felt that the solution was going to a better place. So, we decided to wait and see how much they invest on the stability. We have been happy with the results. They are really focused on the customer and our pain. They are trying to remediate everything that we have issues with. Therefore, we decided to stay with them for now.
What other advice do I have?
Don't be afraid. Just do it. You will enjoy the features of it. It is a great tool.
You need to test Tidal many times. It's not straightforward. You need to test and learn it.
We have something that is not unique to many platforms. I have five guys who handle the platform. That's costly for us. We would like to see the platform more automated or straightforward. I would like to not need to hire so many people just to administrate and maintain the platform.
Our capacity has increased in terms of the number of jobs and integrations, but that is a natural thing. I don't think it's related to the solution. When you start to develop jobs, then year by year the number of jobs grow because the organization is growing.
I'm very happy with the product, but it's not a fully baked product. It requires babysitting. I have worked on other solutions and know what is there. This takes time for us to install, upgrade, and task because there are so many components to the product. If you do one little mistake, then you can screw the system.
I would rate the solution as an eight (out of 10).
Which deployment model are you using for this solution?
On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.