I would rate the scalability an eight out of ten. 

The cloud plays a major role in its scalability. When it comes to on-premise, it's not that scalable, as you will need to have a server and a standard process around that which will reduce the delay. In general, it's not that easy to get a system scalable when it is on-premise, especially when compared with the cloud as it's much easier to scale a system horizontally or vertically with any number of resources.

Scalability is another strong point. It's very scalable. It's very easy to stand up parallel machines, and add them to a cluster. We have two machine clusters because another strong point is that we've built everything in high-availability. We have two of everything; everything is clustered. But if we all of a sudden acquired 50 more companies, and had all kinds of additional business, we would just stand up a couple of more servers in the cluster, they would inherit the same exact code, and it would be simple very simple to scale.

It's used for all our North America integrations. It runs the gamut of a little bit of EDI, a lot of EAI, and some MFT. Anything where one system needs to talk to another system, and trade data, we use WebMethods for that.

We are always building new things in it. There are always new projects. 

Its scalability is good, but you have to plan it in advance. When you are designing your overall infrastructure architecture and delivery framework, you need to put scalability at the core of it. Once your infrastructure is set up, it's not very easy to scale it up or down.

It can run on commodity hardware, so it is scalable using commodity hardware, like Intel processors of any brand, as long they run on the Linux operating system. They can do a clusterized environment and scale easily when transaction volume is bigger than we expect. It can actually scale on demand, and it's easy to set up by joining a new cluster into an existing cluster. It performs well in this case.

We have 60,000 to 70,000 employees at the bank. About 10,000 people are using the services we create with the solution. They are mostly in the transaction back office and they monitor the day-to-day transactions from the channels. They monitor our mobile banking, trade, finance, and treasury transactions, as well as wealth management, corporate payments, and cash management. It's typically the wholesale, retail, and the micro-banking staff who heavily use this integration. For the back office, the upper-level user is a department head, while the junior level is staff that does the monitoring, day in and day out.

Scalability is very good on the cloud but a little difficult for the on-prem version because it requires the creation of one integration server and booking the code on a second integration server, and creating a cluster between them. 

The scalability of webMethods integration server is much greater than the solution we used previously, which was from IBM.

I have worked in applications that have millions of transactions coming in, so webMethods scales very well. We have performance tests done. With just one Integration Server, we could scale up to just one service, and 400 TPS are usually supported, or four under transactions per second. With the current implementation that we have, it has millions of users. We have around 100 developers in the company who have been using Integration Server directly.

Maybe five years back, the architecture model that we were following was maybe a service-oriented architecture. We are moving towards microservices right now. In terms of the Integration Server footprint, there is no plan to increase it further. 

We also don't have transformation requirements nowadays, since we are moving towards more API or driven-based architecture.

The solution is very scalable. If you want more webMethod Integration Servers, it is very easy to spin them up. It's very easy to apply packages to each one of those solutions. Or, if you want to just have one large webMethods Integration Server, it is easy to create the configuration settings to allow that JVM to have more memory.

There are less than 20 users. A solution like this is normally a back-end solution. Obviously, we have administrators who are overseeing the product to make sure it's up, patched, available, and secure. Developers who are rolling out new solutions and debugging any issues going on in production or lower environments. Then, the third group is probably the business users. That is a very small hand full of users at our company. Those users are typically looking just to make sure that the data is flowing as they would expect. For example, I expect a certain file to go out to this customer every day. That business user has access to log into the application and pull that file.

The product is used extensively at my organization. Out of all our integrations, it probably counts for 60 to 70 percent. Every minute of every day, it's being used. I think the usage that we have in place today is correct. If we were to expand any further, we would probably be looking at iPaaS solutions.

The solution's on-prem version is scalable. I am not sure about the cloud version since everything is controlled by the product. My company has 500-600 users. As a consultancy business, we offer solutions to clients across different countries who seek to implement network solutions.

Different people view scalability differently, but with webMethods Integration Server, what's happening is that you have cloud-based tools that make the solution far more scalable.

From a webMethods Integration Server point of view, as long as there's a load balancer in front with clustered mechanism, then it should be good to go. Still, the real key is how much of the transformation occurs in integration scenarios, the volume of transactions, the number of transformations, and content-based routing, which affect performance and scalability.

