As illustrated in our previous two blog posts in this series, cloud observability and optimization recommendations are the core capabilities for effectively managing your cloud finance. In addition to these capabilities, you need ways to govern the budget of your projects, chargeback to the project owners, as well as to enforce the proper policies for instance, storage lifecycle policies and security scanning rules. We group these as the capabilities as Governance. 

 

The foundation for Governance is the capability to group multi-cloud resources according to various boundaries such as organizational units, projects, VPCs, etc. Cloud management platforms need to provide a flexible way for the purpose of grouping so that Governance can be effectively carried out. In this blog post, we will look into what Governance capabilities you should look for, and how they can be absent in cloud native solutions. 

 

Along with these, we will also discuss crucial communication capabilities that should be present in cloud native solutions (and yet they are not available). Communication is fundamental to the success of FinOps in enterprises when there are interdisciplinary teams involved. 

 

Now let’s demystify the myths:

Myth 1: You have the flexibility to effectively group your cloud assets based on your organizational units, departments or projects across clouds for governance.

Reality is that cloud native solutions are only capable of grouping assets within their own clouds. For a project that encompasses multiple clouds, you will have to resort to Excel sheets to combine the data together. Chargeback is a typical use case for these groupings. Are you running a multi-cloud project and struggling to have accountability for budgets, chargeback, security policy enforcement and storage policy enforcement? If so, you need to look beyond the cloud native solutions.

In addition, you might have a use case for grouping instances together since they make up the same online service. Simply take a 3-tier application where you have a web tier, application tier and a database tier. You might want to group the instances serving these tiers together so that you can control the startup and shutdown orders of the instances for different tiers at just one-click. With this kind of grouping, you can control the budget, startup and shutdown scheduling, and more. The fact is that cloud native solutions do not offer this kind of grouping to you.

Myth 2: Cloud solutions can help you attribute the expenses accurately to your organizational units, and projects, even when the resources are shared. 

In reality this is not at all the case for shared resources. Almost all cloud solutions struggle to provide accurate chargeback data for shared resources since there is only one line item for each resource regardless of whether it’s shared or not.

In Microsoft Azure, a preview feature is available to perform shared resource allocation according to a fixed percentage. This can be effective in some cases, but can be a crude estimation for others.

You may argue that some cloud native solutions allow you to write scripts to distribute the cost of shared resources to the respective departments. But don’t you think it is a maintenance overhead to ensure that the script is always up-to-date and may cause you to consider wrong or old data. The need of the hour is a solution that enables you to automatically divide costs right after you have configured according to your requirements. Kubernetes workloads represent classic use cases – You might intend to divide the costs of a Kubernetes cluster by tracking which pods have run for which departments. And yet the cloud native solutions do not allow you to easily do so.

Myth 3: Storage lifecycle policies are easy to manage.

Reality is that in cloud vendors such as AWS you can define lifecycle policies individually for ECR, S3, EFS and EBS however there is no option available to common policy or to bulk update policy for all storage assets. Also, it is very tedious for the administrators to determine whether lifecycle policies are applied to the required storage components. A one-stop window is what tops in the preference list of all administrators.

Myth 4: All the key stakeholders, including your finance team and your IT team, have equal access to the billing and utilization data for their FinOps practice.

Reality is that in most cases the finance team has access to the billing data and the IT team has access to the utilization data. To make FinOps effective, the two teams need to consider both categories of data together. Cloud native solutions do not offer data in these categories in one single pane of glass. They offer multiple tools for cost observations (e.g. AWS cost explorer) and utilization observations (e.g. AWS CloudWatch dashboard). 

 

Adding to these complexities, users cannot simply just share their reports by copying a URL for a specific report. They end up having a hard time finding all the data others are looking at, and become inconsistent in the conclusions of their analyses.

We hope the above makes sense. You might think that we are just deconstructing your realities with no input on how to perform your tasks better. Rest assured that Aquila Clouds FinOps platform has capabilities to help you with all the above. For example, we enable you to:

• Effortlessly group your multi-cloud assets and precisely account costs for shared resources to the respective departments and business units even in a multi-cloud setup. 
• Use the single-window to define common lifecycle policy to required storage components and effortless update storage policies for the required components. 
• Define permissions to enable stakeholders to access billing and utilization data, and recommendations on our platforms
• Share reports using smart URLs with your colleagues so that you all can have the same view

We look forward to hearing your feedback.