IBM Turbonomic Optimizes your AWS,Azure, and GCP spend

A client reached out and asked us to help rein in the runaway cloud expenses. Luckily we have a tool just for that. IBM aquired a few years ago and fully integrated into its suite a tool called Turbonomic. The following is the journey and a summary of the results.

"Nearly half of survey respondents (45%) said they’d received a surprise in their cloud bills “a number of times” over the past 12 months, with 70% of respondents noting surprises have happened at least a half dozen times in the past year." [1]

FinOps is an emerging field that takes real-time monitoring of the cloud spend. Turbonomic is a tool that sits 'front and center' in the FinOps instrumentation and also provides optimization recommendation and in some cases fully automated scaling up or down to optimize costs per stated corporate goals balancing speed, performance and revenue.

Turbonomic takes a marketplace view of the various options to buy storage and compute resources. Using a combinatorial algorithm, Turbonomic scans millions of solution alternatives across compute, network, storage and suggests the economical option of VMs to be obtained in the cloud. Consumers using Turbonomic "Market" shop around to find the cheapest providers that satisfy all of their resource and placement requirements. When a cloud entity scales, it is actually "moving" to a new instance type. By shopping and moving to the cheapest provider, consumers are likely get the best available performance while making the best use of available resources and spend less. In this way, your company can spend less on Cloud resources.

Some examples of Placement actions in the Turbonomic 'Action Center':

• Datastores moving between different disk arrays (Move)
• On-Prem VMs moving between different datastores (Storage Move)
• On-Prem VMs moving between different physical machines (Move)
• Container pods moving between different nodes (VMs) (Move)

"In IBM Turbonomic, when an entity wants to change its resource allocation, it generates a?Scaling?action. On-prem VMs and containers generate?Resize Up?and?Resize Down?actions based on their ROI. Cloud entities (VMs, volumes, database servers, etc.) generate?Scale*?actions to assure performance for the lowest dollar cost."

• Cloud volumes increasing storage capacity (Scale)
• Cloud volumes decreasing IOPS capacity (Scale)
• Cloud VMs changing from one instance type to another (Scale)
• Cloud volumes changing storage tiers (Scale)
• On-prem VMs increasing virtual memory or virtual CPU capacity (Resize Up)
• On-prem VMs decreasing virtual memory or virtual CPU capacity (Resize Down)
• Containers increasing virtual memory or virtual CPU capacity (Resize Up)

"Resize Up actions are generated whenever entities become?profitable. Profitability is the market's way of saying that the entity needs more resources to assure performance, and those resources are available. This applies to VMs running on-prem and containers running anywhere. Resize Up actions target the 95th percentile utilization over the last 30 days, both of which are adjustable in Settings. For on-prem entities, Resize Down actions are generated whenever entities become?unprofitable. Being unprofitable is the market's way of saying that the entity does not need so many resources, and these resources can be better used elsewhere. Resize Down actions target the 95th percentile utilization over the last 30 days."

Entities will resize up when they become profitable. When resources are not needed, Resize Down actions are generated for efficiency. Percentiles are used to justify when it is appropriate to resize down resources

"Volume Scale actions are generated when a volume seeks to change its performance level or disk capacity. The Action Details for a Volume Scale action will include such information as graphs for IOPS and throughput utilization, percentiles of utilization, storage tier information, cost data, disruptions, and reversibility. The Action Details for a Database Scale action will include such information as graphs for VCPU, VMEM, and IOPS utilization, percentiles of utilization, database details, cost data, disruptions, reversibility, and resource impacts. Start/Buy?actions are generated whenever more providers are needed to meet the demand of resources. In the Pending Actions widget, the action type will display Start/Buy actions. For on-prem entities in the Action Center, however, these actions will be displayed as?Provision?actions. Entities such as Virtual Machines, Application Components, Hosts, Storage, and more can generate Provision actions. Depending on the entity type, most Provision actions are only in a recommended acceptance mode and cannot be executed in the UI.? A Start/Buy action is?Buy?actions for cloud VMs. These actions will recommend purchasing more Reserved Instances (RIs) from a cloud provider. Reserved Instances are a reservation of cloud resources and capacity that are purchased at a set price for a given time period. These actions are initially investments, but will result in higher savings over time. The Action Details for a Buy RI action will include such information as the RIs to purchase, how many should be purchased, the estimated RI utilization, cost data, and savings data."

"Too much supply or insufficient demand for on-prem hardware will generate?Stop?actions. These actions are also displayed as?Suspend?actions in the Action Center. Suspend actions will recommend powering off hardware to increase the efficiency of the datacenter. Consolidating hardware can result in cheaper costs for electricity and air conditioning over time.?The Action Details for a Suspend host action will include such information as the name of the host to be suspended, the current resource details for the host, the impact the suspend will have on the cluster, and any imported or custom placement policies."

"Reconfigure?actions are generated for actions that are not considered moves, resizes, scaling, provisioning & suspending, or buying. These actions can relate to placement policies, software licenses, network configurations, storage configurations, and more. Reconfigure actions are also displayed as?Configuration?actions in the Pending Actions widget. The Action Details for a Reconfigure action will include such information as the policy or policies being affected, what should be reconfigured, and a reason for the reconfigure."

We conducted a proof of technology followed by a proof of concept followed by prove of value at our client and results are shared below:

We noticed that congestion on 21 out of 32 hosts was reduced using this approach

We also noticed that Ready Queue congestion and host memory utilization reduced.

Conclusion:

Results are very encouraging with $940,000 saved on one cluster. More clusters will be onboarded soon.

References:

1. https://devops.com/survey-much-greater-focus-on-reining-in-it-costs/

Disclaimer: Opinions expressed are those of the author. No warranties express or implied.