Leaving cloud scalability to automation

Leave the scalability of the cloud to automation

Automation is a great tool. Instead of solving a problem once, you can automate a solution to automatically adapt to changing needs, without the need for a human being.

The scalability of the cloud is the best example of this. It is no longer necessary to manually provision finite static resources such as storage and compute. Instead, we’ve set up automation (typically provided for us) that can leverage as many resources as needed without developers or architects thinking about it.

The number and types of automated scaling mechanisms vary widely, but serverless is the best example of automated scaling. With serverless computing now part of the standard infrastructure, such as storage and provisioning of compute resources, it is now also part of the container, database and network. Many resources that were previously statically configured can now “automatically” configure and supply the exact number of resources needed to perform the job and then return them to the pool after use.

Very soon, it will be easier to list the number of resources that are not serverless, as cloud service providers are all about serverless and serverless cloud services are increasing every month. The serverless computing market was worth an estimated $ 7.29 billion in 2020. In addition, it is expected to maintain a compound annual growth rate of 21.71% for the period 2021-2028. serverless will reach a value of $ 36.84 billion by 2028.

So the question is, are we always affordable and fully optimized in terms of spending and resource usage, leaving scalability to automated processes, such as serverless and cloud-native autoscaling?

Of course, this is a complex issue. There is rarely a correct path, and scale automation is no exception.

The pushback on automated scaling, at least “always” linking it to cloud-based systems to ensure they never run out of resources, is that in many situations system operations will not be cost effective and less than efficient. For example, an inventory control application for a retail store may need to support 10 times the amount of processing during the holidays. The simplest way to ensure that your system can automatically provide the additional capacity needed in the event of seasonal peaks is to leverage automated scaling systems, such as serverless or more traditional autoscaling services.

The problems arise from the cost optimization analysis of that specific solution. Suppose an inventory application has built-in behaviors that scale automation detects as requiring more compute or storage resources. These resources are automatically provisioned to support the expected additional load. However, for this specific application, behaviors that trigger the need for more resources do not actually require more resources. For example, a momentary spike in CPU utilization is enough to bring 10 additional compute servers online to support a resource expectation that isn’t really needed. You end up paying 5 to 10 times as much for resources that aren’t actually being used, even if they are returned to the resource pool moments after provisioning.

The key point is that using autoscaling mechanisms to determine resource needs isn’t always the best way to go. Leaving automation to scale alone means that the likelihood of providing too many or too few resources is much higher than if the resources were provisioned according to the exact needs of the application.

So, we can turn on autoscaling, let the cloud provider decide, and end up spending 40% more, but never worry about scaling. Or we can perform more detailed system engineering, match the resources needed, and deliver those resources in a more accurate and cost-effective way.

There is no answer here. There are some systems I build that are much more reliable and cheaper with automatic scaling. They are often more dynamic in their use of resources and it is better for some process to try to keep up.

But we’re leaving money on the table for many of these use cases. Most system capacity calculations are well understood and therefore the number of resources required is also well understood. In these cases, we often find that if we take back control of resource provisioning and de-provisioning, we are left with more cost-effective approaches to cloud-based application deployments that can save hundreds of thousands of dollars over the years. I’m just saying.

Copyright © 2022 IDG Communications, Inc.

Leave a Comment

Your email address will not be published.