Prior to joining CloudHealth, I worked at a startup that developed and sold an enterprise DevOps platform. One thing I learned pretty quickly (and eventually blogged about) was the propensity for users to try to build release orchestration and/or deployment automation tools themselves. I mean, sure, there are plenty of open source tools available, and some are actually really good. But I saw firsthand when talking to new customers that many of them had gone down the path of using multiple free tools, stitching them together with scripts, only to buy our platform later because they underestimated how much effort and cost it would take to build and maintain their own software.
In their own words, “free” is actually really expensive. And they simply couldn’t afford “free” anymore.
Less than a year into my time at CloudHealth, and I’m seeing the exact same story play out. In fact, CloudHealth surveyed ~500 companies that considered using native and free tools for public cloud management and found that 10% of respondents chose the DIY path. CloudHealth has previously written about “Avoiding the Pitfalls of DIY Public Cloud Management,” but I think it’s a topic worth re-visiting since customers may be exploring the DIY approach again for a number of reasons:
Why organizations think to go DIY or native
First, free native tools provided by the public cloud providers continue to add more functionality. As an example, companies can use AWS native tools to build their own cost reporting. AWS provides accessible APIs enabling you to build reporting around your cost and usage report (CUR) file.
Cloud management platform costs grow in parallel to their cloud costs. As companies scale their cloud services and infrastructure, the cost of their cloud management platform grows as well. We’re in an explosive cloud growth phase so it’s natural and smart to constantly re-assess cloud management tools and the value they provide.
Companies identify unique requirements. As cloud usage scales, organizations are working harder to integrate their cloud management software with their other internal systems. Examples include IT service management (ITSM), ticketing systems, procurement, identity and access management (IAM), and many more. Some companies believe that it would be easier to integrate with their internal systems if they build and maintain their own platform and/or build custom integrations or write scripts for their unique requirements.
When the challenges of DIY become too great
At my past role, I was able to speak to customers that had used our platform, then left because they felt that free tools had advanced enough for them to build their own tool cheaper. They ended up returning as customers for a couple reasons:
- High cost – Building and maintaining their in-house software required multiple full-time employees at a huge annual cost. Plus, they were spending a big chunk of their budget serving a custom-built software platform.
- Poor scalability – They found it nearly impossible to scale the platform. Even with full-time staff dedicated to supporting multiple native tools and scripts, the in-house software could not meet demand.
- Lost productivity – Substantial development resources were dedicated to building and maintaining the in-house tool rather than building new, value-adding software.
Here at CloudHealth we’ve got a couple customer examples where they experienced similar results.
In the first example, a customer of ours had some staff turnover and the new leadership team naturally asked why, when there are free tools available, they were paying for a cloud management platform. So, they began to evaluate the native AWS tools to see if they could reduce costs without losing functionality. They learned quickly (even though the AWS tools were very good) that they had additional needs the native tools couldn’t fulfill, and they didn’t have the resources to dedicate to building extensions and internal reports based on the free tools. In fact, CloudHealth and AWS joined together and worked with this customer to show the best approach for their success involved a combination of the two. One of the important factors was CloudHealth’s policy-driven governance capabilities. Due to the customer’s limited resources, the ability to set up policies and automate repetitive tasks and remediation actions was crucial. The customer was also just beginning to expand their use of a second cloud, Azure. They weren’t too anxious to add another set of native tools to their portfolio, making CloudHealth’s multicloud capabilities an important functionality to consider.
The ability to create policies and take automated actions was also a key factor for our second customer example. After evaluating the native tools of their cloud provider, this customer felt strongly that they needed a “set it and forget it” kind of policy-based management and automation solution. They wanted to automate simple things like deleting old snapshots and unattached EBS volumes. They could’ve built their own internal alerting tools, but relayed to us that the CloudHealth platform’s policy and governance engine is a definite step up from a custom-built solution using scripts that they could’ve made.
Speaking of scripts, our third customer example had their own tools for provisioning, usage, reporting, and visibility. This customer was in the software industry, so they naturally had a lot of internal skills and a VP of Engineering who could build and maintain scripts. Problems soon began to surface because other business units and departments like finance couldn’t easily access the data. In addition, the engineering team was spending an inordinate amount of time maintaining these scripts, leaving them less and less time to focus on other strategic tasks. Their policy engine suffered because scripts, as often happens, can’t scale. The engineering team liked having control over the cloud management platform, but it became more expensive to maintain it than the cost of buying a dedicated platform.
Lessons learned from companies who’ve tried (and failed) to go DIY
To wrap up, our customers learned some valuable lessons and shared them with CloudHealth.
You can’t afford free. A DIY platform is much more expensive than you think. You end up with 10s or 100s of thousands of lines of code and a significant part of your budget chewed up servicing the software platform itself. Plus, all that custom code represents potential security and governance vulnerabilities. And how much does it cost you to audit it?
The data is simply not as good. Compared to native tools of the cloud providers, a dedicated cloud management platform like CloudHealth shows actual costs, not just price. CloudHealth reflects actual costs and can present the data via Perspectives that you design. You can drill down into amortized costs, apportioned costs, discounted costs, etc. And CloudHealth can feed data into your business intelligence (BI) dashboard.
Policy-based governance and automation is critical. There’s simply no way to build, maintain, and scale a policy-based governance engine that can virtually eliminate routine tasks like CloudHealth can. Even if you could build something to alert you to aging snapshots, unattached EBS volumes, or open ports, the delay in action costs money.
Cloud native tools for cost reporting have definitely gotten better. But reporting on costs is only one aspect of cloud management. Plus, as soon as an enterprise is using multiple public clouds, every DIY challenge of native tools, spreadsheets, and scripts becomes magnified. A comprehensive multicloud management platform helps build an overall culture of accountability where every team is represented in a Cloud Center of Excellence (CCoE) and contributes to and adopts best practices. It can be difficult to put a price on that. But, as some of our customers have shared, “free” can be an awfully high price to pay.
