Using an Internal Developer Portal for FinOps Visibility

Platform teams are increasingly looking to provide developers with more context around cloud costs. Developers want to benefit from FinOps practices but they need a way that pulls together the required information into one place so they can align cloud investments with business outcomes.

Despite investing in cloud cost tracking and optimization tools, there are numerous issues to contend with:

• Developers, tasked with optimizing the cost of their applications, are unable to comprehend the many resources that comprise a single service, so they have no insight into how much a service costs, and can therefore do little to optimize a service’s cloud costs.
• Tech leads and product managers are unable to see how much a namespace costs, and they have no way of doing so with cost reports, so they are hindered in planning their roadmap with cloud resources in mind.
• Engineering team leaders are unable to determine which team owns which resource, or which resources their team’s services use, leaving them unable to effectively request and maintain a cloud budget.
• FinOps teams are unaware which resources are aligned to which service, so they are unsure which resource cost optimizations can be implemented without disrupting service functionality.

An internal developer portal provides the advantage of centralizing development routines and tools, and cloud cost data is no exception. Because the portal integrates with the platform tools, it can pull in and combine data from these tools, adding valuable depth. This means teams handling FinOps get a clearer picture by seeing their cloud bills with the added context of development activities. At the same time, development teams can benefit from properly contextualized cloud cost data to tweak their resource configurations without sacrificing functionality.

How a Portal Can Help

Portals are made up of five main pillars: a software catalog, a scorecard layer, a developer self-service actions layer, a visualization layer and a workflow automation layer.

Given the above context, an internal developer portal is able to help relieve the pain described in the following ways:

• The software catalog can include cost data, which can be aligned to teams, services and domains, giving developers, managers, and FinOps teams a common operating picture to optimize the cost of a service, not just the resources that serve it.
• Scorecards allow leadership to monitor compliance with standards set by FinOps without depending on data calls or running scripts on otherwise unintelligible cost reports.
• Self-service actions bring powerful cost predictions directly to the developer while they create development environments.
• Dashboards enable engineering leaders and FinOps teams to visualize the data that matters most, such as cost per service, domain, and team.
• Automations: For example, auto-terminate a developer environment after it reaches a predefined TTL.

Technical Guide

Ingesting Resources and Costs

Begin by ingesting your cloud resources to a portal by following the instructions provided in the installation instructions here. We will use Port as an example. This will allow you to view your cloud resources in a centralized catalog using blueprints, which are the most basic building blocks in a portal, allowing you to represent assets in your organization. The blueprints that are created by following these steps depend on user preferences but are generally major resource types in your cloud provider of choice.

Next, ingest your cloud costs using the tool of your choice, such as Kubecost, which provides granular insights into resource utilization, empowering teams to optimize their Kubernetes spending effectively. Kubecost’s comprehensive interface and analytics are ideal for businesses seeking to control costs without compromising performance. Kubecost is built on OpenCost, an open source Kubernetes cost visibility solution that is managed by and part of the Cloud Native Computing Foundation.

Relating Resources and Costs

Finally, maximize the advantage of using a portal by relating your resources and their costs. Relations define connections between blueprints, consequently connecting the entities based on these blueprints. This provides logical context to the software catalog.

Go to your Builder page and relate your costs to your resources by expanding your cost blueprint and clicking “New relation.” Enter the required parameters (provide a title, select the intended cloud resource from the “Related to” dropdown, select “one entity” (since a single cost line item is associated with a single resource), and select whether it should be a required relation.

👁 Image

If you have already ingested your services from your git provider, relate these resources to the services that run within them by following the same process described above, only this time the service should be tied to the cluster in which it runs.

👁 Image

This process lets you see:

• Costs tied to resources that are associated with the services they host.
• Additional business domain information that enables you to determine which services cost more than they contribute to the domain they serve.

This crucial contextual information enables you to:

• Easily identify where to adjust spending for better financial efficiency.
• Aggregate costs per domain, ensuring that non-revenue generating domains do not exceed budgets (crucial for monitoring costs of goods sold).

Creating a FinOps Dashboard

Now that you have resources and resource costs ingested and related in your portal, make a view that is useful for you, such as a FinOps Dashboard, where FinOps and engineering teams can collaborate on cloud resource costs effectively. Let’s take a look at these example views offered on our public demo site.

Ensure Environment Costs Are Appropriately Balanced

FinOps teams seeking to lower their cloud costs can both optimize production environment resources and ensure development environment costs are not excessive. A view like the one below brings all resource costs across all environments into one view, allowing FinOps teams to monitor the effect of their cost optimization initiatives.

👁 Image

Drill Down into Individual-Resource Costs by Environment and Team

If the number charts in the dashboard view above reveal alarming information about environment costs, FinOps teams can use the table views below in the same dashboard to drill down into resource costs, grouping by environment, team or any other property in the table. Identify an anomalous environment cost using the view above, then find the offending resource (or resources) in the table below.

👁 Image

👁 Image

Conclusion

FinOps tools provide visibility into cloud spending, presenting the information available from the cloud provider, which doesn’t always tell the full picture.

By using a portal to contextualize cloud resource costs:

• Developers can build their applications that comply with FinOps standards — no more building applications at all costs
• FinOps teams can embrace the service context not included in their cost reports and effectively collaborate with developers on cost optimization efforts — no more myopic focus on cost reduction

Data from FinOps tools must be enriched by data from development tools, aligning cost to resource; resource to service; and service to team and domain. With a common understanding, finance can drive effective investment initiatives and development teams can effectively deploy their applications with an eye towards cost. By using a portal, developers, engineering leaders, and FinOps teams can maximize their investment in cloud cost-tracking tools and optimize their cloud costs without sacrificing service functionality.