Control VM Sprawl with Expiration Dates
Public clouds provide an easy path to deploying virtual machines (VMs), but this ease of deployment, if not properly managed, can lead to a proliferation of uncategorized, mysterious, and often expensive VMs. This reviled situation is known as VM Sprawl.
Networking Appliance Company: Case Study
Case in point, a major networking appliance company had adopted public cloud usage team by team, and wound up with more than a dozen AWS, Azure, and GCP public cloud accounts. The result was multiple interfaces to see and manage all of their VMs, and no unified way to track each VM’s purpose, owner, or lifecycle. The inability to gain visibility into their VMs was costing the enterprise IT team money and time, and exposing them to unnecessary security risks.
Step 1: Automatically Set Expiration Dates
The first step they took to get control over the situation was to install CloudBolt and to connect it to all of their public cloud accounts. When connected to a virtualization system or public cloud account, CloudBolt automatically discovers all of the VMs, networks, images, etc, and begins tracking and reporting them. Standing up CloudBolt and connecting all of their public cloud accounts took less than half a day and gave the IT admins a single web interface where they could see all of their resources across their various public cloud accounts. It’s worth noting that CloudBolt synchronizes with the providers’ inventory every 30 minutes, so if a user powers off a VM, creates a new one, or changes an existing one (ex. adding memory to it), that change will appear in CloudBolt within half an hour.
Step 2: Plug-in
Next, the customer added a post-sync plug-in to CloudBolt that automatically set expiration dates on all of their VMs (here’s a sample CloudBolt plug-in that can be used as a starting point). They then emailed all of their developers and other users of the public clouds to let them know that their VMs would be turned off in 60 days, unless they went into CloudBolt’s web UI, claimed their VMs, and changed or removed the expiration date.
This step was extremely valuable to the organization as it allowed them to know which of their VMs were still needed, and which users and groups they belonged to. By the 60 day mark, they saw that half of their public cloud VMs were powered down, drastically reducing their public cloud costs. CloudBolt’s discovery and expiration date management had enabled the equivalent of sticking a post-it note on the shared refrigerator saying “Unclaimed food will be discarded Friday at 5pm”. The end result: chaos became order, their costs decreased drastically, no important VMs were lost, and the clean up took place without incident.
Step 3: Compare Before & After Costs
After these two steps, the IT department was able to contrast their pre-CloudBolt public cloud bills with their post-CloudBolt bills and present the savings to their peers and management. The strong accolades and recognition received for their work enabled the IT team to continue with additional improvements.
Self-Service IT & Power Schedules
Another improvement made was the roll-out of self-service provisioning of resources in any public cloud or any of their private virtualization systems (VMware and OpenStack). Depending on the group and the environment for the new resources, expiration dates with maximum lengths were set up to be enforced by CloudBolt (here’s a video on how those expiration dates are set up).
In addition, the team set up automated power schedules in CloudBolt so it would turn off VMs when they were not in use (saving even more money), implemented limits & quotas on groups and environments, and added approval processes for any orders in production environments.
Conclusion
For this IT department, striking back against VM sprawl saved money, time and increased visibility, and also greatly enhanced navigation of the infrastructure. Now, anyone with appropriate permissions can see which VMs belonged to who, how they are changing over time, plus notes detailing their purpose.
CloudBolt also allowed the entire IT organization to collaborate and troubleshoot more effectively. It established a common interface for cross-team collaboration, where IT and their internal customers gained a common control plane for infrastructure and applications. Their DevOps practices were advanced and CloudBolt provided them with a place to automate and standardize their practices and processes.
Related Blogs
Cloud Automation and Orchestration: A Comprehensive Guide to Streamlined IT Operations
As businesses increasingly adopt cloud technologies, managing these environments has become more complex. To optimize resources, reduce costs, and accelerate…