Whether you are serving consumers visiting your website or internal customers accessing infrastructure services, customers want the ability to access what they want when they want it. As a result, scalable architecture is top of mind for many organizations -- especially those who face peaks in traffic and must be able to effectively service it. Designing for scalability, the ability to handle large amounts of traffic and service it gracefully, without degradation of performance or downtime, is an essential component of successful service delivery.
There are two strategies to ensure websites, or infrastructure generally, scale. We will discuss these strategies here as well as share some examples of organizations that applied them and how you might go about approaching these strategies yourself.
Strategy 1: Reactive
This strategy makes it easy to be user-scalable (i.e. serve more people) by simply adding compute power, or in the case of public cloud, more instances While this strategy obviously drives up costs, it does maintain the customer experience. While some people think of this strategy like the proverbial duck on water, where everything appears to be business as usual, there can definitely be some fast paddling beneath the surface.
For example, we worked with a customer that found a bug in their application that caused scalability to dramatically decrease. A web-based reviews organization that many people depend on when making purchases, a scalable website was a non-negotiable business imperative. Although this bug threw efficiency out the door, the team was able to maintain application response times by adding (many) more compute instances (~700% increase) to ensure they were able to service demand through a peak period. While they ended up spending quite a bit to manage the situation this way, their customers were none the wiser.
Implementing a reactive strategy means the ability to quickly add infrastructure. If your organization is an AWS customer, you can spin up new servers to increase capacity. If adding new servers is time-consuming, that is a problem and automation can help. With automation, servers come up quickly, addressing the scalability issue rapidly.
A more real-time option is AWS autoscaling. When enabled, your team doesn’t need to do anything. When a resource need arises, automation bootstraps and the issue is resolved. Even for systems not horizontally scaling, such as databases, this public cloud approach is helpful. For example, if the database is a choke point, there are a number of database scalability techniques that can be employed. In the cloud you can purchase resources to increase power instantly. Whereas in traditional data centers you’d have to buy new hardware, a solution that is rarely possible to do quickly. Check out our AWS Database Services for more information.
Strategy 2: Proactive
Organizations that implement this strategy take steps to improve the efficiency of their existing resources. They use caching and other smart strategies, (like taking the time to fix bugs), to serve more people -- and with less expense. By making the individual components more efficient, these organizations can serve more users with the same resources.
With this strategy, you may still need to add resources when traffic increases, but its rare. Doing more with less allows you to use your resources more efficiently and strategically.
There are several techniques Flux7 customers use to implement this scalability strategy:
- Use caching applied at multiple layers. At the top-most layer, they take advantage of a content delivery network (CDN) like Amazon CloudFront, which caches requests, so when a similar request comes in, they can serve it without actually touching servers. Because the content is served by the CDN, not servers, this approach is very efficient, highly scalable, and even serves to improve the customer experience.
- Use caching between an application(s) and database(s). Most commonly used is Amazon ElastiCache which caches regularly accessed data so you don’t have to make a roundtrip to the database. This decreases the number of requests to the database, and as a result is much more efficient, allowing organizations to serve more users from any size database. In addition, some databases scale better than others. For example, NoSQL, DynamoDB, MongoDB or Cassandra all allow for horizontal scaling, allowing you to proactively add more nodes during a reactive, ‘add more resources’, phase. Alternately, we see customers using Aurora DB as it can handle more traffic at smaller size.
In opposition to both these strategies is the organization that is not efficient nor able to add more resources. This sort of paralysis is a recipe for failure and one we dissuade every chance we get. Really, organizations need to at the very least be able to add new resources; those that can’t are in real need of adopting either of the above strategies before it’s too late.
For example, we talked a while ago with a leading retailer whose ecommerce site crashed during the Thanksgiving holiday. Over that weekend, they expected x-number of people to visit their site. However, the site wasn’t scalable and so when x+ number of people showed up, the website crashed. Either the retailer incorrectly predicted their holiday traffic or their technology simply wasn’t ready. Their 2016 Q4 earnings reflected the impact of this problem. Today, this retailer is closing hundreds of stores nationwide. I suspect one of the reasons why is that they simply could not move fast enough and embrace at least one of these two strategies when it came to their ecommerce site.
At Flux7, our DevOps experts highly recommend a proactive approach to website scalability. Embracing automation, efficiency, and proactivity will not only keep your customers happy, but will also save you money and grow your ability to be strategic. If your organization is not yet able to get its arms around proactivity, being able to add resources on the fly as demand increases, is critical. In either case, you improve scalability and ensure a positive customer experience. To learn more about growing your organization’s scalability and efficiency with DevOps and AWS services, please subscribe to our blog below.