Why traditional software doesn’t scale

With traditional software, developers make assumptions about how the application will be used, especially about how people will organize their data. When all those assumptions prove to be true, the application tends to perform well. If those assumptions don’t hold true (or if the developer doesn’t make assumptions but only provides a set of configuration options), the app needs to be “tuned.”

The tuning is never done by the original developers, however, because that approach doesn’t scale. Instead, customers usually hire consultants, who conduct a lengthy evaluation and education process and then do their best to tune the app. Over time, the way the customer uses the app changes, requiring more tuning.

How our multitenant platform delivers scale

In a multitenant, cloud-computing environment, there is effectively one platform that serves the needs of all customers. The developers who originally wrote the code can constantly tune the platform and even re-architect it based on real-world usage data. Compare this approach to on-premises software, where the developers never know how the platform is actually used.

We constantly monitor for performance issues related to such things as database queries and search. If there is an issue, our performance team evaluates it and then sends it directly to the development team. Frequently, the issue is addressed before customers even know it exists.

Because the development team is intimately aware of the app’s real-world performance, we can significantly re-architect major subsystems to provide dramatic performance improvements. For example, in the Summer ’09 release, we re-architected the sharing model; as a result, for example, one of our largest customers can now re-parent roles in the role hierarchy in only 2 minutes compared to the previous 1 hour 18 minutes.

Despite massive growth in the number of requests over the past few years—from about 500 million requests/quarter to about 10 billion requests/quarter—our overall performance has decreased from an average response time of about 600ms to under 300ms.  

Learn more