A good example is when you must put a highway to handle the traffic load it is typically expected to serve. You don't need to make it very, very scalable. If you're integrating the product with internal components in SAP or the Salesforce CRM system, you find out how much traffic typically happens, and you double it. Then you create an integration solution, which you benchmark to see whether it can handle that particular load. If it's going to be a cloud-based solution, you again do something similar, but at a much grander scale. That's when you put a load balancer in front and do all your scalability tricks.

There are many scalability options, it is possible to add core CPUs to your server or you can add additional servers. Both are possible, both are not complex. The only thing that you need to take into account is then the licensing, but there are no technical issues for scalability.

With our current licensing, it's very easy for us to scale. With our older licensing model, it was very hard. This is definitely something that I would highlight. I'm very happy with our current setup because we can scale and it's more of a constraint of your commercials rather than a product constraint when it comes to scalability.

I rate the solution a seven out of ten for scalability.

The scalability of the webMethods Integration Server is good. You can scale out by purchasing extra licenses in the new nodes.

We provide a public service, we have more than 1,000 users using this solution.

The scalability of the webMethods Integration Server is good.

Our IT team is using the solution in my organization.

We plan to increase our usage in the future.

We find that it scales very well. It's a true enterprise tool.

Our usage will increase as our business grows. It's a core part of our infrastructure.

It is highly scalable, to my knowledge. The organization has used it for almost two decades without issue. I'd rate the scalability nine out of ten. 

We have about 100 users on the solution. 

We do not have plans to increase the number of users, to my knowledge.

webMethods Integration Server is a scalable solution.

webMethods Integration Server is a scalable product.

webMethods Integration Server is a scalable product.

It is being used only by the developers, it's not for public users.

We have three developers in our organization who are using it.

Our entire company uses the solution. There might be 100 people using it on a daily basis. 

Scalability is one of the main purposes of the product - scalability meaning that it can adapt to small customers, clients, and even to bigger systems and clients with a lot of data going through the Integration Server. 

This is a scalable solution. 

We haven't run into any limitations up until now. We utilize it for a lot of different things, but we haven't run into any speed issues or other problems.

We end up talking to our customers using the solution and we have over 250,000 customers. Our internal users don't really even notice it. They just see that everything is up and running and available in real time.

Scalability has not been a problem for us.

No. Absolute top.

webMethods Integration Server is scalable. We use it daily. 

It is easy to scale. We can really scale it up. We have had no issues with this.

Right now, we have an establishment of one organizer per platform but our plan is to use it as the only, single point of integration. The entire enterprise, all applications through all departments, and all IT will use the platform.

We are planning to increase the usage of the platform continuously over the next five years.

You have to buy another license for clustering named Terracotta which also had several different license, basically it was acting as a multicast and a cache, so if one of your node is processing something it would write into Terracotta, and then the other node would recognize some process going on so it wouldn't try to do the same processes which would be make double transaction for instance. It also can be use for data cache so you could have better performance fetching frequently data called rather than query it somewhere else e.g Database or REST Resources

It seems to be doing very well.

I rate the scalability a nine out of ten. Seven users are using the solution in our organization.

We have ten solution users in our company. It has good scalability. We plan to increase its usage.

For what we need, it scales quite well. We don't have to worry about having to scale too large as our organization, a bank, is not a very big bank. That said, scalability has never been a problem. 

It's a solution that is generally used by the IT department, not everyone in the company. Maybe between five and ten people use it in total. 

webMethods Integration Server is a scalable solution. There are Microsoft Windows and Linux versions available.

We have more than 10 customers using this solution.

We had some issues with clustering as we were trying to scale. We are using Terracotta and it gave us some problems.

No issues with scalability.

There were no scalability issues on-premises, but I have yet to check with the virtualization concepts and cloud scalability coming up.

The solution is scalable.

I rate the scalability of webMethods Integration Server a nine out of ten.

No scalability issues. Typically, you can not scale the solution if it is not well designed (architecture, service layers, data processing).

No.

Not much.

In terms of scale, I would give it a four out of 10.

The solution is scalable. 

No problem with scalability in versions 6 and 7.