FinOps is a process, not a tool

FinOps is a process that gives cost visibility

FinOps is a process in the organization that gives predictability and insight into cloud costs. Along the way it improves governance and compliance, and savings are its side effect. FinOps is not a one-time check, a tool installed in CI/CD or a cost review once every three months. The speakers often see the reverse order: a company introduces checks once a year or once a quarter and wants to cut costs right away. That will not work.

With visibility, the organization knows what it spends money on, controls costs more easily, has fewer resource types and reviews them more easily. A lower cloud bill must not come from extra work for people.

Szymon Warda: “It’s not about spending less. It’s about spending more wisely.” (translated) 03:00 As a rule, spending more wisely also means spending less.

Costs leak through scattered resources and the long tail of systems

Costs spread wherever each vendor, region or department has its own underused resources. The description comes from work with one client, but the speakers see this situation in very many organizations, to different degrees and in different areas.

A typical setup is many subscriptions and accounts where vendors deploy software and, in a way, spend money that is not theirs. Looser control is not bad in itself: it gives agility and shortens delivery time, and organizations often do not know how to do it differently. But this setup has no reservations, no budget control, no alerts, no forecasts and no rules on which resources to use. Some resources can be centralized: more reuse makes control easier, cuts staff overhead and improves compliance.

Software licenses are a separate problem. At this client nobody controlled them, and they can run into serious dollar amounts. Licenses are often easy to overlook because they land on a different invoice, and in some organizations they are a very significant cost.

Repeated solutions that differ slightly from each other also create a hidden cost. Say one service exists in six versions: each one needs backup, security and network policies and has to be maintained. Every system a vendor deploys extends the long tail of costs, and the IT department’s headcount has to grow with the number of systems it maintains. This model does not scale well.

Hours add up too. Over the years, three hours here, two there and four somewhere else can turn into, for example, two or three full-time positions. Getting that time back later is expensive, because saving four hours a week pays off only moderately. It may be better not to let those four hours appear at all and to stay at, say, 20 minutes. That is why FinOps also watches future costs: the organization sees what they will look like and how they will be distributed.

Neither a new tool nor cost cuts by teams give lasting savings

Buying a FinOps tool or license will not fix the problems, yet the speakers often see companies take this path. It is easier to give in to marketing that promises the product will remove them. Szymon Warda: “no magic powder has ever cured anyone” (translated) 08:29

A new tool lands on a team that already maintains many products. Nobody knows whether it will be configured well, whether it will work and whether people will want to use it. At worst it can become another obstacle, at best another ignored tool that raises the cost.

A set of best practices is a better direction because it addresses behavior. But the organization has to create conditions in which people want to adopt them, have time for it and know how to apply them.

Asking every team to find unneeded resources and cut costs on its own is a trap the speakers see very often. Six months later the costs can come back even higher, a yo-yo effect: they were shifted onto people, the company paid incorrectly, or the savings only had to look good in Excel for the right quarter. Even eight hours a month per team adds up to a fairly large budget across the organization.

A good share of the savings and visibility has to happen at the organization level. Protopia proposes to do this work once, centrally, and to give teams automation and ready-made processes instead of a daily morning review of a spreadsheet on their to-do list. A pit of success is a setup in which the right things are easy, cheap and simple to do. Teams hand over part of the work, and if they act as agreed across the organization, their work gets easier and cheaper. Then nobody has to fight the organization, because optimal behavior pays off.

The first step puts vendors and the organization in order

Building the process starts with vendors, in two ways. For the future, the organization sets architecture guidelines: which resources to use and how vendors should report budgets and forecast costs. This way the long tail of costs stops growing at its previous pace. For systems already running in production, the organization takes an inventory: it checks which resources are in use and what can be optimized. The inventory produces a list of best practices and changes that make the system meet regulatory, security, governance and compliance requirements.

The organization itself also needs order. As a rule, a cleanup stage comes first: licenses, unused resources, bad tags, budgets and different approaches to the same FinOps work. The processes have to be cleaned up and unified. Then the organization consolidates the resources it uses in many places. The vendor review also shows which resources vendors use and what is worth taking under the organization’s own control, for example DevOps agents, a Kubernetes platform or an observability platform.

Governance combines consistent budgets with automated policies

