Accelerate Innovation by Shifting Left FinOps, Part 2

In Part 1, we looked at the overview of FinOps as an evolving practice to deliver maximum value from investments in the cloud.  We also discussed the challenge or the need for shifting left FinOps for better optimization of your cloud usage and cost. In part 2 of the series, we will walk you through the steps on how you go about creating the FinOps cost model for an example solution.

There are 3 steps to creating and implementing the cost model:

1.   Create the FinOps cost model
2.   FinOps cost model reviews
3.   FinOps cost model refinement

Depending on the size and complexity of either the workload or your organization, these steps may be done once, or multiple times in a cycle. Higher complexity may require multiple revisions and refinements which need to be agreed between stakeholders and implemented. As you mature, however, you will typically re-use existing models or find the correct model much faster, and this process will typically involve a small number of cycles.

Step 1: Creating the FinOps Cost Model

The first step to effectively Shift Left with FinOps is to create a cost model, which is used to provide a forecast for the cost of running a workload. The model can be simple: provide the cost for a small number of architectures and levels of throughput/performance. It can also be scaled up, provide more granular control of inputs, and cover a much wider range of throughput/performance levels for enterprise workloads.

In this step, you define the required performance levels and review the architecture building blocks from a cost perspective to arrive at a baseline cost for the solution.  This will include cost across various layers in your architecture including:

• Infrastructure cost - Cost associated with selected compute, storage, and network resources
• Application cost - Cost of building the application components and services, like runtimes and development environments, platform services like messaging, security, and integration
• Data cost - Cost of acquiring and processing data and related cloud services like database services, analytics, warehousing, and machine learning

Apart from these three major elements, the total cost will involve other cost elements, such as:

• Development cost - Human resources involved in building and operating these components
• Licensing cost - Costs associated with specific tools and third-party services
• Support cost - Costs associated with technical support and maintenance services for the solution

Another key metric to be included in the FinOps cost model is unit economics. This is a cost analysis of the revenue and cost associated with a single unit of a product or service. In the case of a SaaS solution example, we can understand how profitable it is to run the entire process for a single customer and make strategic decisions to keep the cost of goods sold (cogs) to a minimum. Unit economics can help analyze many of these factors to determine whether the solution is viable and sustainable from a cost perspective in the long run.

Baseline Cost for Example Cloud Native Application

The table below defines the metrics for calculating the base cost for the candidate architecture. From an infrastructure perspective, the table gives an approximate compute and storage reference for domain data ingestion.

We build a model for seven different performance levels. These will reflect the predicted or potential levels of required performance of the workload over the short to medium term. Due to the rapidly evolving nature of cloud services, and regular workload reviews, long-term workloads will typically include new services or features and forecasts will not be accurate. These levels chosen should provide enough granularity to highlight differences between architectures and medium-term performance requirements, and not incur significant effort to calculate. 

These models can also be used to show different levels of efficiency for different workload architectures. If there is a future state workload architecture that delivers significantly more efficiency, it may be best to implement that model now and avoid the costs of re-architecture, change, and validation later.

Finding a balance between model complexity and the granularity of performance levels is key here, start simple and then add either or both complexity and granularity as you refine the models.

Let's calculate the data ingestion for a domain data source having a monthly source data size of 250 GiB. Then the compute and storage cost is calculated to be approximately $353. (Refer to the Tools section for the details on this calculation.) Similarly, the table below defines the metrics to determine the query cost for single domain schema (with single concurrency at a time):

The data reporting cost is then calculated for the above metrics with GCP BigQuery as the engine and it comes to approximately $4,000. (Again, refer to the Tools section of the article to find out the details.) 

Step 2: FinOps Cost Model Reviews 

These reviews are an important step that teams need to perform before going ahead with the macro design and development activities. The candidate solution architectures need to be reviewed from a total business cost perspective. The key infrastructure, application, and data elements need to be reviewed for cost to the business over the expected workload lifecycle, evaluate the impact to any functionality, and the solution's capability to meet any of the non-functional requirements. 

During these reviews, all requirements are validated again with the stakeholders to ensure the required balance and alignment with business objectives are met and ensure that every possibility of cost saving is implemented. These reviews are an iterative process where all the optimization recommendations are applied to the candidate architecture to come out with a working architecture. It is assumed that all the cost optimization techniques and their applicability for the candidate architecture have been evaluated and the cost model for the working architecture is optimal before it is approved for design and development.

These reviews also include the verification of the budget/forecast from the business, and validate that the solution can be contained in the budget.

Step 3: FinOps Cost Model Optimization and Refinement

In this step, we apply the learnings and insights from the reviews to refine and improve the architectures we have created previously. Depending on the findings from the reviews, we may go back to Step 1 and adjust the cost model and then have another review cycle, or proceed to optimizing the architectures with the model in the current form.

Tools for Building Your FinOps Model

Generally the more complex the model (higher number of inputs, more performance variations, inclusion of additional costs), the more accurate and useful it will be for your implementation. Just like anything with FinOps, tooling is critical to reduce the effort required and gain better insights. 

You can start with vendor-provided tooling such as AWS Cost Explorer and AWS Pricing Calculator, Azure Cost Management and Pricing Calculator, and Google Cloud Cost Management and Pricing Calculator. These tools provide basic monitoring and estimation of the workload infrastructure cost.

For building your FinOps Cost Model you need tools that can also provide workload planning, unit economics, budgeting, and forecast capabilities.  Also if your application is leveraging multiple cloud vendors, it is difficult and time-consuming to get a single view of your cost model using vendor-provided tools. So in this case where you need you need more insights and analysis during the conceptualization and architecture phase, you should consider tools like Apptio Cloudability to build and optimize your FinOps model.

Cloudability goes beyond cloud cost management to provide you with the required planning capabilities for creating the cost model as well as tracking, monitoring, and analyzing the spending through development, deployment, and operations.

Below is an example of how you can leverage Cloudability to create the cost model described in Step 1 with Apptio Cloudability's workload planning feature. In this case, the compute and storage cost can be calculated by workload planning based on your component architecture.

 Cost for Infrastructure using Cloudability Workload Planning

Using Workload Planning, you can further include the cost of services like BigQuery that are needed for data analysis and reporting.

Apart from the planning capabilities, you can also leverage tools for the following:

• Perform unit economics to better understand and analyze the cost structure of your cloud-based product or service, typically on a per-unit basis. This also provides the breakdown of costs across design, development, deployment, and operations and compares with the revenue projected/generated by each unit sold or used. By understanding the unit economics for a cloud product or service, you can make informed decisions and changes to your candidate architecture to better overall profitability.
• Understand your current spend and plan better for the future with Cloud Financial Planning capabilities that include cost transparency, control, forecasting, and optimization. These tools allow you to set the budget, forecast the IT spend, and track the resources and usage to stay on budget.
• Calculate and predict the infra and application cost before deployment based on automation templates like Terraform/CloudFormation. 
• FinOps dashboard to get visibility to the cost of base architecture and track the cost optimization for subsequent iterations

In this article, we have explained how to create and refine a cost model. In the next part of this series, we will look at cost optimization techniques for infrastructure.