Harness Cloud Cost Management

Before Harness CCM focus on providing insights to Developer and Application teams along with leadership . For so long Cost Management got stuck in between Finance teams and leadership . This product broke the barriers by introducing automation capabilities that can actively reduce the cost and take care of the anomalies and do effective idle time management and waste mangement of cloud resources. I also like how Harness CCM provides out of box insights at Name space and service level granularity in a shared kubernetes cluster

What initially appealed most was its perceived potential and the compelling promises made during the evaluation and contract negotiation phase. Specifically, the VM stop-start functionality was a significant draw for us. We were convinced that this feature would enable us to realize substantial savings in VM costs, especially given that many of our development VMs are only used during standard business hours and could be shut down and restarted automatically. This seemed like a straightforward path to significant financial optimization. Beyond just cost reporting, Harness presented a full suite of CI/CD tools, reporting tools, and security tools. This breadth of services was attractive because it gave us the strategic opportunity to potentially expand the scope of the Harness tool beyond our initial focus on cost optimization. We were also highly persuaded by the vendor's strong commitment to customization and dedicated support. We were explicitly told by their lead developer that they would customize anything we wanted and that he would make himself available to us. Additionally, one of their sales engineers assured us that the implementation process was so easy that there would be no need to engage a third party for assistance. These assurances suggested a highly facilitative and accessible partnership, promising an easy working relationship and readily available help without struggle. We were convinced that we would be able to save more than the overall cost of the contract within the first year alone. This belief in significant, tangible cost savings, coupled with the product's advertised functionality and breadth of services, were key factors that drove our decision to purchase. The product functionality and performance, along with organizational viability, were also considered key drivers.

Once set up, the product was simple enough that non-technical people were able to make their own perspectives. The connectors are relatively straightforward to set up and consistently pull in the information needed for visualizations. Liked the ability to pull in kubernetes cluster costs and put those alongside cloud costs. Harness has the ability to calculate how much a service or deployment costs based on their resourcing. This gave us an overall cohesive view of a microservice's cost.

There was no API support to automatically set Connectors when we integrated

My primary dissatisfaction with Harness Cloud Cost Management stems from the tool's fundamental failure to deliver on its core promises and the value we expected, both quantitatively and qualitatively. Despite being initially convinced we could save more than the entire contract cost in the first year through the VM stop-start functionality and reporting, we never saved any real money. The VM stop-start, which was a major reason for our purchase, did not yield the anticipated savings. Furthermore, the reporting capabilities proved to be inadequate and unproductive. Despite our efforts to engage with application owners and executives to understand their specific needs for reporting and alerting, we never managed to get any good reporting out of the tool. This directly impeded our goal of gaining clear insight into our cloud spending. A significant source of disappointment was the stark discrepancy between the vendor's initial assurances and the actual implementation experience. We were repeatedly told that the implementation would be straightforward and that engaging third-party assistance would be unnecessary due to its simplicity. However, in reality, the implementation went so poorly that we never actually got to effectively use the product's full capabilities as intended. This fundamental failure meant the product did not scale with our business growth as we had hoped. Instead of upgrading or expanding its use, we opted to discontinue it entirely, which involved deleting the application and writing off a significant portion of the contract as a sunk cost. The lack of actual value delivered meant that our ROI expectations were entirely unmet, both in terms of quantitative savings and qualitative user satisfaction. Users were genuinely unhappy with the product because the reality of its performance and our interactions did not match the initial discussions.

The product could use more native integrations with other development costs beyond cloud costs. For example, our teams would love to be able to integrate CCM with our other vendors who manage our metrics, logging, alerting, etc. It would also be nice to pull in Harness costs into CCM, such as a way to calculate the cost per service instance and attach that to a perspective. Autostopping was difficult to get working. While initially simple to set up, it was apparent that not all the features were fully fleshed out yet. We ran into issues with the traffic detection not working, the ability to pause and unpause autostopping rules, and fixed schedules not exactly working. It would also be great if autostopping had the feature to reduce a kubernetes service to a single pod, rather than taking the entire service offline. Recommendations could be more fully fleshed out. Some of the savings being displayed were not entirely accurate, as we it took the highest number of instances used that month even though we had scaled it up and down respectively.