Why scalability hurts so much.
By Sean Mc Grath
By and large, software applications that scale - be it in terms of millions of users, transactions, documents, records, or whatever - cost a lot more to develop than applications that do not scale.
There are a number of reasons for this - some technical, some Machiavellian. I will restrict my gaze to the technical ones and let your imaginations contemplate the other kind.
There does not appear to be a mandatory correlation between the scalability of IT solutions and complexity (and thus cost), yet it is rife in the industry.
The HTTP protocol on which a majority of the Web is based, is an excellent counter-example in that it combines simplicity with great scalability. This puppy is so simple in comparison to many communications protocols yet it scales very, very well. It degrades gracefully with load. Its design allows any amount of clever trickery to be used to boost performance whilst retaining the innate simplicity of the HTTP protocol.
The key word here is, I think, "simplicity". I have no proof to offer you when I say that simple software designs just seem to scale well. If you look after simplicity, then with the aid of some analysis and precise intervention, scalability will look after itself. This is one of my most deeply held intuitions about system design.
I like to think (perhaps wrongly) that Tim Berners-Lee concerned himself with keeping the HTTP protocol simple and that scalability just, sort of, well, you know, happened.
Let us turn our attention to the layers of functionality that have been built on top of the original web. We see numerous examples of technologies where scalability certainly does not just happen of its own accord. The Web is awash with scalability frameworks - often served up with a side-order of standards - to address the scalability problem head on. If you want your application to scale, so the story goes, you must design to the framework. All else is folly...
Being a fully paid up simpleton, the primary problem I have is that none of the popular scalability frameworks out there are simple. It can take literally years to achieve a high level of proficiency in these things. Does it have to hurt so much?
Another problem I have with complex scalability frameworks is the ease with which your architecture can be bent out of shape to fit the framework. Even if the framework is a vendor neutral one, the reality is that your applications easily become tied to a particular implementation of the framework. So much so, that you could have saved yourself a bunch of time and money by coding directly to a vendors "enhanced" implementation rather than kidding yourself about portability of your system.
Then there is XSLT - by far the most common tool for processing XML out there. XSLT has an interesting programming model that constrains what developers can and cannot do quite severely. The reasons for the constraints? They are there to protect something called "side-effect freeness". The main benefit of side-effect freeness? Our friend scalability. Thanks to staying within the side-effect-free framework, a XSLT application can be automatically distributed across multiple machines/processors for execution. Is the price tag associated with this scalability solution worth paying? Is all of the pain and suffering going on in developer cubicles all over the planet right now really worth it? Does it have to hurt so much?
Perhaps. Perhaps not. There are clear examples of where donning the straightjacket of a scalability framework on day one was the right thing to do. However, there are also clear examples where scalability just looked after itself. The latter tends to happen when architectures are kept as simple as possible.
I fear that our increasing reliance on frameworks is making it more and more difficult for free spirited, innovative approaches to scalability to emerge from the noosphere. The gravitational force of a couple of frameworks out there seems to be immense.
Longer term, I fear that the rigidity of scalability frameworks - the straightjackets that come in the box - will negatively impact our ability to innovate "out of the box" in the future.
Does it have to hurt so much?