The preface gives us a "lay of the land" and sets expectations. The book is aimed at anyone creating an enterprise-class application. What is an enterprise-class application? Any application where if it goes down the company loses money. I suspect that Twitter, Facebook and many parts of Google would be considered enterprise-class. If GMail stops working then Google can't serve its ads to the millions of people who use it. Probably not good. If you think about your own application, do you wish to avoid those late night support calls? Is it your hope that the operations people can properly deploy your application into their data centers and keep it tuned and humming? If any of these apply to your application, perhaps this book can help you. The author hopes that the reader will come to the realization that no matter how much you plan, bad things will happen to your software when released into the wild and you need to account for those things.
The book is broken up into four sections with each section prefaced with a real-world case study. The names in the studies have been changed to protect the innocent but the money lost and the pain that was felt remain.
Section one revolves around keeping the system alive. Nobody is going to worry about paying for new features in your next release if they have to reboot the system every day just to keep it breathing. The system must be stable.
Section two addresses capacity. What does capacity mean? How can it be optimized over time? What are some design patterns and anti-patterns that affect capacity?
Section three discusses how to make your system more easily deployable into the data center. Hardware, software and networking has changed over the years and we need to be aware of those changes in order to make deployment more palatable to the operations folk.
Finally, section four is about obtaining intel from your running system. How do you gather relevant data? What do you do with that data?
No comments:
Post a Comment