Accelerate Innovation by Shifting Left FinOps

Part 1: The Challenge and the Workload

FinOps is an evolving practice to deliver maximum value from investments in Cloud. Most organizations in their journey of adopting FinOps focus on highly tactical and visible activities. They perform activities post-deployment of the applications to help them understand and then optimize their cloud usage and cost. This approach, while being able to clearly demonstrate benefits, falls short of the potential of FinOps as it requires workloads to be effectively built multiple times. Shifting left with FinOps — you build once, this not only saves money on your cloud bill — but increases innovation within your business by freeing up your resources.

In this series, we will walk you through an example solution and how to effectively implement a shift-left approach to FinOps to demonstrate the techniques to discover and validate cost optimizations throughout a typical cloud software development lifecycle.

• Part1: The challenge and the workload
• Part2: Creating and implementing the cost model
• Part3: Cost Optimization Techniques for Infrastructure
• Part4: Cost Optimization Techniques for Applications
• Part5: Cost Optimization Techniques for Data
• Part6: Implementation / Case Study Results 

The Challenge

In the current format of this evolving discipline, there are three iterative phases: Inform, Optimize, and Operate. The Inform phase gives the visibility for creating shared accountability. The Optimize phase is intended to identify efficiency opportunities and determine their value. The operating phase defines and implements processes that achieve the goals of technology, finance, and business.

FinOps Phases 

However, with modern cloud pricing calculators and workload planning tools, it is possible to get visibility to your complete cloud cost without having to go through the development process well before anything is built. The cost of development, deployment, and operations can be determined based on the architecture, services, and technical components. 

The current architecture method involves understanding the scope and requirements. The personas involved and the functional requirements are captured as use cases. The non-functional requirements are captured based on the qualities (security, performance, scalability, and availability) and constraints. Based on the functional and non-functional requirements, a candidate architecture is proposed.  

Existing Architecture method and FinOps activities

As soon as a proposed candidate architecture is developed, we include a phase to do a FinOps model for the candidate. In this step, we shift left some of the FinOps activities at the architecture phase itself.  The candidate architecture is reviewed through the frame of FinOps for optimizations. This will go through iterations and refinement of the architecture to arrive at an optimal cost of the solution without compromising on any of the functional and non-functional aspects.

 ShiftLeft FinOps Model for Creating Working Architecture

Building a FinOps Cost Model is very similar to how you can shift left security in a DevOps pipeline by creating a threat model upfront. Creating a FinOps model for the solution is an iterative process.  This starts with establishing an initial baseline cost for the candidate architecture.  The solution components are then reviewed for cost optimization. In certain cases, it might require the teams to perform a proof of engineering to get the cost estimates or projections. The cost optimization techniques need to be applied at various levels or layers to arrive at a working architecture. They can be divided as follows:

• Cost Optimization Techniques for Infrastructure 
• Cost Optimization Techniques for Application
• Cost Optimization Techniques for Data

The Workload

Workloads can be very different; however, when viewed as functional components — you can utilize similar optimization approaches and techniques to maximize efficiency and value. Most workloads will have some form of data input, processing, and output, so the example we will use is a cloud-native application that performs data ingestion, processing to enrich and analyze the data, and then outputs the data along with reports and insights for a user. We will utilize a cloud-agnostic approach and break the workload and optimization techniques into the following components:

• Infrastructure: This is the computing, storage, and networking. This will include the resources, services, and associated attributes of them.
• Application: This is the application design and architecture and covers how the application will behave and function on the infrastructure.
• Data: This is the data itself and also the formatting and handling of the data throughout the workload.

These methods and techniques for each component and layer are discussed in detail with the help of an example. The workload for this example is a cloud-native application that involves some domain-specific data ingestion, processing, and analysis. The structured/semi-structured data is enriched and analyzed further to create reports and insights for the end user. This application is architected to be a deployment that can leverage services in multiple clouds — for instance, AWS and GCP.

Candidate Architecture for the representative Cloud Native Application

Conclusion

FinOps is a practice that gives the enterprise a better way to manage their cloud spending. Shifting left FinOps gives more opportunities to save costs earlier in the software development lifecycle. This involves the introduction of a few simple steps before the solution architecture is pushed to the detailed design and implementation phase. The steps involve creating a FinOps Cost Model and iterating through it to ensure that you have applied all the cost optimization techniques at the infrastructure, application, and data layer and components. You can optimize your overall cloud expenses by shifting left FinOps. In part 2 of the blog series, we will be creating and implementing the cost model.