Microsoft Azure is a cloud computing platform that offers a wide range of tools and services to help organizations build modern applications that can drive digital business success. Azure provides a scalable and reliable platform that can be used to develop, deploy, and manage a variety of applications and services, from web and mobile apps to data analytics and AI-powered solutions. However, due to its complexity, achieving operational excellence in the cloud is difficult. Fundamentally, as a Cloud Operator, you need to ensure great end-user experiences while staying within budget.
In this post, we’ll give you a quick overview of the various methods to optimize Azure cloud costs. However, regardless of what cloud cost management strategy you use, achieving operational excellence at scale and taking advantage of the elasticity of the cloud requires software that optimizes your consumption simultaneously for performance and cost—and makes it easy for you to automate it, safely and continuously. Let’s see how IBM Turbonomic helps customers optimize their Azure cloud costs.
Rightsize Instances
Microsoft Azure’s operating expense model (OPEX) charges customers for the capacity available for different resources regardless of whether they are fully utilized or not. Customers can purchase instances in different sizes and types, but often default to buying the largest instance available to ensure performance. Rightsizing resources is the process of matching instance types and sizes to workload performance and capacity requirements. To optimize costs, rightsizing resources must be done on a continuous basis, however organizations often rightsize reactively like, for example, after executing a “lift and shift” cloud migration or development.
Azure customers can use Azure Advisors rightsizing recommendations to rightsize their Azure virtual machines. These recommendations are generated based on historical CPU utilization to make sure the instance in correctly sized.
Let’s see how IBM Turbonomic helps customers rightsize Azure virtual machines through percentile-based scaling. The diagrams represent the IBM Turbonomic UI. Diagram A shows the application stack. The supply chain on the left represents the resource relationships that Turbonomic maps out from the business application down to the Cloud Region and can include other components such as container pods, storage volumes, virtual machines and more – depending on the infrastructure that supports the application. This full-stack understanding is what makes Turbonomic’s recommendations trustworthy and gives cloud engineer and operations the confidence to automate. For this particular Azure account, Turbonomic has identified 197 pending scaling actions.
After selecting “SHOW ALL” customers are brought to Turbonomic’s Action Center, which can be found in Diagram B below. This diagram represents all of the scaling actions available for this Azure account. From viewing this dashboard, customers can see important information including the account name, instance type, discount coverage, and on-demand cost. Customers can select different actions and execute them by clicking “EXECUTE ACTIONS” in the top right corner.
For customers looking for more details on a particular action, they can select “DETAILS” where Turbonomic provides additional information that it considers in its recommendations. As shown below in Diagram C, this instance needs to be scaled down because it has underutilized IO Throughput, IOPS, vCPU and VMem. Other information for this action includes the cost impact of executing the action, the resulting CPU and Memory utilization, uptime and net throughput.
Public cloud environments are dynamic, and to meet budget and performance goals, Azure customers must scale their instances both vertically (rightsizing) and horizontally. To scale horizontally, Azure users must monitor application load balances and then scale out instances as load increases from increased demand. Distributing load across multiple instances through horizontal scaling increases performance and reliability, but instances must be scaled back as demand changes to avoid incurring unnecessary costs.
For horizontal scaling, Azure users can use Azure Monitor’s autoscaling capabilities. Azure Monitor can scale workloads based on metrics such as CPU usage, queue length and available memory. Users can also scale based on a schedule. Users must configure the metrics considered and schedules in rules.
The only way to optimize horizontal scaling is to do it in real time through automation. IBM Turbonomic continuously generates scaling actions so applications can always perform at the lowest cost. Diagram D below represents an Azure account that needs to be scaled out.
The horizontal scaling action for this Azure account can be executed in the Action Center under the “Provision Actions” subcategory found in Diagram E below. Here you can find information on the actions and the corresponding workload such as the container cluster, the namespace, and the risk posed to the workload, which in this case is transaction congestion.
Diagram E
In Diagram F below you can see how Turbonomic provides the rationale behind taking the action, in this case a container pod needs to scale back its vCPU and Vmem to improve performance. Turbonomic also specifies all the container pod details including the name, workload controller, namespace and container cluster.
Suspend Instances
Another impactful way to reduce Azure spend is to shut down idle instances. An organization may suspend instances if it is not currently using the instance, such as during non-business hours, but expects to resume use in the near-term. When deleting an instance, the instance will be shut down and any data stored on the attached Azure storage volume is also deleted. However, when suspending an instance, users do not delete the underlying data contained in the attached Azure storage volume. Suspending an instance only stops the virtual machine’s compute resources, which include the CPU, RAM, and temporary disk. When you resume the suspended instance, the attached Azure storage volume will still contain the same data that was there before the instance was suspended. The data will be available to the instance as it was before it was suspended, so there will be no data loss or configuration changes.
Microsoft Azure customers can manually suspend Azure virtual machines through the Azure Portal or schedule suspension through the Azure Resource Manager.
IBM Turbonomic automatically identifies and provides recommendations for suspending instances. To suspend a virtual machine with Turbonomic, customers will need to first select an Azure account with a pending suspension action as show in Diagram G below.
To execute a suspension action, Turbonomic customers simply needs to go to the action center, select the corresponding action and execute.
If customers need additional details before executing, they can select the “DETAILS” show in the Diagram I below. The details provided for this action include the reasoning behind the action, in this case to improve infrastructure efficiency, as well as the cost impact, age of the instance, the virtual CPU and Memory and the number of consumers for this instance.
Leverage Discounting
Customers can also leverage discounted pricing through optimizing Azure Reservations coverage and utilization to reduce costs. On Azure, the discount only applies to compute and not the other metrics used to measure usage for Azure virtual machines. When purchasing reservations, users need to determine the VM size to buy. Customers can use recommendations provided from the Azure portal and Azure Advisor to determine the size.
IBM Turbonomic’s analytics engine automatically ingests and displays negotiated rates with public cloud providers and then generates specific reserved instance purchasing and scaling actions so customers can take full advantage of existing RI inventory and maximize reservation-to-instance coverage. Diagram J represents an Azure account that has pending actions to increase RI utilization and coverage.
Diagram K represents the “Buy” actions that can be executed in the action center to increase RI coverage. Some important details listed in the Action Center here are the platform the RI will be purchased on, the term of the RI, the payment type and the region. Diagram L provides more details for this action such as the cost impact and resulting RI coverage. All of this information can again be found in the corresponding “DETAILS” tab.
For longer term commitments, Turbonomic provides reserved instance planning scenarios for added customization. On the Turbonomic platform, users simply select “PLAN” on the dashboard on the left and then select “NEW PLAN.” After selecting “NEW PLAN,” customers can then select the reservation planning option shown below in Diagram M.
First, customers need to indicate the scope of the reservation purchasing plan. We are going to select Azure for this plan. Turbonomic users can also scope by custom groups, accounts, billing families and regions as shown in Diagram N below.
After indicating the scope of the reservation plan, customers can then configure the plan to the preferred offering class, term and payment type shown below in Diagram O. Customers can also customize the historical usage period they want Turbonomic to analyze as well as whether to use data from deleted VMs.
After running the plan, Turbonomic will provide a dashboard as found in Diagram P. In this plan, customers can see the cloud cost comparison currently versus after executing the plan. This comparison covers RI coverage, RI utilization, on-demand compute cost and reserved compute cost. Turbonomic also provides insight on virtual machine mapping and discount inventory.
Finally, Turbonomic summarizes all of the actions that will be executed as part of your VM reservation plan. These actions are summarized under the “PLAN ACTIONS” and are shown in Diagram Q below.
Delete unattached resources
Finally, we will review deleting unattached resources. As organizations build and deploy new releases into their environment, resources left unattached. Unattached resources are when customers create a resource, but stops using it entirely. After development, hundreds of different resource types can be left unattached. Deleting unattached resources can significantly reduce wasted cloud expenditure. Diagram R below shows an Azure account that has 99 pending delete actions to remove unattached resources. Similar to suspending idle instances, Azure Resource Manage also allows customers to delete resource groups. Just as with suspension, Azure Resource Manager will send an alarm to users to delete an instance based off of utilization thresholds.
The delete actions for this account are listed in the Action Center in Diagram S. The information listed in the “Delete” category of the Action center include the size of the EBS volume, the storage tier, the amount of time it has been unattached and the cost impact of removing it.
For additional insight on the impact of these delete actions, again customers can select the “DETAILS” tab and find more information as shown in Diagram T. Below you can the purpose of this action is to increase savings. Customers can also see additional information such as the volume details, whether the action is disruptive, the resource and cost impact.
Azure App Service Optimization
Azure App Service is a fully managed Platform-as-a-Service (PaaS) that allows Azure users to quickly deploy and run enterprise-ready web and mobile applications for any platform or device on scalable and reliable cloud infrastructure. App Service users pay for the compute resources they provision based on the App Service Plan pricing tier they select. Microsoft Azure users can use Azure Advisor and Azure Autoscale to manage their app service plan count and scale based off of CPU and memory usage.
IBM Turbonomic provides continuous optimization you can safely automate to help Azure users get the most out of their PaaS investments. IBM Turbonomic provides dynamic vertical scaling—so App Service plans (ASPs) are never overprovisioned—while also automatically eliminating unused ASPs. Diagram U below shows the action center for Azure App Service scaling actions. In the action center you can see the resulting instance type, vMEM capacity and on-demand price from taking the action.
Diagram V below shows the details for an Azure App Service scaling action. Here you can find the reasoning for the action, which in this case is due to underutilized storage amount, vCPU and vMEM.
Diagram V
Diagram W depicts delete actions for unused Azure App Service plans. The important information you can find in this subsection of the action center is the instance type, the number of days the plan has been empty and the corresponding cost impact of deleting.
Diagram X represents the action details for an ASP delete action where you can see the App Service Plan details and the cost impact of taking the action.
Trustworthy automation is the best way to maximize business value on Microsoft Azure
For cloud engineering and operations teams looking to achieve budget goals without negatively impacting customer experience, IBM Turbonomic offers a proven path that you can trust. Only Turbonomic can analyze your Azure environment and continuously match real-time application demand to Azure’s unprecedented number of configuration options across Azure compute, storage, SQL databases and existing savings inventory. Are you looking to reduce spend across your Azure environment as soon as possible? IBM Turbonomic’s automation can be operationalized, allowing teams to see tangible results immediately and continuously, while achieving 471% ROI in less than six months.1
Want to explore IBM Turbonomic cloud optimization at your own leisure? Try IBM Turbonomic in our live sandbox environment.
Want to learn more about how IBM Turbonomic supports your own specific use-case? Request a demo
#automation-featured-area-1