Just finished reading the book The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise by Martin Abbott, Michael Fisher. The book draws on authors’ experiences working at PayPal/eBay and other Internet companies, and covers many aspects of scalability including people, organization, process, and technology. According to Yishan Wong, who used to work under the authors and is now an engineering director at Facebook, “the opportunity to directly absorb the lessons and experiences presented in this book is invaluable to me now working at Facebook.”
The authors made a good point that people, and sometimes processes as well, are more important than technology to deliver scalability. I think it’s probably true for other engineering disciplines as well.
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
The book even has two pages on CMM/CMMI(Capability Maturity Model Integrated). When a book or article includes an introduction on it, I think it’s an indication that it may be a bit verbose or too theoretical for pragmatic practitioners. That is why I didn’t read the book from cover to cover. Instead, I find the conclusion and key points sections at the end of each chapter are pretty helpful. So I read all of the conclusions and key points, and whole chapter when I need to.
As a technologist, I am more interested in technology than anything else. I found the AKF’s Twelve Architecture Principles in the book worth mentioning here.
- N+1. It means you always have redundancies for everything. Even better is you can have three, which is the Rule of Three.
- Design for rollback. When a new version doesn’t work, you can always to roll it back to the previous working version.
- Design to be disabled. Then you can turn off individual features as needed to isolate problems.
- Design to be monitored. You can only take actions only when you know something goes wrong or out of range.
- Design for multiple live sites.
- Use mature technologies.
- Asynchronous design. The caller of a service should not have to wait for a process, therefore can improve parallelism.
- Stateless systems. When a system is stateless, you can easily bring up or down a system easily. Note: it’s true for cloud computing as well. Check my aritcle: stateless VM.
- Scale out not up. It’s much higher chance to hit an up limit than an out limit.
- Design for at least two axes of scale: (AKF Scale Cube: X-All Work Evenly Distributed; Y-Work Distributed by Type of Action; Work Distributed by Customer Location.)
- Buy when non-core. It basically says don’t invent your own wheel, as you know in software.
- Use commodity hardware.
Please note that as the book title suggests, these principles are for the Web architectures. They may or may not apply to enterprise infrastructure and applications. If you work on IT for enterprises, you need to think more before adopting them.