You’ve probably wondered before how much the infrastructure of your project costs you, and you’ve definitely noticed there’s no linear relation between the cost and the workload. Many CEOs, CTOs, and developers suddenly realize that they spend way too much on infrastructure. But what exactly costs so much?

Usually, cost minimization ends up with buying the cheapest solution or AWS support plan, or optimizing the hardware configuration when it comes to physical racks. Plus, there’s no clear-cut rule to determine who might end up handling that task. In a startup, it would probably be the lead programmer, who already has a whole slew of headaches. In larger or more established companies, for example, the CMO, CTO, or even the CEO in tandem with an accountant would have to deal with it. In short, it’s not unusual to see infrastructure costs skyrocket while the situation is being handled by busy, confused staff.

When you need paper towels for the office, your office manager or outsourced cleaning service personnel will take care of it. When you need programming services, call the CTO. When you need to boost sales...well, you get the point. However, since way back, when a "server room" was not a room, but a closet with a tower holding a couple of hard drives in a RAID, everyone (ok, most of us) has turned a blind eye to the fact that there is no specially educated person who knows all the ins and outs of power capacities.

Unfortunately, my experience suggests that this task has been constantly delegated to random people: first noticed, first charged. It's only recently that the FinOps position began to take some concrete shape in the industry. FinOps is a specially trained person tasked to control the purchase and exploitation of power capacities, and, therefore, revision of a company's expenditures on infrastructure.

I’m not saying you should get rid of expensive and effective solutions. At the end of the day, every company must decide for itself what hardware and/or cloud-based systems it needs to function reliably. But you must admit that mindlessly writing checks for hardware support without further monitoring and cost-benefit analysis is not a sustainable solution.

Who the hack is FinOps?

Let's say you have a solid company, breathlessly referred to as an"enterprise" by your salespeople. In the beginning, you probably followed the standard procedure of buying dozens of servers, AWS, and some extra bits and bobs here and there. In a big company, there is constantly something going on — some teams grow, others break up or move to different projects. Thus, having extra facilities makes sense. But, the mix of these two factors will eventually make your accountants tear out their hair when they see yet another invoice for infrastructure.

What’s the best way out for the accountant? Buy a wig, pretend to be Moby, or dig into the source of that long string of zeros on all those invoices?

Let's be honest: the approval and payment process within most companies is far from perfect. However, though an unattended rack in a server room will eventually be noticed by a watchful system administrator, there’s no such guarantee for a cloud-based service with automatically recurring payments. Such a service can quickly outgrow its usefulness while the charges steadily rack up. But the saddest thing is that the team next door might be going into a tailspin because an accountant keeps rejecting their request for that same cloud-based system.

What's the most obvious solution? Let the needy teams do the management? No way! Relations between different project teams are awfully tenuous in most tech companies. One team might simply not know that the second team has a ton of value in mothballs.

Who’s to blame? — Well, no one. That's the way the cookie crumbles!

Who suffers? Well, the whole company.

Who can fix it? FinOps, ta-da!

FinOps is not just a third wheel between the developers and the necessary equipment. It is a person or a team that knows what, where, and how well the company’s data is stored. In fact, these people must work in tandem with devops, on the one hand, and the bean counters, on the other, by fulfilling the role of an efficient mediator and, most importantly, analyst.

A few words on refinement

Cloud solutions. They are relatively cheap and very convenient. (They stop being cheap, however, when the number of servers hits three digits.) Plus, cloud solutions allow you to use more and more services that were previously unavailable, including database as a service (Amazon AWS, Azure Database), serverless applications (AWS Lambda, Functions Azure), and many others. They are all very cool in principle: pay, install, and enjoy! The deeper the company merges into the clouds, however, the worse are the CFO's heebie-jeebies. (The faster the CEO loses her hair, too.)

The invoices for various cloud services are always quite messy: transactions with one expenditure item sometimes require multi-page transcripts. Unfortunately, they don't help you puzzle it out. There are even services that translate cloud invoice gibberish into human language; see, for example, cloudyn.com or cloudability.com.

So, what should a FinOps do?

  • Clearly understand what kind and how many cloud solutions were purchased, and when
  • Know how purchased capacities are used
  • Re-distribute them according to the needs of departments or teams
  • Safeguard against buying capacities just for "being on the safe side"
  • And, as a result, save your company money

Let's look at the example of storing a cold backup DB in the cloud. Say you archive it in order to reduce the space and traffic needed for a repository update. One such operation is a dime a dozen, but hundreds of them cost a pretty penny.

Or, let's look at another situation: let’s say you purchased reserve capacity on AWS or Azure to prevent failing under peak traffic. Can you be sure that’s the optimal solution? Usually, those backup servers are idle 80% of the time. That means you’re just giving your money to Amazon. Considering that the same AWS and Azure provide burstable instances for such scenarios, why should you pay for idle servers if you can use a tool that’s specifically provided as a peak traffic solution? Or, replace your ‘On Premise’ instances with ‘Reserved’ instances — they cost much less.

A few words about cash

As I said in the beginning, procurement tasks are often delegated to some random people, who are later left to themselves. Usually, those people end up deciding how much and what to purchase on a tight schedule and without advice from top managers.

Meanwhile, the company could have saved tons of money on discounts and bulk purchase reductions if only those people had spent more time, stepped out of their comfort zone, and had consultations with the cloud service salesperson. Instead of automatic selection of options on the Amazon website, a one-on-one talk with a real sales manager must take place. So, your people need to have the time, authority, and skills to scout and negotiate the best offers.

Don't forget that AWS and Azure are not the only pebbles on the beach; there are solutions from other providers. Google, for example, introduced the Firebase platform, where you can locate a project that requires fast scaling on a turnkey basis. This solution makes sure repositories, real-time DB, hosting, and cloud-based data synchronization are available in one place.

On the other hand, if you have a combination of monolith projects, a centralized solution might not be an option. A long-lived project with its own history of development and a considerable amount of data requiring a repository deserves fractionary accommodation.

When optimizing spending on cloud services, you may suddenly realize that critical applications are worthy of a more hefty expenditure that will ensure your company's revenue continues to roll in. Developers' "heritage," old archives, and databases, on the other hand, don't need costly cloud solutions. A standard data center with an average HDD and medium hardware with no bells and whistles will be more than enough.

If you think this "trifle" doesn't deserve your attention, please remember that all big problems begin when people in charge ignore little things and do the job the fastest and easiest way they know. Then, in a few years, multi-page invoices will start to arrive, and the hair-tearing will commence.

Instead of a summary...

In short, cloud solutions are cool in their ability to meet the needs of businesses of vastly different scale. Unfortunately, we still haven’t perfected a culture of consumption or control over such an innovation. FinOps represents an organizational lever arm that can help you better use cloud capacities. But please don't turn this position into a firing squad that will be tasked to trace careless developers and rap their fingers for idle capacities.

Developers should develop, not count the company's money. It is FinOps who need to make the process of cloud capacities purchasing, disposal, and transfer a simple and enjoyable time for all teams involved.