We split users primarily into four roles. The viewers can't do anything other than see what's happened. There are also operators, which are people that can rerun jobs, yet can't modify anything. They're a little bit ahead of a viewer. Then you go into being a developer, which can write jobs in non-production. Finally, my admin team uses it. They keep it all running. The fattest part of the bell curve, the biggest user there is, is the developers. Overall, we're between 1200 and 1500 users. The admin team is six people, and the developers are about 800 of them.

We're worldwide. Unless we get some off-world friends to introduce themselves, I don't have a lot more room for expansion. What we're seeing now is people wanting to stand up more masters for more autonomy. I see us expanding into China, which is going to be a pretty nifty little trick since there are a lot of restrictions on communications there. That's about the only expansion I see for us. Obviously, there is increased job usage. However, in terms of expanding the footprint of the platform, that's only in geographic regions.

Tidal's scalability has met all of our needs up to this point. We're not on all 16,000 servers, because we don't need to do processing on some of them. But we're probably around the 5,000-server mark with no issues at all.

The product continues to grow. We haven't adopted a lot of the new functionality that it has offered, because we're very comfortable with the way we do things and we make it work with what we know. Most of our applications are internally built, so we're not using SAP.

I've been impressed with the scalability so far. In terms of the number of E1 systems that I connect to a single Tidal instance, I'm probably in the top 10. I don't think anybody else sets it up quite like this. It has been very flexible. I've been happy with the results that we've gotten.

It is deployed across eight different JD Edwards instances. They are separate JD Edwards systems. There are not a lot of people getting on it, but we do have a lot of reports being generated out of it.

The scalability is pretty good. We've used Tidal only for our main application which is our health and welfare system. We do a lot of reports and off of that, but we don't use it in any other areas. 

We've never scaled it extensively across too many different platforms. The only thing we have right now is a SQL Server platform and an Oracle Database that we go against. We're only in one location.

I don't see us expanding our use of it for now. We're pretty stable.

There are close to 10 other teams using Tidal, and I'm not sure how extensively they are using it as of now. People login to Tidal when they need to check the status of their jobs. When it comes to developers, there are close to 20 users. We do have business folks who use Tidal when they just want to monitor or operate their jobs.

We are still expanding day by day. We do get requests to create new jobs, and the developers will take care of those. We receive those requests once in a while. We are still expanding but it will not be a drastic increase.

We've two data centers and about 20 users, 1,500 jobs, and 100 servers. That's pretty much the environment. We've development, testing, and production with the high availability feature from Tidal.

We've scaled up a lot in a short time, and it doesn't even matter. There is no limit. You could scale up to however many servers you need to, or however many jobs you need to. They don't care if you're running 10,000 a day or 500. It works just as well. You could scale up as much as you need to.

We're a medium-sized company at 11,000 jobs and we're using just one instance for that. My understanding is that it can scale out to hundreds of thousands of jobs, depending on how you implement it. We're in a good space and we would be able to scale out if we needed to. I don't see us needing to, but my understanding is that there are companies that use it on a much larger scale.

Over the years, they have built out connections to different types of systems that they didn't originally support. Azure Data Factory is new in the last eight years, and that means that Tidal didn't always need a connection to that system. They build out those types of connections and they work to stay current and to work with the applications that are out there. I see them striving to stay relevant, in a good way.

Tidal does a nice job of continuing to educate its customers on their solutions and what they're modifying or doing to provide new features. They have quarterly webinars that are very informative. I also find that our customer service rep is very informative. If I have a need for a demo of something that is new, I can reach out, get it scheduled, and they'll do a demo for it.

We have the solution deployed in a single data center where we have our production environment. We also have it in separate QA and dev environments. We connect to about 18 applications across our enterprise. Our total number of users is about 150, but on a weekly basis there are 20 to 30 people who use it heavily, people who are always in the system doing things.

Tidal does a good job. We periodically have them do a performance review every six to nine months by sending them our logs. I open a ticket, then send them a bunch of logs. They take a look at them and we do any necessary tuning. We have discovered over the years, going from a small to medium to high-medium organization, that Tidal is very responsive in terms of helping us figure out how to tune systems so we have the best performance. It can handle very large scale organizations job-wise. It is just how you tune your servers, and they're very willing to help with that. The best thing that a person can do is work with Tidal support to find out exactly what is necessary on the back-end to have their system scaled out correctly. It can be done. We run about 8,000 jobs in production, but I know there are some systems which run tens of thousands of jobs of production. We haven't hit a scalability issue at all.

