"That is because scalability issues are not framework or language specific." - Brian McCallister Good post from Brian. But be careful, it's not all solved in the system architecture. Which is to say, no matter how good your architecture is, you need to think about and measure how well the application code is running. You can still write application code that will kill a computer as the volume of data grows, no architecture is going to help you out there. Sean was telling me last night about some performance profiling he'd been doing for a multi-stage, multi-pipe XML processing line - let's just that where the bottlenecks turned up were counter intuitive - I absolutely guessed wrong, but of course I did - it's a given that you'll guess wrong. So you have to measure - but to measure you have to build something to measure - you won't solve these kind of issues during architecture-picture-time. Spend architecture-picture-time making sure you can build something which can be measured later on. As we keep moving towards application logic and to a value-driven programming world where transaction monitors, pools, caches, i/o, malloc-dealloc, library data structures, and runtimes are about as relevant a concern as flip-flops and asm, there's a risk we'll forget about the algorithmic side of code, which is never going to go away completely. Two of my favourite algorithm books for the working stiff, real eye openers, are Richard Skiena's The Algorithm Design Manual and Jon Bentley's Programming Pearls. The other thing that's caught my eye is not a book but a presentation [pdf] fast becoming a classic, by the people behind Livejournal, which is called, but if it were a nineteenth century novel it would would be called "LiveJournal. Or, You Can Scale Anything For Capacity When You Put Your Mind To It Even If You Didn't Get It Right Up Front, Or Have Become Surprisingly And Insanely Successful, And Are Now In The Weeds"....
Previous Topic
