If you’re small, scalability is not an issue. If you’re big, you can plan for it. But what if you wake up one morning and you suddenly find you’ve become the next Google?
In his talk “The Economies of Scaling Software“, Abdelmonaim Remani talks about what scaling means, how you can plan for it (even if you don’t expect it to happen) and all the nasty details that stand between you and success (slides on slideshare).
Today, the ubiquity of the Internet has blurred the lines between consumers and enterprises. They start to ask the same questions which eventually all boil down to: “How can I find what I’m looking for in a universe of haystacks?”
One day, many of us will find themselves with the need to scale because the performance of the old solution has become unbearable and all low-hanging fruit (faster CPU, more RAM) have been picked.
To solve this, you can look at the CPU (slide 16-35) or you can start to build clusters (36-45).
Or your I/O might be the bottleneck (slides 46-60). You can solve this by looking at NoSQL databases and caching.
Is the network the problem? (slides 61-75) Start with asynchronous processing, batch jobs, content delivery networks (CDN), DNS sharding or use a different protocol to connect the various parts of your system.
But how do you know what part is the bottleneck? The answer here is monitoring. (slide 77)
Note that scaling often helps with disaster recovery, you still have to plan for it – if all nodes of your cluster are in the same room, it’s still a single point of failure (slide 79)
Software isn’t everything. Don’t forget your team (slide 82)
Posted by digulla 
Dark Views 