Definitely, you wondered how much the infrastructure of your project costs. At the same time, it is surprising: the growth of expenses is not linear with respect to workloads. Many business owners, service stations and developers implicitly understand that they are overpaying. But for what exactly?
Typically, cost reduction comes down to simply finding the cheapest solution, AWS pricing, or, in the case of physical racks, optimizing the hardware configuration. Not only that: in fact, anyone is engaged in this, as God puts it into his soul: if we are talking about a startup, then this is probably a leading developer who has enough firebrands. In larger offices, this is done by the CMO / CTO, sometimes the general director personally gets into the question together with the chief accountant. In general, those people who have enough "profile" concerns. And it turns out that infrastructure bills are growing, but deal with it ... those who do not have time to deal with it.
If you need to buy toilet paper for the office, the supply manager or a responsible person from the cleaning company will do this. When it comes to development - leads and CTO. Sales are also clear. But since the bearded times, when a “server” cabinet was called a cabinet in which there was an ordinary tower system unit with a little more RAM and a couple of hard drives in a raid, everyone (or at least many) ignores the fact that capacity purchases should be dealt with also a specially trained person.
Alas, historical memory and experience show that for decades this task was shifted to “random” people: whoever was closer picked up the question. And only recently, the FinOps profession began to take shape and take on some concrete outlines on the market. This is the same 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 are not campaigning to abandon expensive and effective solutions: each business must decide for itself what it needs for a comfortable existence in terms of hardware and cloud rates. But it is impossible not to pay attention to the fact that thoughtless purchase “on the list” without subsequent control and analysis of use for many companies results in very, very solid losses due to inefficient management of the “assets” of their backend.
Who is Finops
Let's say you have a solid enterprise, about which salespeople aspirate "enterprise". Probably, “according to the list” you bought a dozen or two servers, AWS and something else “little things”. Which is logical: in a large company, some kind of movement is constantly taking place - some teams grow, others break up, others are transferred to neighboring projects. And now, the combination of these movements, together with the “list” purchasing mechanism, ultimately leads to new gray hairs when looking at the next monthly infrastructure bill.
So what to do - patiently continue to go gray, paint over or figure out the reasons for the appearance of these many terrible zeros in the payment?
It’s a sin to hide: coordination, approval and direct payment of an application within the company for the same AWS tariff is not always (in reality, almost never) fast. And just because of the constant corporate movement, some of these very acquisitions can be "lost" somewhere. And it's trite to stand idle. If an attentive admin notices an ownerless rack in his server room, then in the case of cloud rates, everything is much sadder. They can be laid up for months - paid for, but at the same time no longer needed by anyone in the department under which they were purchased. At the same time, colleagues from the neighboring office begin to tear their hair that has not yet turned gray not only on their heads, but also in other places - they have not been able to pay for about the same AWS tariff for a certain week, which they desperately need.
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 know about the wealth of the first, which somehow turned out to not really need this very wealth.
Who is to blame? “Actually, no one. So far everything is arranged.
Who suffers from this? Everything, 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 it “lies” in terms of the same cloud tariffs purchased by the company. In fact, these people should work in tandem with DevOps on the one hand, and the finance department on the other, acting as an effective intermediary and, most importantly, analytics.
A bit about optimization
Clouds. Relatively cheap and very convenient. But this solution stops being cheap when the number of servers becomes double or triple digits. In addition, 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 because they are easy to use - buy and go, no problem. But the deeper the company and its projects plunge into the clouds, the worse the financial director sleeps. And the faster the general turns gray.
The fact is that invoices 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 pleasant, but it is almost impossible to understand it. Moreover, our opinion on this issue is far from the only one: in order to transfer cloud accounts to a human one, there are entire services, for example or . If someone was confused by the creation of a separate service for deciphering invoices, then the scale of the problem outgrew 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 being used.
- redistributes them, depending on the needs of a particular unit.
- does not buy "to be".
- and in the end - saves you money.
A great example is cloud storage of a cold copy of a database. Do you, for example, 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 penny - in a particular case, but the totality of such penny situations then translates into exorbitant costs for cloud services.
Or another situation: you bought a reserve of power on AWS or Azure in order not to fall under peak load. Can you be sure that this is the optimal solution? After all, if these instances are idle 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 smoking servers if you can use a tool to solve problems just like peak loads? Or instead of On Premise instances, you should look towards Reserved - they are much cheaper and they also give discounts.
Speaking of discounts
As we said at the beginning, anyone is often involved in purchases - they found the last one, and then he somehow himself. Most often, people who are already so busy become “extreme”, and as a result, we get a situation where a person quickly and skillfully, but completely independently decides what and in what quantities to buy.
But when interacting with a salesperson from the cloud service, you can get more favorable conditions when it comes to the wholesale purchase of capacities. It is clear that getting such discounts from a car with a 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 you what they have discounts on now. It's also useful.
At the same time, you need to remember that the light has not converged on AWS or Azure. Of course, there is no question of organizing your own server room - but there are alternatives to these two classic solutions from giants.
For example, Google brought the Firebase platform to companies, on which it is possible to host the same mobile project on a turnkey basis, which may require rapid scaling. Storage, real-time database, hosting and cloud data synchronization using this solution as an example 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 history of development and the corresponding amount of data needed for storage, then you should think about a more fragmented placement.
While optimizing cloud spending, you may suddenly realize that for business-critical applications, you can also buy more powerful tariffs that will provide the company with uninterrupted earnings. At the same time, the “legacy” of development, old archives, databases, etc., to be stored in expensive clouds is such a solution. After all, for such data, a standard data center with conventional HDDs and medium-power hardware without any “bells and whistles” is quite suitable.
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 score on trifles and do it in a way that is more convenient and faster. Which, in the end, in a couple of years results in those same horror accounts.
The result?
In general, clouds are cool, they solve a lot of problems for businesses 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 lever that helps you make better use of cloud power. The main thing is not to turn this position into an analogue of a firing squad, whose task will be to catch inattentive developers by the hand and “scold” them for downtime.
Developers should develop, not count the company's money. And so FinOps should make both the process of buying, and the process of decommissioning or transferring cloud capacity to other teams, an event that is simple and enjoyable for all parties.
Source: habr.com