The second step is governance built on visibility and automation. Visibility starts with budgets at the organization level: all systems report costs in a consistent way and by the same forecasting rules, so they can be compared. The organization also sees which resources it uses, in which versions and where, and breaks the invoice down into smaller items. It reviews data retention and reservations, then decides where to invest time, what to buy and what to drop.

The first part of automation is policies that enforce good behavior. The rule applies, period, with no reliance on scout’s honor. Where something cannot be checked automatically, dedicated services quickly report the noncompliance. Reporting rules shorten the time between an event and the moment the organization learns about it. If the organization learns about a resource, for example, two months after it started using it, a request to change it will not work. If a day or two passes between use and information, a change becomes more realistic.

Nudging gives teams ready-made automation and modules

The third step encourages people to follow good practices of their own accord, because a stick without a carrot is not enough. Nudging is encouraging good behavior and making it easier. This stage has two parts: the goals and the way to deliver them. An example goal is good practices and a lower cost of Azure or any other cloud.

The goals are delivered through, for example, automatic machine start and shutdown, backup automation, and autoscaling of databases, Kubernetes clusters, virtual machines, and PaaS and SaaS services. On top of that come license count monitoring and processes that make it easy to request access. A team tags a resource, and from that moment all the automation covers it. The team can also use a ready-made CI/CD or infrastructure as code module. Governance can add DevOps and security elements to the modules.

Some organizations, once they have visibility, change how they work internally and with their vendors.

Monitoring leaves room for exceptions and closes the loop

The fourth step is monitoring, because not everything can be automated and not everything is worth automating. It would be easier to impose FinOps on day one with no exceptions, but the business will demand them. Monitoring shows where the exceptions are, protects against regression and lets the process grow. This is the less pleasant part, and it moves slowly: architecture reviews, rules for developing vendor documents, and reporting.

The conclusions from nudging and monitoring go back to the documents from the first step and show how the organization, its vendors and the existing systems should change. This creates a feedback loop in which the process changes along with the organization.

The first rollout phase shows what happens in the organization

Protopia splits the rollout of the whole process into three main phases, and the first one should show what is actually happening in the organization. It covers the inventory, setting up alerts, a license review and identifying resources through tags. As a rule, Protopia also applies simple standards found in every organization, such as the automations from the third step and backup retention automation. These practices reach beyond FinOps. Along the way, things that do not comply with security policies and compliance requirements often come to light.

In Protopia’s experience this phase takes roughly 2–3 months, no longer, because Protopia does not want to drag it out. The time depends on the organization.

In this phase the client mainly provides access and names contact people. They answer questions about naming standards, how the systems are built and which vendor delivers what, in other words tribal knowledge that is often missing from the documentation. As a rule, this adds up to a few person-days over the whole phase.

The second phase turns visibility into concrete changes

The second phase draws conclusions from visibility and starts conversations about optimizing existing resources. Protopia shows how much the client can save, then asks the vendor how much the change costs to implement. Sometimes the cost of the change may exceed the savings. Sometimes the vendor prices the change high, and Protopia presents counterarguments. This can become a negotiation over where real effort is worth putting in.

The phase also includes a detailed review of new architectures. Earlier the work was about general things; now it is about new systems and the delivery process in the organization. This review produces a set of good practices that feeds the first step of the process.

The FinOps process is now tailored to the specific organization, including who the points of contact are. Decisions are made about what becomes a shared resource, what is kept separate and how to manage shared resources. Changes to cloud resources will most often be required, but Protopia tries to keep them as small as possible. Protopia can deliver the shared resources itself, for example as infrastructure as code with a CI/CD pipeline for automatic deployment. The client gets a resource that is manageable and has minimal maintenance cost.

The client takes part in this work, and the knowledge transfer is meant to let the organization use and manage these tools on its own. The phase usually lasts about six months: it starts with a larger scope and slowly winds down.

The third phase maintains the FinOps culture indefinitely

The third phase never ends, because what is being built is a process. At this stage the organization already has good practices, policies, automations and monitoring. It maintains the FinOps culture on its own, and Protopia can support it. The organization expands this culture, runs the feedback loop and adds small elements that keep the process paying off for the organization. Oversight of old system migrations and reviews of systems that are still being rolled out can continue. The process also expands to the remaining parts of the organization.