Availability

Availability is the ability of your application to perform the tasks it is capable of doing. This differs from reliability, which is the ability of your application to not make mistakes. A system that adds 2 + 3 and returns 6 has poor reliability. A system that adds 2 + 3 and never returns a result has poor availability.

Poor availability is caused by many things, including the following:

• Resource exhaustion

• Unplanned load-based changes

• Increased number of moving parts

• Outside dependencies

• Technical debt

Application availability is often the first casualty as an application tries to scale beyond its capabilities. The topic of availability is covered extensively in Part I, including how to measure it and how to maintain a highly available application. Even in light of continuously increasing scaling needs, your application availability can be maintained at appropriate levels for your needs.

Risk Management

You cannot possibly manage the risk in your system if you cannot identify the risk in your system. This is the critical lesson from Part II. Understanding your risk is the first and most important step in operating a highly available, highly scalable application.

After you understand your risk, you must manage that risk. Although removing risk is always desirable, often the cost of doing so is unacceptably high, both from an actual cost standpoint, and from an opportunity cost to your application. You certainly have more important, more customer-focused things to do that are better for your customers, your company, and your bottom line than to remove every ounce of risk you know from your application.

Instead of removing all risk, you must manage the risk. This involves evaluating two values with every risk, the risk’s likelihood, and the risk’s severity. These two values are so important, we dedicated all of Chapter 6 to the subject. Generally, severity is the cost to you if a risk happens, whereas likelihood is the chance of the risk happening.

A risk that can cause a very serious problem in your application (but is virtually impossible to happen) might not be one that you want to try and remove. Similarly, a risk that is highly likely to happen, but would have very little impact on your application, is probably not a risk you will need to prioritize removing. Yet a risk that is somewhat likely to happen and can cause a reasonably serious problem may, in fact, be the most important risk for you to work on resolving.

We introduced a tool called the risk matrix, which can be quite effective in helping you manage the risks of your application and determine which risks need to be mitigated or removed.

We discussed techniques for mitigating risk, techniques for validating mitigation action plans, and techniques for building applications with reduced risk.

Services

A service is a distinct enclosed system that provides business functionality in support of building one or more larger products. Services provide an application architecture pattern that facilitates building systems in a manner that promotes improved system and development team scalability.

When building highly scaled applications, services provide the ability to make improved scaling decisions, accommodate improved team focus and control, reduce complexity at the local level, and improve testing and deployment capabilities.

We provided tools and suggestions for how to build high availability into your application at the service level, and reduce the effect of service failures on your application and its users.

Scaling

We covered how to build your scaling plans to ensure system availability and management. We discussed building systems “two mistakes high” to avoid failure loops and cascading dependencies.

We also looked at the Single Team Owned Service Architecture paradigm, or STOSA. This provides a model for scaling your development organization as your application scales, to provide the ability for a larger number of engineers to effectively work on a single application, without sacrificing application scalability or availability. This involves defining what it means to be a service owner and organizing your application around these principles.

We talk about using tools for managing service dependencies to maintain application quality even during times of hyper growth, including internal SLAs and service tiers.

Cloud

Finally, we looked at the cloud and how you can use it to build highly scaled applications.

We looked at how the cloud has changed the way we think about computing, and the way we think about building applications. We discussed building geographic and network topographical diversity into your application using the cloud, and how to avoid pitfalls where you believe your application is geographic and network topological diverse, when in fact it might have built-in dependencies that increase your risk of problems.

We addressed the use of managed infrastructure and how you can utilize it in highly scaled applications. We covered how cloud-based resources are allocated, and the role you need to play in ensuring that your applications have the cloud resources they need to keep operating.

We then discussed compute options available to you when using the cloud. We looked at AWS Lambda, and the revolutionary future in scalable development it enables.

Architecting for Scale

Architecting an application for scalability is more than building an application that handles lots of users at the same time. There are many things involved in making an application scalable:

• You must be able to handle a large and growing number of customers.

• You must be able to handle a large and growing quantity of data used by your customers.

• You must be able to handle a growing complexity in what your customers want to accomplish with your application.

• You must be able to add more developers working on your application as your company’s needs expand, and you must do so without sacrificing development speed, efficiency, or application quality.

• You must keep your application online and functioning, even in light of all of the aformentioned changes and improvements.

These aren’t easy problems to solve. The techniques discussed in this book are designed to help you solve these and many more of your application scalability concerns.