Can the Internal Developer Portal Finally Deliver FinOps Clarity?

2023 is gearing up to be the year platform engineering goes mainstream. As budgets tighten, businesses want more insight into what engineering is doing, and platform teams look to simplify the developer experience — helping to do more with less.

The discipline of platform engineering aims to remove bottlenecks and help accelerate the speed at which application teams deliver value to end users. To abstract out the complexity of engineering in the cloud-native world. To take care of what Syntasso’s Abigail Bangser calls “non-differential but not unimportant work” — security, Kubernetes, cloud deployments, observability, compliance, and more. 

For Port CEO Zohar Einy, platform engineering covers all the Ops that distract from the Dev — DevOps, SecOps, FinOps, RevOps… you get the idea. All those portmanteaus admirably aim to tear down silos among departments but also risk increasing the cognitive load of already burnt-out developers. The term “full stack developer” is an impossibility, but with seven-layer technical stacks, it’s hard to even remain a full stack team. And a lot of these requirements are repetitive and redundant across organizations, regressing these creative workers back to code monkeys.

Platform engineering — and the internal developer portals or IDPs it demands — offers the opportunity to finally break down that important silo between business and DevOps, enabling FinOps and GreenOps at a time of tighter finance and carbon budgets. All while enabling developers to focus on work that matters to the business and to your users.

Platform Engineering Connects BizDevOps

A few years ago, when Einy and his co-founder Yonatan Boguslavski were tasked with simplifying the DevOps experience for an Israel Defense Forces’ intelligence team of thousands of developers, “We realized how big the problem is.” Complexity had grown so much that application teams could no longer be autonomous, lacking the knowledge of or access to the infrastructure they needed.

“The entire ecosystem of Ops became very complicated,” Einy reflected. “You can’t have one repo, one machine. You have a lot of things going on: Infrastructure as a Service, cloud resources, microservices, Kubernetes, ArgoCD — and the list goes on, and it never stops. Innovation brought into DevOps work created a lot of complexity, with different architectures and moving parts.”

There were 10 to 20 necessary steps if a developer wanted to create a new microservice: create a repository, configure the CI/CD pipeline, run infrastructure as code, and stay within guardrails (if they exist). “And to do that, you need to be an expert in the entire ecosystem of DevOps,” Einy said, and understand who owns the microservice and if your Kubernetes cluster is the best version to comply internally. Again, non-differential — yet organizationally important — work that distracts from delivering end-value to users. It is also repetitive work that takes away the creative side of engineering. 

“With DevOps, we keep innovating, but we can’t expect developers to keep up the pace,” he said. 

They eventually realized that an in-house internal developer portal (IDP) was the right solution as a way to provide engineers with everything they need to go “zero to hero” tucked behind a single interface, so they can reclaim application team-level autonomy.

If platform engineering is the what, then the internal developer portal becomes the how.

An Internal Developer Portal Prints FinOps Receipts

Now that platform engineering is a more widely understood and adopted discipline. Its use cases are going well beyond delivering on the promise of DevOps. That’s because an internal developer portal or platform provides transparency to the business side while helping development teams understand how they are delivering business value. 

One platform engineering use case that’s gaining traction is FinOps, which Passion.io’s Sara Miteva pegs as a way to optimize cloud spending “to empower teams to balance between speed, expense, and quality.” The FinOps Foundation calls it a cloud financial management discipline and cultural practice which “enables organizations to get maximum business value by helping engineering, finance, technology, and business teams to collaborate on data-driven spending decisions.”

Indeed, cloud computing costs continue to rise while organizations look to cut all spending — unfortunately emphasized by ongoing tech layoffs. Last month, the co-founder of Basecamp and Hey productivity tooling, David Heinemeier Hansson, aka DHH, recommended looking at your other expenses, including cloud cost before you cut staff or payroll. In fact, their team left the cloud completely last year and are already showing massive savings. It’s unlikely that more companies will follow suit and leave the cloud totally behind, but optimizing your cloud usage can significantly cut waste, along with your carbon footprint.

“Many people are dependent on the software that is being developed in a company. It’s become necessary to better understand your expenses and connect them to the business,” Einy said, offering another definition of FinOps. 

The challenge is that cloud resource provider reports tend to be rather meaningless to developers, teams, and business owners, as they reflect a collective cloud spend without drilling down to the team or microservice level. FinOps looks to understand cloud expenses and how it affects them from a business point of view: 

• How much does this customer cost?
• How many resources is this microservice using?
• How many dollars does each development team expense?
• How could resources be better shared?

The necessary data to answer is there across existing cloud reporting tools, but it needs to be mapped in a way for all stakeholders to understand.

An internal developer portal that integrates with tooling like Kubecost can offer a lot of insights into reporting, offering a common visual language between business and DevOps teams, mapping cloud spend data to developers, teams, microservices, systems, and domains, giving insight at the team level of who is spending what, within different environments. This transparency nurtures more cost-conscious engineering teams, which in turn enables right-sizing cloud spend.

The internal developer portal becomes a way to represent the logical aspects of your environment, tagging and tracking different elements. This horizontal view empowers engineers and product managers with better decision-making at the business level, not just at the operational level. Making decisions based on the business value gained per resource, teams can now optimize what to leave in the cloud and what to remove from it, and where to share resources. 

"We see DevOps teams as a major beneficiary of IDPs, and FinOps specifically, since, instead of organizing FinOps reports or trying to manage all of their DevOps asset information, they can use the software catalog in the internal developer portal," Einy said, pointing to this common theme of platform engineering and IDPs not replacing, but finally delivering on the promise of DevOps.

Yes, FinOps is another move to shift things left. Which could just put more work on the already overburdened application teams. But the thought of IDP-enabled FinOps is to present the information and options simply and transparently, without teams having to waste time searching for it. 

FinOps Offers Back Door to GreenOps

Agile has taught us that you cannot improve what you cannot measure. Therein lies the challenge with most initiatives to decrease carbon footprint — carbon measurement across the tech industry is still nascent. Cloud cost remains the most reliable way to measure the carbon output of engineering teams, especially in less green cloud regions like the Eastern U.S. 

Within a no-code internal developer portal like Port, you can represent your regions and cloud providers and tie them to data and expenses. After all, your cloud region is a known logic. 

If an organization is better at tracking its cloud usage, you can see within the IDP what resources are being underused or not used at all. You could then flag that a resource isn’t being used and then ping the developer connected with it, asking if — yes or no — that resource can be auto-terminated. It also allows departments to identify resources that could be shared among multiple teams. 

If your cloud usage is tracked at both team and resource levels, product managers can query the data and create reports on cloud cost per team, service, environment, system, and domain and start to automate resource allotment for how much is usually used monthly. This skips the usually manual step of developers asking permission to procure cloud resources, but then, if a team needs to go over, a manual approval process is still warranted. After all, some bottlenecks, especially in these tight times, are necessary.

The end effect of GreenOps is, of course, not just cutting carbon footprint but cutting cloud cost. When platform engineering drives a common language between business and tech, everybody wins.