Streamline DevOps & Cut Costs: Massdriver’s IDP empowers devs with cost control tools & cloud bill of materials, preventing misconfigurations & reducing IT expenses.
Massdriver has made available tools for tracking cloud costs and generating a cloud infrastructure bill of materials (Cloud IBOM) to internal developer platforms (IDPs) as part of an ongoing effort to streamline platform engineering workflows.
With a few clicks, the Cloud IBOM makes it possible to map hybrid cloud resources such as databases, machine learning pipelines, and serverless computing frameworks.
Massdriver CEO Corey O’Daniel said these tools reduce expenses by preventing misconfigurations resulting in unexpected costs. Rather than solely providing a summary of costs incurred, the tools provided by Massdriver surface how much cloud services will cost when the developer invokes them, he noted.
In the absence of that context, developers will nearly always overprovision cloud resources to ensure maximum availability regardless of cost, says O’Daniel. The overall goal is to help organizations reduce the total cost of IT by providing developers with insights into costs in real-time, he added.
Earlier this year, the company launched an IDP with platform engineering tools that, for example, allow DevOps teams to build a catalog of infrastructure components that developers can access within the context of guardrails they define. The platform also includes observability and visualization tools that make it simpler to track metrics and monitor the usage of cloud resources.
Massdriver is making a case for an IDP that provides built-in tools and workflows that enable organizations to embrace platform engineering as a methodology for managing DevOps workflows at scale. The goal is to reduce the expertise required to build and deploy applications in cloud computing environments, said O’Daniel. He added that one of the primary reasons there are not more applications running in the cloud today is that these environments are still too complex to manage successfully. He added that an IDP abstracts away that complexity within a set of workflows vetted by a DevOps team.
There are multiple approaches to building an IDP, but rival approaches require too much effort to set up and maintain, said O’Daniel. He added that a proprietary platform provides a more turnkey approach that doesn’t require DevOps teams to either build their own or customize an open-source platform.
It’s not clear at what pace organizations are embracing platform engineering. Still, there is a clear need to balance delivering IT services managed by a centralized team and the desire a developer might have to embrace new tooling whenever they see fit. Today, too much responsibility for provisioning IT environments has been pushed toward developers with less time than ever to write code.
There is, naturally, no guarantee that reducing the cognitive load for developers will increase productivity. Building applications require streaks of inspiration, but, in theory, an IDP should provide more time for inspiration to strike. As part of that effort, DevOps teams should continuously work toward eliminating any bottlenecks that have emerged in their DevOps workflows.
