You have probably wondered how much the infrastructure of your project costs. Interestingly, the growth of expenses is not linear in relation to loads. Many business owners, CTOs, and developers subconsciously realize that they are overpaying. But for what exactly?
Usually, cost reduction boils down to simply finding the cheapest solution, an AWS tariff, or, if we are talking about physical racks, optimizing hardware configurations. Moreover, this task is often undertaken by anyone willing to take it on: if we are discussing a startup, it’s likely handled by the lead developer, who has their hands full. In larger companies, this responsibility falls to the CMO/CTO, and sometimes the CEO personally gets involved with the CFO. In general, these are the people who already have a lot on their plates. Consequently, infrastructure bills continue to rise, but those who are supposed to address this issue are the ones who don’t have the time to manage it.
If the office needs to purchase toilet paper, the office manager or a responsible person from the cleaning company will take care of it. When it comes to development, it's the leads and the CTO. Sales is clear too. But since the days when a 'server' referred to a cabinet housing a regular tower system unit with a bit more RAM and a couple of hard drives in RAID, everyone (or at least many) has ignored the fact that purchasing resources should also be handled by a specially trained person.
Unfortunately, historical memory and experience indicate that this task has been shifted onto 'random' people for decades: whoever was closest to it just picked it up. Only recently has the profession of FinOps started to take shape and gain some concrete definitions in the market. This is the specially trained individual whose job is to oversee the purchasing and utilization of resources, ultimately aiming to reduce the company's expenses in this area.
We are not advocating against expensive and effective solutions: each business must decide for itself what it needs for comfortable operation in terms of hardware and cloud pricing. However, one cannot ignore the fact that thoughtless purchases "by the list" without subsequent monitoring and usage analysis can lead to significant losses for many companies due to ineffective management of their backend "assets."
Who is FinOps
Let’s assume you have a solid enterprise that salespeople breathlessly refer to as an "enterprise." It’s likely that, "by the list," you’ve bought a dozen or so servers, AWS, and a few other things "on the side." This makes perfect sense: in a large company, there’s constantly some movement—some teams grow, others disband, and some transfer to neighboring projects. And this combination of movements, along with the "by the list" procurement mechanism, ultimately leads to new gray hairs when reviewing the next monthly infrastructure bill.
So what should you do—patiently grow gray hairs, cover them up, or figure out the reasons behind those numerous horrible zeros on the bill?
Let's be honest: getting approval, authorization, and direct payment for a request within the company for the same AWS tariff is not always (in reality—almost never) a quick process. And precisely because of the constant corporate movement, some of these purchases can get "lost" somewhere. And simply sit idle. If a diligent admin can notice an orphaned rack in their server room, with cloud tariffs, it's much sadder. They can sit "on the sidelines" for months—paid for, but at the same time no longer needed in the department for which they were acquired. Meanwhile, colleagues from the neighboring office start tearing their hair out—not just on their heads but in other areas—as they haven’t been able to get approval for a similar AWS tariff that they desperately need for weeks.
What is the most obvious solution? Right, pass the reins to those in need, and everyone is satisfied. But horizontal communication is not always well established. And the second department might simply not know about the resources of the first, which has turned out to be less necessary for them.
Who is to blame? — To be honest, no one. That's just how things are set up for now.
Who suffers from this? — Everyone, the entire company.
Who can fix the situation? — Yes, indeed, FinOps.
FinOps is not just a bridge between developers and the equipment they need, but a person or team that knows where, what, and how well things are positioned in terms of the cloud tariffs purchased by the company. In fact, these people should work hand in hand with DevOps on one side and the finance department on the other, serving as an efficient intermediary and, most importantly, an analyst.
A bit about optimization
Clouds. Relatively cheap and very convenient. But this solution stops being cheap when the number of servers reaches double or triple digits. Moreover, the cloud allows you to use more and more services that were previously unavailable: including databases as a service (Amazon AWS, Azure Database), serverless applications (AWS Lambda, Azure Functions), and many others. They are all great in that they are easy to use — just buy and go, no hassle. However, the deeper the company and its projects dive into the cloud, the worse the CFO sleeps. And the quicker the CEO is going gray.
The thing is, bills for various cloud services are always extremely confusing: you might receive a three-page breakdown for one item detailing where, what, and how your money was spent. This is certainly nice, but deciphering it is practically impossible. Moreover, our opinion on this matter is far from unique: there are entire services dedicated to translating cloud bills into human language, for instance, or . If someone has gone through the trouble of creating a separate service for bill breakdowns, then the scale of the problem has exceeded the cost of hair dye.
So, what does FinOps do in this situation:
- clearly understands when and in what volumes cloud solutions were purchased.
- knows how these resources are being utilized.
- redistributes them according to the needs of various departments.
- does not purchase 'just because.'
- and ultimately — saves your money.
A great example is cloud storage for a cold backup of a database. For instance, you archive it to reduce the amount of space and traffic consumed during storage updates. Yes, it seems like a trivial situation in a specific case, but the accumulation of such trivial situations leads to excessive expenses on cloud services.
Or another situation: you have purchased power reserves on AWS or Azure to avoid falling under peak loads. Can you be sure this is the optimal solution? After all, if these instances are idle 80% of the time, you are essentially giving money to Amazon. Moreover, for such situations, AWS and Azure have burstable instances — why have servers burning idle resources when tools are available specifically to address peak load issues? Alternatively, instead of On-Premise instances, it might be worth looking into Reserved instances — they are much cheaper, plus discounts are often available.
Speaking of discounts
As we mentioned at the beginning, purchasing is often handled by just about anyone — they find someone to take the blame, and then they manage on their own. Most often, the person who ends up being the "blame-shifter" is already busy, and as a result, we end up with a situation where they quickly, yet competently and completely independently, decide what and in what quantities to purchase.
However, by interacting with a sales representative from the cloud service provider, you can obtain better terms if you are talking about bulk purchasing of resources. It's clear that such discounts won't be given by a machine during silent and one-sided arrangements — but speaking with a real sales manager might yield results. They might also suggest what discounts they currently have available, which can also be useful.
It's important to remember that AWS or Azure are not the only options available. Of course, there's no talk of setting up your own server farm — but there are alternatives to these two classic solutions from giants.
For example, Google offers the Firebase platform for companies, where you can deploy the same mobile project ready-to-go, which may require rapid scaling. Storage, real-time databases, hosting, and cloud data synchronization are all accessible in one place with this solution.
On the other hand, if we’re not talking about a monolithic project, but rather their aggregate, a centralized solution is not always beneficial. If the project is long-lasting, has its development history, and a corresponding amount of data that needs to be stored, then it’s worth considering a more fragmented hosting approach.
When optimizing costs for cloud services, you may suddenly realize that for critically important business applications, it’s worth investing in more powerful plans that will ensure uninterrupted operation for the company. At the same time, storing 'legacy' development, old archives, databases, etc., in expensive clouds is not the best solution. Standard data centers with regular HDDs and mid-range hardware are quite suitable for such data.
Again, one might think that 'this fuss is not worth it,' but the essence of this publication is based on the fact that at various stages, responsible individuals overlook details and do things as conveniently and quickly as possible. This eventually leads to the horror bills in a couple of years.
What’s the result?
In general, the cloud is great; it solves a myriad of problems for businesses of any size. However, the novelty of this phenomenon means that we still lack a culture of consumption and management. FinOps is an organizational lever that helps utilize cloud resources more effectively. The main thing is not to turn this role into a kind of execution squad, whose task is to catch inattentive developers red-handed and 'scold' them for resource idling.
Developers should focus on development, not counting the company's money. FinOps should make both the purchasing process and the decommissioning or transfer of cloud resources to other teams a simple and pleasant experience for all parties involved.
Source: habr.com