Regularly, 20 to 30 people use it in our organization on a week by week basis. We have about 100 users in the system. Their roles are developing, creating jobs, QA, testing job scenarios, events, and actions; everything around developing a job or job stream. Then, we have our service desk people who do the transports from QA into production. There are about four people who do this.

In production, people from each scheduling team are responsible for the health of their jobs, which can include if there are issues with the jobs running, maintenance that they have planned, setting those jobs on hold, asking me to put an outage on an adapter, rerunning jobs, or disabling/enabling jobs. It is general job development and job management.

Scaling is easy. You could run these in VMS. We happen to have physical boxes. 

We haven't scaled it out, such as creating a remote master. In instances where we thought we may have to kick off jobs from our Maryland data center or jobs in our Denver data center, over MPLS, we thought we would have issues but we didn't have any issues. We were fine. We've been able to run things centrally.

The databases scale the way SQL scales, either by giving it more memory or more CPU.

As we have brought on clients we've grown over the years. We have a tendency to overbuy for the Client Managers. Our Client Managers are coming up on four years now. In 2021 we'll likely do a tech refresh. We'll stand it up with another version of Tidal and we'll do the migration onto the new platform. At that time we'll look at scaling up the boxes a little bit. You can put a lot more workload, a lot more Tidal jobs, on these without having to increase CPU or memory.

The scalability is fine for us.

I find the software very useful and solved most of the problems on my team. I believe Tidal will be a great competition to other automation software out there.

I don't think we've ever pushed a limit of the schedulers, the masters. We haven't really had any kind of scalability issue with regard to the scheduler or the agents. The only thing that we've run into as far as scalability goes would maybe be the web interface, which can get pretty slow at times, so we've got to cycle it. The web client is just sluggish and has an issue where that performance degrades over time. That's why we do the recycle and we notice it helps quite a bit to recover it.

We don't have it open to our users and don't actually see a need to do that at this point.

The system administrator is the regular user of the solution. They do the maintenance of the solution, if needed.

We have jobs that run every 2 minutes all throughout the day as well as hourly jobs that run.

The scalability has been very strong. We haven't been able to hit any limits. I feel like with this technology the speed of systems and networks increases, and what might've been a problem 10 years ago, is not a problem now.

The role of the end user depends on the team, but some of them can create their own jobs. In other cases, they will give us the specifics and another team will create the jobs for them. So, it depends on how involved your team wants to be. We'll give anybody read access, so they can see the output of their jobs, for example. But other teams, who have a little more knowledge, might give more access where they could rerun or create their own jobs.

I don't know about specific plans to increase it other than bringing in those cron jobs which are not using it.

We have to make minimal efforts to scale Tidal Automation. Its scalability is an eight or nine out of ten.

It has good scope for scalability. Scaling is possible with this Tidal tool.

We have had no scalability complaints. It is all pretty straightforward.

We're looking at rolling this out a bit more globally. We have some people in India, North America, and elsewhere. The rate that the skills get picked up can depend on the region, but it also depends on the skill sets that you already have. If you already have some knowledge of an automation tool or orchestration tools, then it's quite intuitive. However, if you have somebody who has never seen it before with no knowledge on the information system, then it might take them a bit longer.

We have about 100 DBAs, testers, business analysts, and automation developers using it. At one point, we had nine live environments.

We haven't hit any roadblocks with volume, but I think we've been sized properly too, behind the scenes, with each upgrade that we've done. It's been scaling fine. That's the bottom line.

There are systems out there that are larger than ours. We try to get to the user conference, here in Boston once a year, to do some comparisons to other organizations and the way they're using the tools. It's an information-sharing session.

Whenever we go for an upgrade, we look for an assessment of whether we need to provide more horsepower or not. If any of the configuration has to change, we watch that carefully with each upgrade. There's a formula that Tidal provides on whether you should have a small, medium, or large installation, based on the number of definitions that you have. They help with calibrating that.

We consider Tidal to be an enterprise scheduling application, so any new process that comes along is first looked at to see if it can be run from Tidal, whether that would involve purchasing another adapter or whatever else would make it work from here. We want it to be an automated function as opposed to being run manually and not integrated with the scheduler.

If you have enough memory, it is scalable. We are running 20,000 jobs. We just increased our memory. It scales really well. 

