Fine-tuning FinOps approach: the next step - DevConf.cz Mini | November 2022
Speaker: Milorad Stević
Cloud financial management or FinOps in the cloud represents tools, products, practices, and cultural setup to increase the ability of an organization to understand and manage its cloud costs.
The current approaches for implementing FinOps practices rely on teams conforming to predefined rules that should make their technical solutions financially efficient. These rules are technical rules, based on financial models defined within the company to make sure that certain financial goals are met. For instance, the organization would create a rule that no snapshot should be older than certain number of days. A more extreme example might be setting the acceptable CPU utilization level for using certain instance type. This idea is focused on gaining financial benefit through educating teams how to lower the expenses, e.g., setting the retention policy for snapshots. This approach is assisted by various practices, tools, and products. No matter how implemented, the approach represents the extension of the financial side of an organization. Some recommendations will never get accepted by engineering teams because they are not providing enough technical evidence that applying them will lead to a sustainable engineering solution while saving money for the company.
Due to this business motivation, there is no long-lasting technical influence in the organization, making the overall impact limited.
The proposed approach offers methodology that establishes a framework not only for achieving financial results, but also for making a long-lasting technical influence. It is a framework that does not interfere directly with technical or financial domains, but coexists with them, acting as a corrective force. It treats an organization as a distributed system, affecting different subsystems to achieve its goals. The approach is about establishing advanced observability at scale, and it is most suitable for large organizations where it is difficult to discuss strategy with many teams directly.
The simple example might be a subsystem able to detect teams with different strategies for managing their snapshots and try to learn about them before imposing a rule that would affect the organization. These strategies might be different for different project types or for different environments. A more complex one would be the ability of a subsystem to detect different CPU utilization patterns and learn how to evaluate them more accurately. This learning would be supported by the subsystem but would have to be executed through a dialog with teams that have different usage patterns. This would empower the proposed subsystem with the new knowledge that would make the subsystem better at performing its recommendation function. The most complex example would be its strategic function. In this example, the company with a lot of teams would use the approach to steer its teams towards desired strategic goals which would unify technical and business goals. For instance, if an organization would like to improve its adoption of serverless technology, the subsystem would be able to detect different patterns for using serverless approach, e.g., some teams would use containers, some would use container platforms, some would use lambdas and some would use some combination, or something different. Then, a dialog between teams using representative patterns would be established and valuable knowledge would be formed. There is no algorithm that can generate this knowledge – the important part of the process, besides collecting a lot of data is engaging with teams, learning from this engagement, and feeding this knowledge into the system.
The difference between the current and the proposed approach is the effects they have on a system. The current approach favors short-term and easier to implement actions supported by rich reporting capabilities. It is more generic and applicable to wider range of organizations. The proposed one prefers long-term influence, through nurturing a dialog which would generate the knowledge that would be used to accomplish long-term organizational goals.
The need for the cultural shift is also discussed: the current approach expresses the cultural shift as a set of organizational rules for lowering expenses. There is no direct correlation between efforts to lower expenses and project goals. Therefore, these rules feel imposed upon teams. The proposed approach defines cultural shift as a contract between business and technology about the strategy that should bring success to an organization, hence the motivation to implement it. The proposed approach is used to guide strategy adoption.
Slides: https://github.com/devconfcz/archive/...