Chapter 1: What is Scaling All About?
Chapter 1.
As applications grow, two things begin to happen: they become significantly more complicated, and they handle significantly larger traffic volumes.
Increased complexity means increased brittleness. More traffic means more novel and complex mechanisms to manage the traffic.
Application developers seldom build scalability into their applications from the beginning. We often think we have built in scalability, and we believe we’ve done what was necessary to let our application scale to the highest levels we can imagine. But, more often than not, we find faults in our logic, and in our applications. These faults appear only after we begin to see scaling problems, and that makes scaling to larger traffic volumes and larger datasets more difficult.
This leads to even greater complexity, and even more brittleness.
Ultimately, this scale/brittleness/scale/complexity cycle turns into a death spiral for an application, with your application experiencing brownouts, blackouts, and other quality-of-service and availability problems.
But these are your problems. Your customers don’t care about these issues. They just want to use your application to do the job they expect it to do. If your application is down, slow, or inconsistent, customers will simply abandon it and seek out competitors that can handle their business.
How can we improve the scalability of our applications, even when we begin to reach these limits? Obviously, the sooner we consider scalability in the lifecycle of an application, the easier it will be to scale. At any point during the lifecycle, there are many techniques you can use to improve the scalability of your application.
But before you can consider techniques for scaling your application, you must get your application availability in shape. Nothing else matters until you make this leap and make these improvements. If you do not implement these changes now, up front, you will find that as your application scales, you will begin to lose touch of how it’s working and random, unexpected problems will begin occurring. These problems will create outages and data loss, and will significantly affect your ability to build and improve your application. Furthermore, as traffic and data increases, these problems simply become worse. Before doing anything else, get your availability and risk management in order.
Modern Digital Customer Experiences
In our modern digital world, software applications become the face of our brand and our company. The way our customer’s interact with us is through our software. Our applications aren’t just part of the customer experience. In many cases, they are the entire customer experience. Software is critical to our success, and modern customers expect our applications to also be modern. How our customers perceive our brands and our company depends greatly on how they perceive our software.
Example 1-1. Non-modern Application
My son has an application that’s on his smart phone that he has to use to get some of his medical benefits. It is a government application, built and run by the US government.
This application doesn’t work all the time. When you launch the application, at an odd time of day, you get an error message. The error message says “This application is only available to use between the hours of 9-5, Monday-Friday, Eastern Time.”.
Yep, that’s right. This is a mobile software application on his smart phone, and the software is disabled except during east coast business hours.
Can your business operate as described in Example 1-1? Can it operate with this type of restriction on its use? Can any commercial business put limits like this on their customers and stay in business?
No, I bet there isn’t a single commercial enterprise out there that can survive and treat their customers this way. Instead, we have to provide our customers with memorable customer experiences. We have to work whenever our customers want to use us. We have to work, 100% of the time, 24 hours a day, 7 days a week. If we do not, we disappoint our customers, and disappointed customers go away.
5 Tenets in Architecting for Scale
What does it take to modernize our software and support our modern customer’s expectations? There are five tenet to building modern, highly scaled, high availability software applications. They are:
Tenet #1. Maintain Availability.
Modern software must maintain a high level of availability. Customers will not tolerate outages. If your application does not function when your customer needs it, they will not remain a customer for long.
Tenet #2. Implement Modern Application Architectur e Using Services.
Modern software requires the use of modern application architectures. Modern application architectures require moving away from monolithic applications and embrace service based architectures.
Tenet #3. Scale your Organization Using Moder n Processes.
You cannot build modern software unless your development organization makes use of modern processes and procedures. This includes service ownership responsibilities and development processes.
Tenet #4. Use Risk as a Tool.
All complex systems have risk. It’s impossible to remove all risk from a complex system. Instead, we must learn to manage the risk and use risk as a tool for evaluating technical debt and making decisions on application improvements.
Tenet #5. Utilize the Cloud.
High availability in a modern application requires nimble scaling. We can no longer afford to have excess infrastructure capacity lying around to meet the peak needs of our application. Instead, we must dynamically allocate and consume infrastructure resources, on demand, based on our current needs. Dynamic infrastructures, and applications that can support and optimize dynamic infrastructures, are a core requirement for modern applications.
These are the five critical tenets to building applications that meet the modern needs of our customers. These are the five critical tenets to Architecting for Scale.
Each of the next five sections of this book is dedicated to one of these tenets. Each section has multiple chapters that expand on the section’s tenet.