Cloud scalability: Scale-up vs. scale-out

IT Managers run into scalability challenges on a regular basis. It is difficult to predict growth rates of applications, storage capacity usage and bandwidth. When a workload reaches capacity limits, how is performance maintained while preserving efficiency to scale?

The ability to use the cloud to scale quickly and handle unexpected rapid growth or seasonal shifts in demand has become a major benefit of public cloud services, but it can also become a liability if not managed properly. Buying access to additional infrastructure within minutes has become quite appealing. However, there are decisions that must be made about what kind of scalability is needed to meet demand and how to accurately track expenditures.

Scale-up vs. Scale-out

Infrastructure scalability handles the changing needs of an application by statically adding or removing resources to meet changing application demands, as needed. In most cases, this is handled by scaling up (vertical scaling) and/or scaling out (horizontal scaling). There have been many studies and architecture development around cloud scalability that address many areas of how it works and architecting for emerging cloud-native applications. In this article, we are going focus first on comparing scale-up vs scale-out.

What is scale-up (or vertical scaling)?

Scale-up is done by adding more resources to an existing system to reach a desired state of performance. For example, a database or web server needs additional resources to continue performance at a certain level to meet SLAs. More compute, memory, storage or network can be added to that system to keep the performance at desired levels.

When this is done in the cloud, applications often get moved onto more powerful instances and may even migrate to a different host and retire the server they were on. Of course, this process should be transparent to the customer.

Scaling-up can also be done in software by adding more threads, more connections or, in cases of database applications, increasing cache sizes. These types of scale-up operations have been happening on-premises in data centers for decades. However, the time it takes to procure additional recourses to scale-up a given system could take weeks or months in a traditional on-premises environment, while scaling-up in the cloud can take only minutes.

What is scale-out (or horizontal scaling)?

Scale-out is usually associated with distributed architectures. There are two basic forms of scaling out:

◉ Adding additional infrastructure capacity in pre-packaged blocks of infrastructure or nodes (i.e., hyper-converged)

◉ Using a distributed service that can retrieve customer information but be independent of applications or services

Both approaches are used in CSPs today, along with vertical scaling for individual components (compute, memory, network, and storage), to drive down costs. Horizontal scaling makes it easy for service providers to offer “pay-as-you-grow” infrastructure and services.

Hyper-converged infrastructure has become increasingly popular for use in private cloud and even tier 2 service providers. This approach is not quite as loosely coupled as other forms of distributed architectures but it does help IT managers that are used to traditional architectures make the transition to horizontal scaling and realize the associated cost benefits.

Loosely coupled distributed architecture allows for the scaling of each part of the architecture independently. This means a group of software products can be created and deployed as independent pieces, even though they work together to manage a complete workflow. Each application is made up of a collection of abstracted services that can function and operate independently. This allows for horizontal scaling at the product level as well as the service level. Even more granular scaling capabilities can be delineated by SLA or customer type (e.g., bronze, silver or gold) or even by API type if there are different levels of demand for certain APIs. This can promote efficient use of scaling within a given infrastructure.

IBM Turbonomic and the upside of cloud scalability

The way service providers have designed their infrastructures for maximum performance and efficiency scaling has been and continues to be driven by their customer’s ever-growing and shrinking needs. A good example is AWS auto-scaling. AWS couples scaling with an elastic approach so users can run resources that match what they are actively using and only be charged for that usage. There is a large potential cost savings in this case, but the complex billing makes it hard to tell exactly how much (if anything) is actually saved.

This is where IBM Turbonomic can help. It helps you simplify your cloud billing lets you know up front where your expenditures lie and how to make quick educated choices on your scale-up or scale-out decisions to save even more. Turbonomic can also simplify and take the complexity out of how IT management spends their human and capital budgets on on-prem and off-prem infrastructure by providing cost modeling for both environments along with migration plans to ensure all workloads are running where both their performance and efficiency are ensured.

For today’s cloud service providers, loosely coupled distributed architectures are critical to scaling in the cloud, and coupled with cloud automation, this gives customers many options on how to scale vertically or horizontally to best suit their business needs. Turbonomic can help you make sure you’re picking the best options in your cloud journey.

Source: ibm.com