How to Contain DevOps Costs: 5 Tips

The public cloud takes away many infrastructure-related headaches and allows you to focus on value-added efforts, such as devops practices, which thrive in that context. But public cloud opex still needs to be watched and managed.

Why? Because budget blowouts do occur. If you’re in an organization that needs to reduce the cost structure of your public cloud-enabled DevOps efforts, read on and see if you’re overlooking any of these cost-containment strategies:

Turn off the VMs. Among DevOps scenarios, only staging environments might need to run 24/7, and that for just limited periods of time. Development and testing environments are unlikely to require continuously running VMs. Given a standard 40-50 hour work-week, a simple disciplined approach to turning off compute resources when not in use, perhaps in an automated way, could save 60 percent or more of the resources for which you may be otherwise charged.

Autoscale. Many businesses have peaks and troughs. Building your production environment for the peaks, however, will result in a tremendous amount of wasted capacity and unnecessary costs. What autoscaling can do is accommodate the ebbs and flows, adding servers when you need them and turning them down when the busy cycle passes. You can program for known patterns or use triggers to activate scaling, and then keep scaling until the symptoms go away.

Mind your GETs. Secondary and archival storage pricing on the public cloud starts low, but the PUT requests that move TBs of post-processed data into cold storage differ from the GET requests that let you extract or download your data. If you are going to need regular downloads or anticipate moving your data somewhere else, then you should expect to incur more costs. Of course, it’s best to understand your design upfront and pair workflows with the most appropriate resources.

Manage Sprawl. Adding VMs is quick and easy, maybe too much so. If there is no ongoing reporting or awareness, then whoever gets the invoice may be in for a surprise, especially if there are twice as many VMs up and running as were budgeted. Plus, these resources may be “forgotten” and not shut down when not needed. The solution is a system of checks and balances that minimizes speed bumps while maintaining control and governance.

Avoid Security Gaps. How consistently are your corporate-wide security policies enforced? When you or your team create a virtual local area network (VLAN) to support a set of newly spun-up VMs, are you copying over the full set of applicable policies? If not, then you’re exposing your enterprise to external rogue elements that can quickly identify network security gaps, breach your defenses and increase the costs (in this case, indirect) of your DevOps environment.

(For a longer discussion of this topic, see the article I wrote for InfoWorld titled, “5 Ways to Reduce Devops Costs.”)