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

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

Usually, cost reduction comes down to simply finding the cheapest solution, the AWS tariff, or, if we are talking about physical stands, optimizing the configuration of the equipment. Not only that: in fact, anyone does this, as God puts it into the soul: if we are talking about a startup, then this is probably the leading developer with enough bunting. In larger offices, CMO / CTO deals with this; at times, the CEO personally intervenes in a couple with the chief accountant. In general, those people who have enough “profile” worries. And it turns out that infrastructure bills are growing, but they figure it out ... those who don’t have time to deal with it.

If you need to buy toilet paper at the office, the supply manager or a responsible person from the cleaning company will do this. If we are talking about development - leads and CTO. Sales - everything is clear too. But even from the bearded times, when the “server” was called the cabinet, in which there was an ordinary tower-system with a little more RAM and a couple of hards in the raid, all (or at least many) ignore the fact that capacity purchases should be dealt with also a specially trained person.

Alas, historical memory and experience indicate that this task has been shifted for decades to “random” people: whoever was closest picked up the question. And only recently the FinOps profession began to take shape and take on some specific outlines on the market. This is the very specially trained person whose task is to control the purchase and use of capacities. And, ultimately, in reducing company costs in this area.

We do not campaign to abandon expensive and effective solutions: each business must decide for itself what it needs for a comfortable existence in terms of iron and cloud tariffs. But one cannot but pay attention to the fact that thoughtless purchasing “on a list” without subsequent monitoring and analysis of use for many companies as a result results in very, very substantial losses due to inefficient management of the “assets” of its backend.

Who is FinOps

Let's say you have a solid enterprise, about which sellers aspirate say "enterprise". Probably, “on the list” you bought a dozen or two servers, AWS and something else “on the little things”. Which is logical: in a large company, there is some kind of movement - some teams grow, others break up, and others transfer to neighboring projects. And the combination of these movements in conjunction with the “list-based” procurement mechanism ultimately leads to new gray hair when viewing the next monthly infrastructure bill.

So what to do - patiently go gray further, paint over or figure out the reasons for the appearance of these many terrible zeros in the payment?

It’s a sin to conceal: approval, approval and direct payment of an application within the company for the same AWS tariff is not always (almost never) a reality. And just because of the constant corporate movement, some of these acquisitions may be “lost” somewhere. And just stand idle. If an attentive admin notices an ownerless rack in his server room, then in the case of cloud tariffs, everything is much sadder. They can stand on a joke for months - paid, but at the same time no longer needed by anyone in the department under which they were acquired. At the same time, colleagues from the next office have not yet begun to tear their gray hair, not only on their heads, but also in other places - they have not been able to pay for about the same week about the same AWS tariff, which is desperately needed.

What is the most obvious solution? That's right, hand over the reins to those in need, and everyone is happy. Yes, only horizontal communications are not always well established. And the second department may simply not be aware of the wealth of the first, to which this very wealth was somehow not particularly necessary.

Who is to blame? - Generally say no one. So far, so far, everything is arranged.
Who suffers from this? - That's it, the whole company.
Who can fix the situation? - Yes, yes, FinOps.

FinOps is not just a layer 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 should work in the same team with DevOps, on the one hand, and the finance department, on the other, playing the role of an effective intermediary and, most importantly, analytics.

A bit about optimization

The clouds. Relatively cheap and very convenient. But this solution ceases to be cheap when the number of servers becomes double-digit or three-digit. In addition, the clouds make it possible 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 in that they are easy to use - bought and drove, no problem. That's just the deeper the company and its projects plunge into the clouds, the worse the CFO sleeps. And the faster the general turns gray.

The fact is that accounts for various cloud services are always extremely confusing: you can get a three-page decryption for one position, for what, where and how your money went. This, of course, is nice, but to understand it is almost impossible. 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 creating a separate service for decrypting accounts, then the scale of the problem outgrew the cost of hair dye.

So what FinOps does 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 particular unit.
• does not buy "that was."
• and in the end, it saves you money.

A great example is cloud storage of a cold copy of a database. For example, do you archive it in order to reduce the amount of space and traffic consumed when updating the storage? Yes, it would seem that the situation is cheap - in a specific case, but the totality of such cheap situations then translates into exorbitant costs for cloud services.

Or another situation: you bought a reserve power on AWS or Azure, so as not to fall under peak load. Can you be sure that this is the best solution? After all, if these instances are idle 80%, then you just give money to Amazon. Moreover, for such cases, the same AWS and Azure have burstable instances - why do you need free smoking servers, if you can use the tool to solve problems of just peak loads? Or instead of On Premise instances, you should look in the direction of Reserved - they are much cheaper and offer discounts on them.

Speaking of discounts

As we said at the beginning, anyone is often engaged in procurement - they found the last one, and then somehow he himself. Most often, people who are already busy become “extreme”, and in the end we get a situation when a person quickly and skillfully, but completely independently decides what and in what quantities to buy.

But when interacting with the seller from the side of the cloud service, you can get more favorable conditions when it comes to the wholesale purchase of capacities. It is clear that receiving such discounts from a car with silent and one-sided registration will not work - but after talking with a real sales manager, it may burn out. Or these guys can tell what they have discounts for now. Also useful.

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

For example, Google brought the Firebase platform for companies, on which it is possible to place the same mobile project on a turnkey basis, which may require fast scaling. Storage, real-time 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 combination, 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 placement.

When optimizing the costs of cloud services, you may suddenly realize that for business-critical applications, you can buy more powerful tariffs that will ensure uninterrupted earnings for the company. At the same time, the “legacy” of development, old archives, databases, etc. to be stored in expensive clouds is a solution for yourself. Indeed, for such data, a standard data center with conventional HDDs and medium-power hardware without any “lotions” is quite suitable.

Here again, you might think that “this fuss is not worth it,” but the whole issue of this publication is based on the fact that at various stages responsible people hammer on trifles and do it in a way that is more convenient and faster. Which, in the end, in a couple of years translates into those same horror accounts.

What is the result?

In general, clouds are cool, they solve a lot 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 you leverage your cloud power more efficiently. The main thing is not to turn this post into an analogue of the firing squad, whose task will be to catch inattentive developers by the hand and “scold” them for downtime.

Developers should develop, not count the money of the company. So FinOps should make both the purchase process and the process of decommissioning or transferring cloud capacity to other teams an event simple and enjoyable for all parties.