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 RecapThis 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.
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.
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.
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.
 Find your current processing ability and needs, and dig up any projected forecasts.
 Analyze the application-architecture in high-level. This helps you determine if the application would scale vertically or horizontally or both, e.g:
 Find which components you can and need to scale, based on  and .
 Analyze these application-component[s] in more detail, and ask yourself these questions:
 Deploy your application in the cloud, if you’re adopting a cloud-strategy for scaling.
 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.
 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: