Guest post originally published on the Fairwinds blog by Patrick Loring
FinOps has become another buzzword in the cloud native ecosystem of late. FinOps, as defined by the FinOps Foundation, is the:
FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions.FinOps Foundation
FinOps has been a term we’ve used in the cloud industry for years. The goal is to ensure that financial teams and ops teams are aligned and there is ownership over cloud spend. That requires the measurement and tracking of financial (aka cloud) spend against budgets, revenue targets and business goals.
There are many great tools that exist to track cloud spend, however one persistent area of concern is containers. The world’s undeniable winner for container orchestration is Kubernetes. I like to refer to it as the “blackhole” of FinOps. Just as the cloud was once an unknown cost to the business, today Kubernetes holds that position in organizations. It’s particularly an “unknown” in those organizations that have no visibility into how Kubernetes is being configured to ensure costs are aligned with application performance requirements.
Why is Kubernetes a Cost Blackhole?
To understand why Kubernetes is a cost blackhole, it’s important to consider how Kubernetes works.
Kubernetes clusters are deployed on cloud instances, but they are often shared. Kube clusters can host multiple workloads and applications, but your cloud provider’s bill has no visibility inside of the cluster. The lack of visibility into how infrastructure is utilized or shared by multiple teams is “the blackhole”.
DevOps teams are putting Kubernetes in place to serve as a platform for developers to work on applications, get them to market faster with the reliability needed for today’s infrastructure (i.e. I need my application to scale automatically if my application goes viral).
Developers are therefore using what the DevOps and platform engineering teams provide. One of the main challenges is setting Kubernetes configurations around CPU and memory. When configuring, a developer must decide what settings to put in place. If CPU and memory are set too low, the application may have performance and reliability issues. On the other hand, if set too high, the organization may be paying for unnecessary cloud resources.
Think this isn’t a big deal? In one example, a developer set a configuration setting incorrectly that led to a $50,000 overspend in 24 hours. Fortunately, the DevOps team caught it within a day, but had that been missed, it could have been devastating to the organization.
FinOps is Kubernetes Service Ownership
The FinOps Foundation says that “At its core, FinOps is a cultural practice. It’s the way for teams to manage their cloud costs, where everyone takes ownership of their cloud usage supported by a central best-practices group.” This holds true for Kubernetes as well.
We talk a lot about Kubernetes service ownership, the idea that DevOps provide developers the tools and guardrails they need to build, deploy and own an application from start to maintenance. When thinking about how Kubernetes service ownership affects overall cost management, proper configuration plays a major role. Service owners, aka developers, need to understand how much an application ultimately costs—and if this amount aligns with their pricing metrics. In the past, before Kubernetes, businesses could rely on cloud cost tools to provide visibility into the underlying cloud infrastructure. But now, Kubernetes provides a new layer of obfuscation in cloud cost management, a blackhole for traditional cloud cost monitoring tools.
By employing a FinOps / service ownership model of Kubernetes, teams can understand the “true cost” of a workload and perform proper cost allocation among applications, products and teams. This level of clarity into cloud resources, typically found through a Kubernetes governance platform, allows teams to make better decisions around the finances of Kubernetes. Without it, organizations have trouble optimizing compute and workloads in a dynamic environment like Kubernetes. Multiple teams, multiple clusters and a lot of complexity translate into copious amounts of information to review and evaluate when trying to make smart, real-time business decisions.
A FinOps approach with Kubernetes can be viewed as just another model for proper cost management and service ownership. Whatever you may call it, if using Kubernetes, you need to empower development teams to own and run their applications in production, removing Ops as a bottleneck to delivery, while also providing finance management detail they need to make better decisions.