According to Gartner, “By 2025, more than 85% of global organizations will be running containerized applications in production, which is a significant increase from fewer than 35% in 2019”. One significant outcome is that enterprises that run their business on public cloud infrastructure will see more meaningful portions of their cloud bill being associated with containerized workloads. Whether this adoption of containers is driven by cloud-native software development or the containerization of on-prem workloads for a “lift and shift” to public cloud, the resultant spend will be joining existing billing data and financial management processes. If we do things “right,” we can adapt our existing financial management capabilities to the unique challenges of running containers on public cloud. Without this effort, a growing portion of cloud bills will lack the financial accountability that helps drive successful business outcomes.
As with all things cloud, usage drives cost: businesses need to allocate costs to the teams consuming resources. The only difference with containers is that the technology itself makes cost allocation more complicated than for non-containerized resources. What some describe as the “cloud within a cloud” challenge has been a major focus for Apptio, and we recently addressed unlocking this black box with this recent post. At the heart of the problem is that container clusters are backed by a shared set of cloud resources (e.g., hundreds of transient R5/M4 AWS EC2 instances that can cost thousands of dollars each day) without a mechanism to tie the associated resource costs back to each cluster or allocate these shared cluster costs to the teams using them. Let’s look at not only unlocking this black box but how we can streamline integration with our broader cloud financial management.
Adapt your current cloud financial management practices
As we begin to unlock the container black box, there are many practices from regular cloud financial management that can be adapted. A good place to begin is thinking about the most important questions that need to be answered. Here are some good examples:
- What is the principal way I need to categorize this spend in a business sense? Do I need to report costs by software application, customer, or business unit?
- How many items (be it applications or customers, etc.) have been deployed to our container environments, and what is the cost footprint of cloud-native migrated from legacy on-prem?
- How are my container costs increasing compared to regular costs, and what percentage is for production workloads?
Let’s explore a scenario where we need to report costs for each of our customers. For regular cloud costs, such as managed databases and blob storage, there’s a good chance we’ll be using a resource tag with the key “Customer” for allocation purposes. It’s critical we have the equivalent delineation in our container environment and establish a strategy early on. For a principal allocation like this we’ve found the Kubernetes Namespace construct the most practical option. Each customer will get their own scoped Namespace within the cluster which makes for clean reporting lines. Kubernetes Labels, which are comparable to resource tags with a key-value pair approach, is another possibility and offer a higher degree of granularity. If Namespace is being used to delineate customers, then Labels could be relied on for splitting out our environment types (production vs. test) or the individual applications which support the customer.
Bring it all together with Cloudability
Having implemented these strategies within your container environments, Cloudability can leverage the resultant meta information to generate detailed allocation information. Still, more importantly, it allows administrators to create allocation definitions that span both container and non-container costs. By doing so, it’s possible to create a shared understanding of what business initiatives are costing across the entire cloud bill and make sure there’s accountability for every dollar spent. By being prepared, we can avoid cloud costs falling between the cracks as containerization scales. The first task is to make sure the Cloudability container agent is installed within each cluster. Without any further configuration effort, the Container Cost Allocation feature surfaces the cost for each customer:
This Cloudability Business Mapping feature can be used to create official definitions for these Customers than span container and non-container spend. It can also be used to classify each customer as migrated from on-prem or cloud-native. In the example below, we can see a definition for mapping each billing line to the customer it belongs to. To summarize, if the cost belongs to a Kubernetes cluster, then grab the value from Namespace, otherwise use the value from the Customer tag.
The output of a Business Mapping is called a Business Dimension, and in this case, the Customer dimension is available for reporting throughout Cloudability. Using dashboards, here are some of the insights we can now glean from individual widgets:
This widget summarizes the cost per customer, regardless of whether the costs are container-based or not, and tells us whether the customer is migrated from on-prem or deployed cloud natively. Note that “Customer Type” is a Business Dimension itself.
In this widget we are able to track our overall count of customers. This is extremely valuable information for senior leadership, particularly the transparency around how many customers have been migrated out of on-prem data centers.
In our last widget, we can see an example of how we can track trends in spend while getting visibility into the underlying usage categories.
Shared costs have always been difficult to manage, but increased container adoption makes it harder. Be proactive and adapt current financial management practices so that container costs can be seamlessly managed, and leadership gets the necessary visibility into container growth for cloud-native vs. on-prem migration.