The Path to Zen

Call Me Pedantic - What Exactly IS Scalability?

This is mostly triggered by Diego Parrilla’s post Spring is not designed for scalability, in which he goes, “…Basically you have two options if you want to scale with pure web applications…”, and then gives two options to scale, both of which involves state replicating clustering schemes. There, Diego, you got on my pedantic nerve. I can’t help but wondering this question - what, exactly is Scalability?

So I went on and did a bit research (OK, OK, I really just googled “define: Scalability”), and got these definitions. Let me just quote the first three here:

The ability to scale to support larger or smaller volumes of data and more or less users. The ability to increase or decrease size or capability in cost-effective increments with minimal impact on the unit cost of business and the procurement of additional services. - dmreview.com

The ability and flexibility of an application to meet growth requirements of an organization. - hostqueue.com

The ability to expand a computing solution to support large numbers of users without impacting performance. - primode.com

So scalability is about performance - the capability to handle large volume of traffic, as far as web applications go. It does not have anything to do with “miminal service interruption when one of the servers goes down” - that’s High Availability. It especially does not have anything to do with “no service interruption whatsoever” - that’s Continuous Availability (see the last link). We usually don’t need the expensive state-replicating schemes to achieve Scalability, or even High Availability. A sticky-session load balancer and a server farm without busily replicating sessions among themselves would scale well, and would provide some pretty high availability. It can’t provide Continuous Availability because when a server fails all the users on that server at that point would have lost their sessions. That’s the only case where clustering comes in and support immediate fail-over without any interruption to the service.

Now, the real question for all you architects out there that can’t wait to hop on the “clustering wagon” the second you hear “scalability” is, is your application really “mission-critical” enough, meaning no user can ever lose her session, to justify the cost to implementing clustering? Remember the cost here includes not only the performance penalty (ironic isn’t it), but also the development penalties - you’ll have to make sure that whatever you stick in the session implements the Serializable interface, that whatever you stick in there references does the same, and finally that not too much is stuck in there.

On a separate level, I don’t necessarily agree with Diego’s comment (his main point actually) on Spring being not scalable, either. The fallacy here, IMHO, is the same as what I have seen from a lot of other online discussions. It’s that people keep trying to compare Spring with EJB, forgetting they are different things and meant for different things.

What is Spring? Even though we all refer to Spring as a container, we have to remember that it’s a completely different kind of container from the kind EJB is. Spring is a bean container, or rather more accurately, as the name of one of its core interfaces shows, it is a bean factory. All Spring does is providing us the ability to transparently wire up our applications, and the convenience to easily integrate with lots of third-part tools, but Spring does not reinvent the wheels by reimplementing those tools on itself. E.g., Spring provides easy integration with well-known ORM tools such as Hibernate and iBatis, rather than providing it own ORM package. On the other hand, EJB is a container in the real sense of “All Your Base Are Belong To Us” :). It provides a complete solution with a more restrictive programming paradiam. Spring is not mutually exclusive with EJB, nor is it a competitor of the latter one. You can use Spring to wire up an EJB-based service layer just as easy as you do, say, a Hessian-based one. Comparing Spring to EJB is like comparing apple and orange.