The most important thing about understanding how to build big systems is realizing that you should respect them.You need to understand the terminology, the teams, the business, and the responsibility.The second most important thing to learn is how not to build big systems.
This book falls into two sections. In the first section we look at big picture issues, mostly in the realm of management and operations of mission-critical systems. In the second section, we jump feet first into some serious engineering discussions.
The first three chapters discuss what it truly means to work with big systems. Although many books have a thousand pages of technical details and examples, this book is terse and to the point.The first three chapters will satisfy both the technical and nontechnical person who wants insight into why working in large, mission-critical environments is challenging. If you hit something technical that you don’t understand, just barrel on through it, or ask your engineering staff, perhaps a systems administrator—they just love that.
-
Defining scalability—You will gain an understanding that scalability and performance are indeed different.
-
Avoiding failure—Perhaps the most intimidating aspect of big systems is the old saying,“the bigger they are, the harder they fall.” You will learn a variety of methods for mitigating risk.
-
Developing—On the technical side, the only differentiator between your business and other businesses is that which you have developed.This book guides you through sane development practices that will help carefully control agility and risk.
-
Monitoring—Are your servers up? Is your business functioning? Oddly, it is rare that the same person asks both of those questions. I will show you that it is vital to monitor both technical and business-level metrics.
-
Managing costs—Cost management is an art. Although this book does not delve deeply here, we will discuss how bad choices can explode the ongoing costs of your architecture.
The second part of this book becomes more technical with each chapter as we discuss engineering solutions to real-world problems. Chapters 4 and 5 are a testament to the confusion surrounding high availability (making sure things are...you guessed it, available) and load balancing (which has nothing to do with availability).Too often these terms are used interchangeably and without a care; that should stop.
The rest of the book is a mixture of case studies and discussions of design approaches. It varies from conceptual and light on the technical details to extremely deep exploration of a problem and its solution.
We will focus on presenting solutions to problems rather than implementations of solutions to problems. Focusing on the implementation in a specific language is a good way to lose the attention of a programmer of a different language.The language is mostly irrelevant. I can’t count the number of times I’ve heard people say “Java doesn’t scale” or “PHP doesn’t scale.” No language scales; solutions scale. By mixing up the examples to use a variety of operating systems, languages, and other technologies, I hope to have you thinking about the nature of the solution instead of the details.
Knowledge you’ll gain:
-
HA/LB—High availability and load balancing are different terms and mean different things.We’ll discuss decoupling their roles to allow for better architecture decisions. At the very least, I guarantee you will no longer mix up the terms.
-
Static caching—By building a content distribution network, you will have the tools to improve performance and user experience.
-
Dynamic caching—Although the benefits of dynamic caching are similar to those of static caching, the concepts are drastically different.You will learn about the various types of dynamic caching and how they can help your architecture.
-
Database replication—This is perhaps the most misunderstood technology today. Different vendors mean different things. I will guide you through this maze of nuance, and you will learn to do replication on your own terms.
-
Clustered logging—Logging is simply ignored by most people. I will illustrate how useful logging can be with compelling examples.You will certainly want to rework your logging infrastructure after reading this book.
I challenge you, the reader, and everyone you can influence, to step up and understand your problems before you attempt to solve them.This applies to management, operations, programming, and architectural design (and quite frankly, life as well).You must understand how what you are building will be used and, from the beginning, design for scalability those parts that need to scale.Too often it involves no more effort to design and implement a solution that scales than it does to build something that will not—if this is the case, respect yourself and build it right.