The solution is scalable, and my organization has more than 5,000 employees.

There are some restrictions. That is something that bothers us because there are some service limitations. For example, the file size is limited to this amount; there are some restrictions. Oracle claims that it is being restricted internally due to performance issues. 

If you use a file larger than a GB or something, they offer very different adapters with different restrictions, that is all. 

According to the current situation, we will either split the file and then manage it internally. But it adds a lot of, sometimes unnecessary, overhead for us because the team implements; we need to improve that. There are some things they can work on to improve.

The solution is only used by the core IT team; no one else uses it.  It will be a five-person team from the client's side.

Not more than five, because the client's IT teams are limited to five people, and they only manage it. There are a maximum of five people.

We use it every day.

It is easily scalable. For example, if you want to add servers to an existing set of servers to increase elasticity, it is easy. As demand changes, the elasticity can be reduced or increased.

It is also dynamic. It is dynamic in some of its features. It automatically enhances the server if it is needed more and reduces the servers if they are idle for an extended period of time.

We work for a variety of clients. I am sure there are a lot of clients who are currently using this Oracle Integration Cloud solution.

We do have an Oracle practice we call Oracle COE which stands for Center Of Excellence. For just OIC, I would estimate that we have a global team of over 500 developers.

Just for OIC, we have Fusion products separately, Oracle integration, ERP Cloud, and SIM cloud, that is the SaaS layer, but they can be more than 500 developers for the PaaS layer.

This solution is extensively being used by our organization.

I believe it will be used even more or remain stable, but I do not believe its demand will decrease. But, the usage will be more.

I rate the solution's scalability a nine out of ten. We have more than 100 solution users in our organization.

I would rate the scalability an eight out of ten. There are around fifteen end users. We use it on a daily basis. 

Oracle Integration Cloud Service is scalable. We have not had any performance issues with it. It behaves well. 

We have seven or eight clients using this solution currently. They use a variety of other Oracle products as well that we have helped arrange. 

I rate the product's scalability an eight out of ten.

It can scale. You can just keep provisioning it. Of course, you need additional computing power, however, you can always add it. It comes with a certain cost, which needs to be considered. That said, the scalability is there; you can increase, optimize, or decrease it also.

Oracle Integration Cloud Service is scalable.

We have approximately 30 IT experts in my small organization. We have plans to increase the usage of the solution in the future.

We're not in production, but they've said that as long as we're not using the VM for any services, they will automatically scale it. There are a few from my team using the solution and also some developers. It will be extended as we move forward to our development and QA, UAT stage. We currently have up to 25 users but we know we can have 300 or 400. 

This product is definitely scalable. It suits enterprise companies and small companies. Day-to-day middleware users would not use this solution, just technical users on the IT team.

The solution can scale quite well.

The solution is scalable but we haven't tested that yet. We tried to download a large file from a CM cloud but services were getting timed out because it took longer than five minutes.

Oracle Integration Cloud Service is scalable. It's all configurations. We have approximately 500 people using this solution including IT developers, IT leads, IT designers, and IT architects.

The stability of Oracle Integration Cloud Service is great.

We have approximately 100 people using this solution in my company. In my client's company, there are approximately 50 users using it with plans to increase usage.

There are volumetric constraints today driven by licensing, but we haven't encountered an issue with this. However, people should consider them before signing up.

Scalability is a complex thing, as when we scale with more instances and requests, there will be costs attached to it. However, OIC can be scaled and it scales automatically.

Oracle Integration Cloud Service is scalable, we have tripped out the size. I am confident that it can continue to scale.

Many think that they can use OICS as an ETL tool, which is not true. There are other offerings from Oracle that offer that, they just need this layer to bring in data and process data.

I would rate the scalability seven out of ten.

Scalability is an important non-functional requirement in any software engineering project. Scalability supports two other non-functional requirements: performance (e.g. throughput or data processed per unit time OR response time in a synchronous request-response scenario), and availability (for high availability, the environment needs more instances in a cluster so if one goes down, others can serve requests without causing downtime to consumers)

Scalability depends on two (occasionally competing) aspects:

1. Platform-level scalability; this is the ease of provisioning hardware, VMs, application server instances in a cluster, etc. In the case of Oracle Integration Cloud, this aspect is well abstracted away from application developers and fairly easy to manage. It can easily scale up or down.
   
   
2. The second important aspect of scalability is the actual technical design of the application. In OIC's case, "integration flow", that is deployed on the platform.

A well-designed solution can achieve the same performance on a fewer number of instances, less memory, and less CPU. A well-designed solution that is "scalability-friendly" would easily spread its load across multiple instances that might be available to it and its performance (throughput) would ideally improve linearly with an increase in the number of instances. An important quality of a scalable solution is also that in the event of "infinite load", it would only accept as much as it can easily process at a predictable rate given the resources available to it, and would then start accepting more as more resources are made available (a non-scalable solution would simply fail under such an 'overload' situation). 

It often happens that some of these application design level aspects of scalability get neglected, therefore, customers often end up incurring unnecessary costs in merely "platform-level" scalability with the expectation that "performance issues" would go away by throwing more OIC instances at an application. 

To deliver the best outcome to customers, both of the above perspectives on scalability need to be addressed. 

For our customer's use cases, we achieved this with our application design and repeated testing with large data volumes. We did not over-engineer or over-optimize, even when we felt the solution could be enhanced to perform with higher throughput, we took customer's feedback on when the throughput was acceptable for their immediate business objectives, to avoid diminishing returns

The solution is scalable.

The solution is scalable.

The scalability is good. 

We used to face some issues when we tried to connect to the Oracle ERP Cloud. When we were trying to run a job on the ERP Cloud site, when the integration was complete, the job on the Cloud would still be running. We couldn't completely monitor the execution of that integration. There were instances when the integration finished, and at the end of the retry count, the thing was still running — the job on the ERP Cloud site was still running. 

Because of this, we had to keep pulling the job on the ERP Cloud site to find out if it was finished or not; but you can't keep doing that forever. We would retry and after five attempts, we would find out that the job was still running. We just had to report back saying that the job was still running on the ERP Cloud site. There was no way of knowing whether a job was completed successfully or not — unless we logged into the Oracle ERP Cloud and checked the status of a particular job.

Although the solution is fairly easy to scale, we're using the latest version which is available on OCI, and scalability should be addressed. I believe Oracle is still working on this. At the moment I think, probably small, medium integrations are good. Bigger integrations could be developed, though availability and progressive recovery are not in place yet. We have about 7,000 people on the solution. Scalability is mission critical for us at this point. The entire company utilizes it and it is integrated with critical solutions like SAP and HTML output factors.

It still hasn't gone into production yet. We have around five users configured already. I don't think they charge based on the users, so doubling the number of users probably should be okay. The way it works is, basically they made me the admin and I can add as many users as I want. They charge based on the number of adapters that are configured. You can have six licenses or 10 licenses.

It is scalable.

There is a limitation with the data, a limitation in terms of the amount of cancellations that you can do, and with the amount of the size of the payload.

We have around ten users using this solution in my company. We have plans to increase usage. 

We had no issues scaling it for our needs.

Scalability has not yet been an issue for us in this project.

Within our group, there are three people who are using the product. Once it goes live, there will be a knowledge transfer to a group of support people. There are approximately eight to ten people in that group.