How much do you spend on infrastructure? And how to save on it?

Definitely, you wondered how much your project infrastructure costs. At the same time, it is surprising: the increase in costs is not linear relative to the loads. Many business owners, service stations and developers implicitly understand that they overpay. But for what exactly?

Typically, cost reduction is reduced simply to finding the cheapest solution, AWS tariff or, if we are talking about physical racks, optimization of equipment configuration. Not only that: in fact, anyone is engaged in this, as God will put it in his heart: if we are talking about a startup, then this is probably the leading developer who has enough bunt. In offices, the CMO / CTO is doing more of this, sometimes the CEO personally climbs the question for a couple with the chief accountant. In general, those people who have enough "core" concerns. And it turns out that infrastructure bills are growing, but they deal with it ... those who do not have time to deal with it.

If the office needs to buy toilet paper, the caretaker or a responsible person from a cleaning company will take care of this. If it’s about development, leads and CTO. Sales - everything is clear too. But even from bearded times, when a “server room” was called a closet in which there was an ordinary tower-sistemnik with a little more RAM and a couple of hard drives in the raid, everyone (or, at least, many) ignored the fact that also a specially trained person.
')
Alas, historical memory and experience suggest that this task was shifted over decades to “random” people: who was closer, he picked up the question. And only recently the FinOps profession began to take shape and take on some specific outlines. This is the specially trained person whose task is to control the purchase and use of capacity. And, ultimately, in reducing the company's costs in this area.

We do not agitate to abandon expensive and effective solutions: every business must decide for itself what it needs for a comfortable existence in terms of hardware and cloud tariffs. But it is impossible not to draw attention to the fact that a thoughtless purchase “on the list” without subsequent monitoring and analysis of use for many companies ultimately results in very, very substantial losses due to the inefficient management of the “assets” of its backend.

Who is FinOps

Suppose you have a solid enterprise about which salesmen aspirate say "Enterprise". Probably, “according to the list”, you bought a dozen or two other servers, AWS and one more thing “on trifles”. Which is logical: in a large company, there is always some kind of movement - some teams grow, others break up, and still others transfer to neighboring projects. And the combination of these movements in conjunction with the procurement mechanism “according to the list” eventually leads to new gray hair when viewing the next monthly bill for the infrastructure.

So what to do - patiently graying on, paint over or understand the reasons for the appearance of these many terrible zeros in the payment?

What a sin to conceal: coordination, approval and direct payment of an application within the company to the same AWS tariff is not always (in reality - almost never) quick. And just because of the constant corporate movement, some of these acquisitions can be “lost” somewhere. And corny idle. If the attentive admin notices the ownerless rack in his server room, then in the case of cloudy tariffs everything is much sadder. They can stand "laid up" for months - paid, but at the same time, no one else needs them in the department they were purchased for. At the same time, colleagues from the next room are starting to tear their hair, which has not yet turned gray, not only on the head, but also in other places - they have not been able to pay for this week the same AWS tariff that they need.

What is the most obvious solution? That's right, pass the reins to those in need, and everyone is happy. Yes, but horizontal communications are not always well established. And the second section may simply not be aware of the wealth of the first, which somehow did not really need this wealth itself.

Who is to blame? - Generally say no. So while everything is arranged.
Who suffers from this? - Everything, the whole company.
Who can fix the situation? - Yes, yes, FinOps.

FinOps is not just an interlayer between developers and the equipment they need, but a person or team who will know where, what, and how well “lies” in terms of the same cloud tariffs purchased by the company. In fact, these people have to work in the same team with DevOps, on the one hand, and the financial department, on the other hand, acting as an effective intermediary and, most importantly, analytics.

Little about optimization

Clouds Relatively cheap and very convenient. But this solution ceases to be cheap when the number of servers becomes two-digit or three-digit. In addition, clouds provide an opportunity to use more and more services that were previously unavailable: these are databases as a service (Amazon AWS, Azure Database), serverless applications (AWS Lambda, Azure Functions) and many others. They are all very cool because they are easy to use - bought and went, no problem. But the deeper the company and its projects are immersed in the clouds, the worse the CFO sleeps. And the sooner the general turns gray.

The fact is that accounts for various cloud services are always extremely confused: you can get a three-page decoding for one position, for what, where and how your money went. This, of course, is nice, but to understand it is almost unreal. Moreover, our opinion on this issue is far from the only one: in order to transfer cloud accounts to human, there are entire services, for example www.cloudyn.com or www.cloudability.com . If someone was confused by the creation of a separate service for decoding accounts, then the scale of the problem 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 powers are used.
• redistributes them, depending on the needs of a unit.
• does not buy "so it was."
• and ultimately saves you money.

A great example is cloud storage of a cold copy of the database. For example, do you archive it in order to reduce the amount of consumed space and traffic when updating storage? Yes, it would seem, the situation is a penny - in a particular case taken, but the totality of such penny situations later turns into exorbitant expenditures on cloud services.

Or another situation: you have purchased for emergency power at AWS or Azure, in order not to fall under peak load. Is it possible to be sure that this is the optimal solution? After all, if these instances are idle for 80%, then you just donate money to Amazon. Moreover, for such cases, the same AWS and Azure have burstable instances - why do you need idle servers, if you can use the tool to solve the problems of just peak loads? Or, instead of instances, On Premise is worth looking in the direction of Reserved - they are much cheaper and they are also given discounts.

Speaking of discounts

As we said at the beginning, anyone often deals with purchases — they found the last one, and then he himself somehow. Most often, people are already “extreme” and so busy, and as a result we get a situation where a person quickly and efficiently, but completely independently decides what and in what quantities to purchase.

But when interacting with a salesperson from a cloud service, you can get more favorable terms, if we are talking about wholesale purchase of capacities. It is clear that to get such discounts at the car with a silent and one-sided design will not work - but after talking with a real sales manager, it may burn out. Or, these guys can tell what they have now discounts. It is also useful.

At the same time, you need to remember that the AWS or Azure light did not come together. Of course, there is no question of organizing your own server - but there are alternatives to these two classic solutions from the giants.

For example, Google brought a Firebase platform for companies, on which you can “turnkey” place the same mobile project, which may require rapid scaling. The storage, realtime database, hosting and cloud data synchronization using the example of this solution are available in one place.

On the other hand, if we are not talking about a monolithic project, but about their totality, then a centralized solution is not always beneficial. If the project is long-lived, has its own development history and the corresponding amount of data required for storage, then it is worth thinking about a more fragmented location.

By optimizing the cost of cloud services, you can suddenly realize that for business-critical applications, you can buy more powerful tariffs that will provide companies with uninterrupted earnings. At the same time, the “legacy” of development, old archives, databases, etc., to be stored in expensive clouds, is a solution for yourself. After all, for such data is quite suitable and a standard data center with conventional HDD and medium-sized iron without any lotions.

Here again, you might think that “this fuss is not worth it,” but the whole problem of this publication is based on the fact that at various stages responsible people are clogging up on trifles and doing things as quickly and conveniently as possible. What, in the end, after a couple of years results in those horror accounts.

What is the result?

In general, clouds are cool, they solve a bunch of problems for a business of any size. However, the novelty of this phenomenon leads to the fact that we still do not have a culture of consumption and management. FinOps is an organizational leverage that helps users use cloud power more efficiently. The main thing is not to turn this position into an analogue of the firing squad, whose task will be to catch the inattentive developers by the hand and “scold” the downtime of capacities.

Developers should develop, rather than count, company money. And FinOps should make both the buying process and the process of writing off or transferring cloud capacity to other teams a simple and enjoyable event for all parties.