Summary
In his weblog on java.net, Malcolm Davis discusses scalability, and the advantages and disadvantages of scaling up by adding more memory, CPUs, etc., to one box versus scaling out by adding more less expensive boxes.
Advertisement
In Scale Up vs. Scale Out, Malcolm Davis suggests that scaling up is an appropriate strategy for the database tier, and that scaling out is more appropriate for the application tier. Davis says that a common mistake he sees in IT shops is using a scaling up strategy in the application tier:
I cannot count the number of discussions I have had with system administrators about hardware configuration for application. Many IT shops treat the application problem much like the database problem. Instead of an array of rack mounted blade servers that are inexpensive and easy to add or replace, administrators purchase big boxes.
The administrator's argument about the big boxes:
Bigger bang for the buck
Easier to admin on box than multiple boxes
Easier to make a single purchase instead of multiple small purchases
LN squared hardware failure, the more boxes the more likely to fail.
The reality:
As seen from the BEA study, less bang for the buck for application scalability,
More difficult to admin because of the conflicting needs of all the independent process. Huge impacts occur due to inadvertent changes to root or patches to sub-systems or OS.
Costly mis-sizing of hardware that cost the organization. It cost more to add hardware to a big-box, then to slide in another blade server.
Software, rather then hardware, is generally the root cause of problems in production
I think the analysis skips one big issue. Scale up does not require a rewrite until an application bottleneck stops the app from scaling. Scale out would typically require JMS, Hibernate, or some sort of shared state architecture.
Ignoring the coding complexity, all the operational conclusions line up with my experience helping to run a large Internet eCommerce site.
Sort of why we formed Terracotta to cluster underneath apps so that scale out can be done while avoiding the rewrite.
Without JVM-level clustering, the debate of scale-out vs. scale-up is a toss up, except in the "totally stateless application" case where scale-out is ideal. With JVM-level clustering, there are apps that still shouldn't be scaled out but at least it can be attempted w/o a rewrite.
Previous Topic