Our usage of Tidal goes up every year. That's not even from planning to increase usage. We have a few holdouts, people who still use Task Scheduler or cron, but over time they've all been folding into the Tidal space to have a better overview and a cross-platform way to see everything and rerun everything and be alerted. They've come to the conclusion that it's a better method, especially for overnight. We have an operations team that manages things overnight, so that if something fails in the middle of the night, that team can handle it, which they would not be able to do if it wasn't in Tidal, along with thousands of other jobs.

In terms of the number of jobs in Tidal, it's been increasing at between 10 and 20 percent a year. It's going up. It's definitely not going down. Initially, it was probably 50 percent a year because everyone was adopting it. Over the past five years, since it was already utilized by everyone, there has been a general 10 percent a year increase because of new jobs that need to be created and new processes that need to be started and stopped.

We're somewhere around 95 percent in terms of adoption of Tidal. There a few small groups that like to do their own thing and use open-source products, but those are groups that maybe only run Unix and that's it. They're happy with Jenkins or something open-source that only needs to run a few hundred jobs. It's only one platform, and it does what they need to do a little bit better than Tidal. But for groups that need an all-in-one solution, they've all gone to Tidal. If they need to do what Tidal offers, they're going through Tidal to do so. It's pretty accepted here.

It is scalable. It has many features that other tools do not provide. It is very convenient to use and we can scale it up.

Tidal has been widely promoted in our company and we are getting multiple requests to onboard teams into Tidal. They are exploring it and giving us feedback. We pass the feedback to Tidal and then they provide us with enhancements. Our job counts are increasing, day by day.

We have 500 to 600 people using Tidal in our environment.

From what I've seen, the scalability is very good. There are companies that I know that run millions of jobs a day. I've been through some user groups that have some people running nine different instances of Tidal, and they're running a lot of different things. So, the 7.7 million a year we run here, coming from where I was beforehand where we were running about 400,000 a year, seems like a lot. But we're still a small fish in the barrel compared to how other Tidal customers are using it.

So the scalability is phenomenal. We're always looking for that next hook and working on trying to tie into other things. We're keeping our versions updated as much as we can, in regard to OS compatibility. Take Informatica, as an example: We're making sure that we're as up-to-date as we can be with the versions that are out on the market.

You can scale. Today, you can easily scale Client Manager, which controls access to the web client. I sometimes complain about this to Tidal. For example, you can add one or two to the HA, which has a master backup. However, the only way you can scale there is vertically. So, you can make the system bigger. But with the Client Manager, you can scale horizontally as much as you like depending on the volume of people that you have, though I usually find that for us one Client Manager works just fine. The reason we have it down to just one Client Manager is because they use the Java clients, so there are different ways of getting to the system. It would be a good idea to have a second Client Manager in place so you have HA if the Client Manager goes down, then you could just go to the other one.

We haven't really had an enormous increase of jobs that has caused us to scale drastically, short of increasing memory. The CPU has not been an issue at all.

We did expand it to non-SAP, but it's not huge yet. It is being expanded to things like running Windows and Unix jobs. There are a good number of jobs that it runs from a volume perspective, but not as much as SAP.

Most people use the web client. There are 40 to 50 active users in the system. What we call super users use the Java client, so there are five to 10 people now using the Java client with the rest of the people using the web client. 

We have three different types of users: 

1. We have the administrative team. Those are the people who maintain the system, do the training, and set up different components of the application layer, such as user groups or server groups. This is more on the technical side. 
2. The super users usually are the most knowledgeable and capable of using some of the more complex features of the product. 
3. The regular users are the people who set up regular, simple, straightforward jobs with some dependencies. They maybe set up some calendars, but nothing overly complicated.

It's very scalable. As the company grows you increase the resources. I've worked at a small company that has Tidal and I'm now working at a pretty big company that uses Tidal and it all works pretty seamlessly.

It's pretty extensively used in our company. We have 25,000 jobs in production, and we keep growing. We keep adding jobs.

We have about eight engineers who create jobs and we have about 10 people who are operators who monitor the production schedule. And we have 200 to 300 other users who are developers. They create code that integrates with Tidal and they work with the engineers to create the jobs in Tidal. They access Tidal to view and check their jobs.

We have an architect and two admins to keep the environments up and running. We have the eight engineers who create, monitor, and edit the jobs and the general environment. They are on-call as well. That's the core team for Tidal. And the NOC manages alerts if something happens, to reach out to the on-call people

Around eight users are using the solution in our organization.

I rate Tidal Automation by Redwood a nine out of ten for scalability.

We have thousands of jobs that are scheduled in a batch and run using this tool. It is scalable, and there are a few hundred users.

Our usage may increase to some extent but maybe not because there are competing forces.