In the first years after the introduction of the cloud, the main focus was placed on how to leverage its benefits. At the same time, management had to deal with setting up internal cloud teams and the organizational disruption that was to follow. During all this, not all DevOps teams did worry about usage costs yet, as the cloud had a natural promise to make all operations cheaper after the initial investment. After all, they were only going to pay for what they needed and when they needed it. Even though this is still very true, the crucial part is actively working to make it real.
This became especially a concern as organizations were actively investing in the cloud. After all, the successful early adopters were the ones that chose cloud computing as an enabling technology, not as a cheap solution to an existing problem. They beat all the necessary challenges to get there: their teams got skilled and certified, potential risks were assessed and addressed, and engineers understood how to use it securely. So when everything was in place organizations started to fully adopt it and reap the benefits, primarily the newfound agility and flexibility that the cloud brought.
And the initial financial results were positive: data center costs went down and on-premise hardware upgrades (read: lump sum payments) became less of a concern. There was now a continuous expenditure that could be based on previous usage frequencies. As a result, business critical applications were confidently transitioned to the cloud and solidified in this new environment, with a common reasoning from an engineering point of view that the cloud had already been accounted for financially.
This is where things took an unexpected turn for many organizations, especially for finance departments and budget owners. Whereas IT departments and units transitioned from silos to a DevOps/DevSecOps way of working, the same was not true for the rest of the organization. Engineers started to work more confidently in the cloud and expanded their workloads, (without?) realizing that it was easier to “get things done”. They could simply provision the resources themselves and public cloud providers would be happy to oblige and provide virtually any amount of capacity almost instantly. Gone were the days when you had to collect countless signatures and approvals just so that procurement could put your request in the line. Then continue to get at least 3 different quotes from registered suppliers that would gladly deliver that server, in no less than 8 weeks.
No more bureaucracy. Working in the cloud was the equivalent of winning the corporate lottery. DevOps teams had been given a limitless company credit card to purchase cloud. But wherever money is involved, there will still be a bit of bureaucracy. And indeed, the bills arrived and charges started to pile up. This began small, but it scaled up with the increased cloud usage. To procurement and finance departments, this was unexpected and sometimes even unaccounted for. These additional expenditures could no longer be ignored, and a new priority emerged: Cloud Financial Management. But, there is no gatekeeper yet. And without strict agreement on who is allowed to spend what and when, things are bound to spiral out of control.
It is a common problem with a common cause. The cloud is powerful, has amazing capabilities, and virtually unlimited capacity. We all know the saying: with great power comes great responsibility. And with great compute power comes a great invoice, unless you learn to wisely utilize its flexibility and efficiency. The cloud should not be treated as an on-premise computer that just so happens to not be in your building. If you do not actively leverage the pay-what-you-use when-you-use-it model, your operations can become even more expensive than before you set foot in the cloud.
Now the scenario looks somewhat like this: critical systems have been solidified in the cloud, but the costs they generate are above what was provisioned. Understandably, finance departments will be pressured to deal with the additional costs and demand that this has to stop. Engineers will tell them that it is too late: if you stop these cloud environments abruptly, it will become impossible for the business to continue as it planned to do. One can’t strip the cloud from what is arguably its most important characteristic, agility. And that prevents organizations from going back to the old bureaucratic, almost paralyzing processes, yet spend cannot spiral out of control further.
Where in the past IT spend was governed by tracking resources (resources that would only be allocated provided the requester had passed some process), we should now look into tracking consumption. You cannot require authorization to run a serverless function that will exist for 10 seconds, but it will have a cost. So whose budget will be used to pay for it? How was it requested and defined anyway? And how is it allocated to the various teams? After you answer that, how will you report this to the teams to enable visibility so that they can be held accountable for what they do?
Uncomfortable situations like these are why Cloud Financial Management is one of the most highly sought after needs in the future of cloud computing. In order to manage both the technical as well as the financial side, both parties need to understand each other. Better processes and agreements are necessary to prevent getting surprised by the next bill every month.
It is fundamental for both parties to understand each other before they can accept what the other is struggling with and why that affects them and ultimately the business. But, becoming aware of the financial results of your cloud operations is difficult. Engineers probably won’t be spending a lot of time in the finance department. Alternatively, finance managers and budget owners will not understand exactly what they are paying for when they process the bills. We see that the only way to create awareness and accountability among both parties is to actively report on the spending and make clear what the money is being spent on or invested in.
In order to achieve this, we need to give both departments something to compare, preferably in the form of a metric system that speaks to everyone. Both sides of the spectrum need to be able to understand this: IT departments/DevOps teams, but also their non-technical counterparts.
But even if both parties are aware of this and assuming they can understand each other, how are you going to measure efficiency? It is crucial to understand where the cloud fits in the company model. When it becomes a core element, just like your IT department, it allows you to work together on realistic KPIs. Then when the cloud bill comes in, you can apply these KPIs to see how realistic they were. When KPIs are established, cloud teams will stay aware of their actions and can keep working together and continuously optimize to achieve the desired efficiency. More on this in Part 2.
At Oblivion we offer a broad range of Cost Optimization services that help you get insight into Cloud Financial Management strategies that work best for your current use case. Let us know in form below if you have a budgeting or cost optimization challenge that you’d like to discuss with us.