Ever heard the story of the developer who left his top-tier ‘PoC instance’ of Synapse turned on for the whole night? Just to discover his company had to pay €1000+ for this mistake?
This story has already become an urban legend.
There’s no denying that costs of cloud environment and infrastructure can easily get out of hand.
However, this story above can be treated as an incident. It is rather an exception than a rule. What usually happens could be related to one of the following scenarios.
gROWTH GOES OUT OF CONTROL
The customer has been rapidly growing his business over the last few months. This growth did not fully happen on a par with the implementation of proper cloud environment governance in his subscriptions.
During initial creation of the first projects and workloads in Azure:
- No-one has configured cost alerts
- No cost budgeting was set up
- No assumptions regarding allowed resource sizing have been taken
- All resource types were allowed to be created
- No control over who can create what kind of resources has been established
Over the months that followed the transition to Azure, too few people have been tasked to administer the cloud environment.
As a result, the admins started to be overwhelmed with requests from users coming from different business units. To relieve the situation, cloud team started to generously assign rights to create resources…
You already know what happened next. VMs, databases and other services started to be created on a completely ad hoc principle, which eventually significantly inflated the Azure invoices.
more control = more costs?
The customer is a large and therefore strictly partitioned organization. While a central enterprise data strategy is lacking, every department and every business unit has their own IT budget, their own resources and create their own environments for data processing and visualizing. These are usually called data silos.
This organizational setup ends up generating tremendous cost redundancy. It happens that e.g. five business units create their own, almost identical, resources without pooling them. Different departments acquire external data sources on their own instead of processing this expenditure centrally, based on the company data strategy. Addressing such inefficiencies could significantly slash infrastructure costs.
At this point, you could say that strict control over resource creation rights would be sufficient to throttle the rising cloud costs. Unfortunately, this is only partially true.
What would be the desired outcome of cost optimization, then?
The objective of cloud cost optimization is to increase administrative power and exert control over your cloud implementation without fully restraining the initiative of your different BUs. Otherwise, you will most probably trigger shadow IT activities, which you initially intended to avoid!
3 KEY ASPECTS TO CONTROL YOUR COSTS
Cost-control setup and processes
Setting up different cost-control processes on your cloud provider tenants should be treated as a continuous process that is initiated at the very same moment whenever your environment goes live for the first time. Afterwards, regular reviews to those policies should be incorporated into the scope of responsibilities of your administrators.
The approach should be similar to zero-based accounting: every expenditure needs to have a business justification. On top of that, these costs should be compared with the benefits that are generated by the floating infrastructure costs. Treat as an investment and validate the ROI.
As an example, simple policies could restrict rights to creating high-tier databases only to specific users with elevated privileges. Similarly, this access could be restricted to specific geographic regions.
Another idea would be to set cost caps on resource groups and automated shutdowns on resources that belong to that group whenever a certain cost threshold is reached. This is a scenario that specifically fits proof of concepts projects: this way, you make sure nobody forgets about that environment which is still up and running weeks after PoC closure…
Resource monitoring should be treated as a basic means of validating whether the costs that your allocated resources generate are proportionate to your business needs, system availability and performance. Thanks to that, we are able to automatically assign more capacity during peak usage time and scale down during idle time.
Monitoring can be applied to all different kinds of resources, including storage resources, compute resources, data models and reporting resources.
According to the FinOps Foundation Technical Advisory Council:
“FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions”.
FinOps is broken down into three phases: Inform (Visibility & Allocation), Optimize (Rates & Usage), Operate (Continuous Improvement & Operations). Basically, FinOps should be regarded as a means of distributing ownership and best practice in order to instill cost-controlling without losing agility.
All those three key aspects need to be implemented together so that you ensure that cloud spending is controlled, and so that it does not happen at the expense of the ability of your business teams to deliver results fast.
Stay tuned for the next articles in this series where I will describe more examples how I help customers to curb their cloud spending while staying agile.
Discover how you could leverage our experience in cloud cost controlling
to make significant (up to 50%) economies on your cloud subscription.