What is Collaborative Cloud Cost Management, and Why It Matters
Collaborative cloud cost management is a new and incremental tactic to help organizations improve their cloud cost efficiency.
Cloud computing has revolutionized the way businesses develop and deliver products and services. It offers unprecedented scalability, flexibility, and agility, enabling faster time to market and innovation. However, cloud computing also comes with a significant challenge: cloud cost management.
Cloud cost management is the process of monitoring, analyzing, and optimizing the spending on cloud services. It involves understanding the usage patterns, consumption trends, and allocation of cloud resources across an organization. Cloud cost management helps businesses to reduce waste, improve efficiency, and align cloud spending with business goals.
Traditionally, cloud cost management has focused on waste reduction efforts, such as eliminating under-utilized or forgotten resources and optimizing purchasing decisions (e.g., reserved instances and savings plans). There are a great many cloud cost management tools available in the market to serve this function. However, often these tools are designed for centralized operations and finance teams.
Centralized approaches to managing costs have proven effective at generating actionable savings recommendations and high-level views, but this approach can face limitations when used in isolation at firms that operate at a scale beyond an early mid-market enterprise.
For example, savings recommendations often cannot be implemented unilaterally. Instead, they require coordination with multiple stakeholders. Further, today’s cloud optimizers may not address every scenario nor anticipate challenges implementing recommendations. Finally, centralized approaches to governance originally developed for on-prem resources can reduce organizational agility by delaying launch times or adding burdensome steps and, in some cases, can create misaligned incentives that end up generating increased costs.
Instead of a purely centralized approach to cost management, consider layering on the emerging practice of collaborative cloud cost management.
Collaborative cloud cost management refers to the practice of making the application and data engineers who create, deploy and maintain cloud applications aware of the impact of their decisions on cloud costs, and empowering them to take action in order to improve efficiency.
These engineers can make a significant impact on cloud costs given their role in the software development lifecycle; however, they typically lack the visibility and in some cases control they need to effectively contribute to cloud cost management. Often, they do not have timely visibility into how much their services, data pipelines, and environments cost. They may lack insights into what drives those costs. They may not be empowered to experiment within guardrails designed by a platform engineering team. They may face barriers such as siloed billing data, complex tools that were not designed for developers, and even misaligned incentives and governance roadblocks.
Collaborative cost management solves these problems by empowering developers with daily visibility into what drives costs for the services, pipelines, and environments they own. It can even involve pairing these insights with self-serve control over common day 1 and day 2 operations that leverage blueprints designed by your platform engineering organization and are executed within engineering’s existing workflow in order to avoid increasing their cognitive load.
Collaborative cloud cost management is not only a best practice for cloud-native development but also a competitive advantage for businesses that want to leverage the full potential of the cloud. By adopting collaborative cloud cost management tools and processes, engineering teams can make smarter decisions that improve their cloud efficiency, productivity, and innovation.
To summarize, collaborative cloud cost management has the potential to:
How does collaborative cloud cost management work in practice? It starts by enabling engineering teams to see the costs for the various services and environments they own on a daily basis. This helps teams understand when spikes occur, and provides a path they can follow to understand why the spike occurred.
That path can involve bringing different pieces of information together for engineering teams. They’ll want to see the costs of the individual resources that power their service or environment during the selected timeframe to see what spiked, and maybe even drill in further to see the cost drivers of that individual resource. They’ll likely want to see deployments and commits at a minimum, maybe even explore observability data as well during this timeframe.
Once they’ve identified a root cause, to the extent it involves needing to change a configuration setting of a resource, teams may want to understand a resource’s dependents, like other resources that are linked to it as well as any other environments and services that depend on it to size up the blast radius of a potential change. From there, they may wish to view config settings for the resource.
Finally, consider where it makes sense to give teams the ability to take action on their own versus foster a collaborative discussion between engineering and operations. You can accomplish the former via self-serve actions, which are simple no code workflows a developer can see if permitted via a role-based access control model. These workflows are loosely coupled with your existing IAC or CI/CD tools and orchestrate the desired change leveraging golden paths defined by your operations or platform engineering team. This approach alleviates cognitive load for developers and alleviates TicketOps for the DevOps team. For various changes that require coordination with DevOps, now your engineering teams can have a collaborative discussion on a timely basis thanks to the fresh, actionable information you’ve made available to them.
So what does it take to actually implement this competency? It might be easier than you realize.
One easy way to facilitate this competency across your enterprise is via an internal developer portal. Internal developer portals are living sociotechnical knowledge maps that organize knowledge about your applications, services and data pipelines, environments, and resources in one place, and pair this knowledge with functionality like self-serve actions to create something new or manage common day 2 operations. They are the perfect conduit to slice cloud cost data at the service level and put it in front of application and data engineers in their everyday workflow where they are further empowered to take action where appropriate.
configure8, at the time of publication, is the only internal developer portal that supports collaborative cost management out of the box. It enables your application and data engineering teams to see the costs for the various services (and data pipelines, ETL jobs, etc.) and environments they own on a daily basis. It helps teams understand when spikes occur, and provides them with a path they can follow to understand why the spike occurred and even take action to address the root cause directly or in collaboration with their ops team. It is simple to integrate, and free to try. configure8 plans to extend this capability from AWS to Azure and Google Cloud soon.
Backstage is an open source alternative to consider. It is important to note that Backstage is a framework to build a developer portal, and, thus, typically involves a larger (likely costlier…) time-commitment to set-up and maintain. Additionally, the information it makes available to developers may be limited in the context of this scenario. For instance, the level of cost driver granularity may be limited to higher level aggregates instead of drilling down into per resource costs for a given service in a given timeframe. Teams may not be able to observe individual resource cost drivers, resource blast radius information, nor resource config settings without meaningful customization. You may also need to expend effort wiring up actions to support resource changes.
You could also try to build a BI dashboard for your team that accomplishes this. This would require ingesting daily cost feeds from your cloud, and then allocating the cost of each individual resource to each environment as well as to each service leveraging proprietary resource<->environment<->service mappings you would build and maintain as your system evolves. Additional you would need to build a library of scripts and make them actionable in IAC and/or CI/CD tools.
Beyond tooling to enable visibility, control, and collaboration, below are related best practices for enabling collaborative cloud cost management for your developers:
Enabling collaborative cloud cost management for your developers is a new and incremental competency to help organizations improve their cloud cost efficiency. By empowering your developers to manage their own cloud costs safely within guardrails managed by your platform engineering or DevOps team via an internal developer portal, you can not only save money but also drive innovation, productivity, and customer satisfaction.
If you want to learn more about how to implement collaborative cost management in your organization, try or talk to configure8. It’s free to get started.