Situating your IT business processes in the cloud offers flexibility, access to almost unlimited services and capacity when required. Development and growth of your business need to be planned to optimize performance against costs. Over/under server utilization can go undetected if not evaluated, leading to disproportionate costs that don’t reflect the real needs of your business.
Downsizing instances is an approach that aims to find the most efficient deployment in terms of saving costs while trying to maintain reasonable system performance, but it isn’t free of debilitating limitations. This article will explore what downsizing is, its pitfalls, and an alternative, more effective approach – Cloudyn’s SmartSizing.
Downsizing Your Cloud to Save Costs
Downsizing today can simply be defined as “optimizing deployment”, and is available through most cloud cost monitoring systems. It works by looking through your collection of cloud resources and analyzing their usage before shutting down or scaling down the ones that are running on low utilization levels for long periods of time.
Say for example that you have an AWS m3.2xlarge instance and are recommended to downsize to an m3.xlarge instance instead. The logic here is simply to save on costs. If CPU capacity is not fully utilized, you are paying for capability that is not being used and, therefore, wasting a portion of your budget that could be more effectively placed elsewhere. By downsizing, you adjust to actual workloads and have optimal deployment…right? Turns out it’s not that simple. Though important, downsizing isn’t a complete approach.
The 3 Pitfalls of Downsizing
1. It doesn’t look at the whole picture
Due to the fact that downsizing views all instances as plain servers, it looks at the hard numbers of CPU utilization and bases its analysis and recommendations on those metrics alone, without taking other parameters into consideration. It doesn’t recognize the distinctions between the metrics and can therefore only give general recommendations. This approach leaves out important details such as the role of the server, how many similar servers exist on the same application layer, or different use cases or services.
It is extremely important to look at where servers are placed within an architecture and what their specific roles are before issuing sizing recommendations. Downsizing a single instance when a web server layer is underutilized is not the most effective approach. In this case, we would want to resize the whole web server layer and not just a single instance, because resizing a single instance could cause performance issues due to unbalanced loads.
IT directors need to know more about how resources fit in with the whole context of their systems. That way they can have a better understanding of the application and cluster costs, optimizing on the whole (according to the SLA, for example) rather than simply trying to downsize certain aspects. The same can be said for high-performance computing or batch processing where a cluster of computers are working in parallel. You need to be able to downsize the whole cluster and not just an individual server within it.
2. It only suggests downsizing in the same instance family
It is obvious that to optimize your deployment, all performance metrics need to be considered (RAM, network level, IO communication with storage, etc.) before providing a recommendation. However, in most cases, downsizing happens within the same instance family, which might not be enough.
Let’s look at a general purpose instance from the M3 family, for example. Your cloud cost monitoring system identifies that its CPU usage is underutilized, so the common approach is to downsize within the same instance family. It won’t notice, however, that RAM is being overutilized and should, therefore, be resized to a RAM optimized family, a different instance family altogether. Performance may be optimized in terms of CPU, but you could be inadvertently taking a hit due to RAM overutilization. Changing the instance family could keep costs on the same level while enhancing performance as a whole.
3. Only suggests downsizing (not upsizing)
If your instance is reaching its maximum utilization, you may be required to upsize, but since most cloud cost monitoring systems simply look for opportunities to cut costs, you won’t be recommended to do so. Unless you have auto-scale (or something similar) enabled, monitoring systems will not even issue an alert to let you know that your instance is being overutilized. Cloud optimization is not just about optimizing costs…it’s about balancing costs with performance. After all, if your applications are not performing properly, your business may suffer loss of revenue.
The solution – Cloudyn SmartSizing
SmartSizing is a new optimization method from Cloudyn that includes solutions for all of the pitfalls mentioned above, and more. By looking at deployment holistically and offering recommendations accordingly, costs and performance can be balanced harmoniously. SmartSizing considers the context of an environment as well as each server’s role, and is open to the option of moving a server down a notch, two notches, or to a different instance family altogether.
SmartSizing helps you find that sweet spot where cost and performance are optimized. Finding the balance no longer needs to be a constant battle. Recommendations may include upsizing, or paying more in some cases, but only if that is the most productive option for your system. It’s a logical conclusion that when your business starts to grow, your cloud service costs will increase as well. SmartSizing helps you align the growth of your cloud with the growth of your business for fully optimized deployments.
Start SmartSizing™ Your Cloud Deployment
Start a 20-day free trial to identify opportunities for greater cloud-efficiency and view your entire cloud deployment in one place. Gain full transparency, accountability and control.