Platform, cloud, and DevOps engineers run into scalability challenges on a regular basis. It is difficult to predict growth rates of applications, storage capacity usage, and bandwidth in modern distributed architectures. When a workload reaches capacity limits the question is how is performance maintained while preserving efficiency at 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 have to be made about what kind of scalability is needed to meet demand and how to accurately forecast reservations or track on-demand expenditures.
Turbonomic can help you make sure you’re picking the best options in your cloud journey. Get started by trying the IBM Turbonomic Sandbox or Request your IBM Turbonomic demo today!
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 cloud native applications. In this article, we are going focus first on comparing scale-up vs scale-out.
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 it was 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 datacenters 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.
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 or container pods) or use 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 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 an efficient use of scaling within a given infrastructure.
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 charge 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 Turbonomic can help. It not only helps you simplify your AWS and Azure billing but, it can let 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 is ensured.
For today’s cloud consumers and 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. Get started by trying the IBM Turbonomic Sandbox or Request your IBM Turbonomic demo today!
Adapted from an original post authored by Leah Schoeb
#Turbonomic
#Cloud