Using an internal developer portal For superior FinOps visibility

Port enables you to contextualize FinOps by pulling in and combining data from multiple sources

Introduction

I joined Port as a Solutions Engineer in early January. In my day to day, I’m meeting with engineering organizations seeking to redefine developer experience by implementing an internal developer portal. The portal provides everything developers need in one centralized place. 

We always start the process by scoping several high-value use cases that comprise a minimum viable portal, which helps them to deliver quick value that solves pain in their developer’s daily lives, thus ensuring a high adoption rate. While creating these user stories, I was surprised at the amount of prospects and customers that wanted to contextualize their cloud costs using a portal.

Problem statement - cloud costs 

Developers at these organizations are tasked with optimizing the cost of their applications, but are given little context to do so. These organizations invest in cloud cost tracking and optimization tools such as KubeCost, but:

• Developers 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.

While this was not among the typical portal use cases I had researched before joining Port, it made sense: one of the advantages of using Port is centralizing development routines and tools, and cloud cost data is no exception. Because Port 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 Port 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, Port 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: Port can, for example, auto-terminate a developer environment after it reaches a predefined TTL. 

Technical guide: ingesting and relating resources and costs

With very little experience using Port, I decided to take on the challenge to ingest cloud cost data into Port, relate it to the correct services, and relate those services to teams. Here how you can follow what I did:

Ingesting resources and costs

Begin by ingesting your cloud resources to Port by following the instructions provided in the installation instructions here. This will allow you to view your cloud resources in a centralized catalog using blueprints, which are the most basic building blocks in Port, 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 have made it a go-to solution 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 CNCF.

Relating resources and costs

Finally, maximize the advantage of using Port 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 or not it should be a required relation.

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.

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 Port, 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.

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.

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 Port 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.