The solution is scalable up to a point. There are some issues at the enterprise level. 

The scalability is excellent.

Four guys use it on the Unix team.

I rate the solution’s scalability a ten out of ten.

Scalability is not a requirement for this solution because it's a configuration management tool.

Scalability-wise, I rate the solution a nine out of ten.

I am a user so am not familiar with scalability. Another team handles the platform and its scalability. 

Around 10 users use the solution in our organization, a presales and sales company. Around 1,000 users used the solution in my previous organization.

I rate Red Hat Ansible Automation Platform a nine out of ten for scalability.

Red Hat Ansible Automation Platform is a scalable solution. Around 300 to 400 users are using the solution in our organization.

It's a scalable solution. The capacity of the single instance is quite enough to hold up an enterprise. From a resilience perspective, you have to have a cluster that actually holds the whole thing.

On a scale from one to ten, I'd rate scalability at seven.

I think it will meet our needs going forward. We're going to put, not a whole lot of servers, just 3,000 servers, and that's going to be spread out. We're going to do an HA Tower. Right now, we're only doing 350 servers for our trial runs. We haven't had any problems with that, we just keep them all up at once.

I rate the solution's scalability a nine out of ten. We have two customers using the solution.

It is a scalable solution and is based on your node license. We are using more than 400 servers right now, and it requires one senior system engineer for maintenance and deployment. We plan to increase the usage using Windows automation.

It's quite scalable. I don't think there are huge limits in terms of what you can do. I have not run any performance benchmarks for Ansible. I don't know how long it would take to upgrade 10,000 nodes compared to competitors. But I feel Ansible could be nicely scalable. An orchestrator would allow you to simply have Ansible containers, perhaps on Kubernetes, and they would run something against the nodes. Having multiple Ansible nodes, or multiple pods of Ansible containers, running code against targets in parallel, would be a scenario in which I could hardly imagine any limits.

We are managing between 1,000 to 2,000 servers.

My team is more of a development team, so we don't run Ansible on a daily basis for operations. We mostly program or develop robots that run Ansible when needed. As for other teams, I'm not sure how they use it, but whenever they need to collect something from these hosts or need to quickly push a similar update to all hosts, I think they would use Ansible. While it's not being used on a daily basis in our organization, it's certainly being used.

It is a scalable solution.

The product is scalable. We can use it on multiple cluster levels.

The solution is scalable and you can go from 100 to 3,000 users with no issues. 

The solution can scale. It can cover large amounts. Many other companies also use it successfully.

We have more than 600 Linux servers. We are using it on all the servers. 

Ansible is a configuration tool that doesn't have to scale like other tools. So scalability does not apply to the solution. Also, it's not a tool used by thousands of users. I am unsure if it can be used to manage thousands of servers. Small teams, like the DevOps team, use the solution. We service large groups of servers with it using a very small team of about two or three and a maximum of four people.

It is scalable. We just add more nodes if we need them.

It is used at multiple locations and in multiple departments, and our end users have multiple operating systems. There are probably over a hundred thousand users. We're going to put some more nodes in at some point in the future.

It is scalable. You just need to know the IP address of the new operating system with which you are going to interact. You just need to enter credentials into Ansible inventory. You have to make entries to this inventory, and you are good to go. You can use the same configuration that you have been using in your previous host.

The solution has high scalability. It can be deployed on thousands of machines. Seven people in our organization use the solution.

It's very scalable. If there were a graph showing scalability, Ansible would be at the peak on that graph.

We are about 50 servers. It is not very big, but we are continuing to grow.

It's scalable. We're looking at an enterprise configuration, when we get it done. It's a matter of getting it licensed.

Ansible has some built-in mechanisms to help you scale. There are different playbooks or steps. I have various multi-project partners that handle these kind of jobs, so I can do the provisioning simultaneously. Of course, we still need to do some prerequisites and there are dependencies between various jobs. 

The solution can scale well. It works for small or large enterprises. There is no limitation. 

We definitely don't have any scale challenges at Oracle. I came from Microsoft, where scale was an issue. We have a small six figures of servers, so it's not a massive environment, so scalability is okay.

SSH is pretty good, but it was not designed for the access pattern of hundreds of connections out of configuration targets. Other tools solve this with a listening agent process, so the initial connection to configure is much faster.

It is scalable.

We patch every week and have seven different environments, so now we are dealing with about 300 servers. However, we could increase that to 20,000 servers, as long as we have them in our catalog. We could push that out and be fine.

It is scalable. You can easily configure one or more nodes.

It has a lot of good features. For example, if you want to create a leader, you can execute a role on one node, then ask it to run on all the remaining nodes. It can easily scale this way.

We're a small shop. It seems it could be quicker, but for what it does, it's fine.

We have approximately five people using the solution in my organization.

I rate the scalability of the Red Hat Ansible Automation Platform a nine out of ten.

I rate Ansible eight out of 10 for scalability. 

It is scalable enough for our needs. We are not working with hundreds of nodes, just ten to 15.

Regarding scalability, we had issues initially. The biggest issue we ran into is, while yes, the documentation says if you want to run on 100 machines you need to have this many CPUs and this much memory - and we started following that - if my job template has 50 tasks in it and I enable verbosity and I run it on 1,000 servers, I am out of memory right away. The moment I have to expand to 1,000 or 2,000 or 3,000 servers, I cannot run verbosity. That has been one of the major problems that we have faced.

Scalability-wise, if I'm not enabling the debug log, it's good. Normally I do that. I have to cut down the list, shorten the number of target hosts, and then I can enable debug. That's been a problem.

I've had no issues with the scalability of the Red Hat Ansible Automation Platform.

Our organization has four to five administrators who use this solution.

I have never had any scalability problems. I have deployed 2000 computers all at once in the past for a previous employer. 

I'm going to have to learn more about the Tower and the sharding of jobs that's coming because, right now, I'm just writing stuff to a couple of individual devices - for Cisco ACI and Palo - but once I get into the Cisco IOS, we're talking thousands of devices. 

Scalability should meet our needs going forward.

So far, we haven't run into any scalability issues. We haven't needed to scale to the levels I've heard spoken about here at AnsibleFest 2018. Certainly, this summer, we used it to push over 8,000 lines of code on network devices and it worked quite well.

It is all modular-based. If there is not a module for it today, someone will write it.

It scales well because of the clustering.

I haven't deployed it at a giant scale, but hundreds of nodes seems doable without too much trouble.

There were a few scalability issues. I had no problems as long as the number of servers was less than 500. When the number of servers has exceeded 500, I encountered an increased number of failures when trying to provision all together. I tried to play with forks, timeouts, and other options, but as the number of servers grew, I got more failures, so I had to provision smaller groups.

It is scalable.

As long as there is a continued focus on improving performance and scalability, then it should meet our needs going forward.

It should meet our needs going forward. We use it in a number of different environments which range anywhere from a handful of servers all the way up to thousands of servers. It has performed and scaled well for everything that we have done.

A little slow.