Cloud Does NOT Mean Infinite Scalability
Scale and Scalability: Rethinking the Most Overused IT System Selling Point for the Cloud Era
Scott Fulton does a nice job dispelling some myths about cloud computing. Application performance is vital to companies today because of the dollars tied to websites, back office systems, and many forms of business automation. New start-ups utilizing cloud infrastructures are quickly coming out of the gate with disruptive technologies that process huge volumes of data for an ever-increasing user base.
We geeks have been saying for years, “you can’t just throw hardware at the problem.” Scott says:
“If you believe that a scalable architecture for an information system, by definition, gives you more output in proportion to the resources you throw at it, then you may be thinking a cloud-based deployment could give your existing system “infinite scalability.” Companies that are trying out that theory for the first time are discovering not just that the theory is flawed, but that their systems are flawed… and now they’re calling out for help.”
Business people are waking up to the fact that scalability is as important to their success as capitalism and democracy. They usually don’t know how important scalability is until their system fail. After customers and revenue are lost, then they look into the underlying causes and find their systems don’t really have the performance capability they thought. So in typical manager decision making, they use money to solve the problem by re-deploying on a cloud infrastructure to get much more horsepower. Unfortunately, it is NOT that simple. Cloud platforms are not magic. There are thousands of variables in the scalability equation, and the cloud with massive virtualization is only one factor to improve performance.
Sometimes the solution is to re-architect the system. In fact, Twitter has re-architected their system 4 times already. An academic may tell us to plan for growth, think through all the possibilities and produce the most scalable system from the beginning. Yeah, good idea. But it just isn’t that easy because there are too many moving parts. Many of the moving parts are on moving platforms that are getting better, faster, cheaper by the month. Scott tells us to do the best we can with what we have now, and then always be looking ahead for ways to improve performance – including throwing away what you have to build a more scalable application architecture.
Bradford Stephens calls today a transitional period where no one truly has scalability figured out. There is no single right answer for evaluating a scalable platform. But he suggests that virtualization and the cloud make it feasible/affordable to rescale by powers of ten rather than multiples of two. That’s exciting to me.
Scott says this:
This is uncharted territory. What we do know is that businesses can no longer afford to develop solutions around the edges of the core problem. They can’t just point to the symbols for their systems’ various ills (latency, load imbalance) and invest in the symbols that represent their solutions (scalability, the cloud, CMS platforms, social network platforms) as tools for postponing the inevitable rethinking of their business models. Throwing your business model at the cloud doesn’t make the symptoms go away; indeed, it magnifies them. Symbols aren’t solutions.
A quote by Sean Leach in this article matches the philosophy of our CTO, Roger Campbell. Namely, get the app into the customers hands quickly and if you need to fix a scale issue, then that’s a good problem to worry about when it arrives. Over 90% of web apps never get much traffic anyway, so why waste time until you know it will be an issue? Wasting months upfront analyzing and planning the best scalable architecture could very well translate to you launching nothing…ever.