How to scale: a seven-bullet checklist

The ultimate checklist for scalability in the cloud.

Scaling is a necessity when your application or auxiliary components become saturated and get to handle more throughput than it can process. To scale or not to scale is therefore a question that we receive on an almost daily basis.

Scaling: A Recap

This post will give you a checklist you can use to determine what kind of scaling to use, and how….
But, before we start, a quick review of what we are talking about here: Scaling can be viewed over two different axes: vertical and horizontal, or a combination. As a metaphor, think of your machine as a balloon, its specifications [memory, CPU and disk] being the properties used to indicate the size of the balloon.

Vertical scaling
If you want to scale vertically you either inflate or deflate the balloon. In other words, you add or subtract capacity to/from the machine: Chose any of the machine’s attributes and increase or decrease its value (even to the point where you go below the original specification). This is also called scaling up and down. Vertical scaling is typically considered the most simple to achieve, often requiring no changes to your operating system or application.

Horizontal scaling
If you want to scale horizontally you basically add one or more balloons next to the one(s) you already have. In other words: you add more machines of similar specifications. This is also called scaling in and out. Scaling horizontally is typically used when you need to distribute workload across multiple servers, for example in a webserver farm, a NoSQL cluster, or processing cluster.

The combination of both vertical and horizontal scaling leads to a number of machines of possibly varying specifications, that may, in fact, vary during their lifetime. From an infrastructural point of view virtualization, scaling vertically or horizontally should not be hard to achieve these days; your virtualization or cloud vendor should simply support both, and preferably online too where applicable.

The difficulties: Caught between a rock and a hard place.

However, at some point, with both vertical and horizontal scaling, you will find yourself caught between a rock and a hard place. Your application will very likely seem to be unable to handle more load when you try to scale further at some point. In fact, your total throughput of your servers may go down when adding a server beyond a certain invisible barrier, sometimes referred to as the scalability barrier. This is caused by the effects of Amdahl’s Law, that says that the non-parallelizable [non-distributable] parts of your application have a disproportionally negative effect on the total throughput.

Amdahl's Law [Source: Wikipedia]

The ultimate seven-bullet checklist to make the right scaling choices.

The above is the crucial factor in defining the choices about what scaling pattern to use. So having set the stage here, how do I decide what kind of scaling to use and when?

It’s not an easy question to answer, there´s a lot of non-triviality thrown in the mix here, and involves many factors. However, our team typically uses the following ultimate checklist to make some key decisions, maybe it comes in handy for you as well.

[1] Find your current processing ability and needs, and dig up any projected forecasts.
  • Is your growth pattern predictable?
  • Does your growth pattern have predictable peaks for which you must prepare?
  • Does your growth pattern have unforeseen peaks for which you need to be ready by the time they happen.

  • [2] Analyze the application-architecture in high-level. This helps you determine if the application would scale vertically or horizontally or both, e.g:
  • A shared-nothing architecture will scale better horizontally than an architecture with physical tiers that form a mesh or go through funnels to communicate [such as shared load-balancers, or a high-latency network connection]
  • Stateless webservers would scale better horizontally than a cluster that needs a shared storage for maintaining state.
  • A NoSQL database would scale better than a typical RDBMS.

  • [3] Find which components you can and need to scale, based on [1] and [2].
  • Do you need to keep your application on-premise?
  • Can you use a hybrid approach to scaling and move just some components to the cloud for this purpose. Is it just that webserver that needs scaling or do you need to go full monty and need to deploy the entire infrastructure in the cloud?

  • [4] Analyze these application-component[s] in more detail, and ask yourself these questions:
  • Do these components (seem to) constrain you from scaling vertically?
  • Do they lend themselves to take benefit of additional capacity in the machine?
  • Do they lend themselves for online or offline scaling?
  • Do these components (seem to) constrain you from scaling horizontally?
  • Do they use hardcoded IP-addresses, URL’s or other references that tie machines down or enforce connections to specific infrastructural elements?
  • Do they rely on static, centralized resources, such as a shared database, forming many-to-one communication topologies?

  • [5] Deploy your application in the cloud, if you’re adopting a cloud-strategy for scaling.
  • Set up your desired hybrid or full-cloud environment.
  • Deploy the application there.

  • [6] Start turning the knobs. Find out what’s best for your application [and for you]. Go for simple heuristics – trial and error, and match capacity against the projected needs. A good example of this is the TeraGen / TeraSort test that is conducted often to measure the performance of a Hadoop cluster. The number of variables that you can tweak against the specifications or number of machines that you can use in a cluster may lead to large quantity of tests before you found the optimal conditions.

    Your cloud vendor should ideally support scaling in an online fashion, meaning scaling (horizontally or vertically) without having to switch down machines.

    [7] Cloudify, if your application cannot walk the walk yet. This means you need to break down the scalability barriers to make it more ready for scaling. This may involve:
  • Deciding to move more application components to the cloud, to reduce latency or scale these components independently,
  • Application refactoring, for example by introducing caching, or reworking the application even more drastically to accommodate for your needs,
  • Using tools like our Cloud Application Controller that assist in making applications cloud-ready, but can also help in making scaling possible.
  • Leave a comment

    Your email address will not be published.


    You may use these HTML tags and attributes:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>