During project planning, you probably had to deal with cloud costs estimation. Finding potential savings can be difficult as the possibility of damaging teams’ productivity shall not be neglected. Let us dig into this not-so-well-known risk factor: too much cloud costs cutting.
In every organization, cloud costs are monitored at different levels: team, product line, business entity, company. Proposals to reduce costs come from different perspectives. Some suggested measures such as deploying a test environment only in a single Availability Zone can be interesting. Do you need High Availability for a non-productive environment, is it worth the thousands of dollars of inter-AZ traffic?
On the other hand, while they seemed to be a good idea in theory, some cost cutting measures do have bad effect on the business. Has your project manager ever talked to you about budget instead of costs – and how would this change your perspective? How do you decide where to cut costs? We will dive into these questions now.
Managed Service vs self-hosted
When starting a new project in the cloud, you look at many possible service alternatives. In the process, we often compare Open-Source Software alternatives which can appear more advantageous: the feature set is larger, and the costs are significantly lower than those of the cloud providers. A good example is logging in the cluster. Instead of expansive PaaS services, it may be better to run logging workloads on cloud VMs or container solutions.
At first glance, this saves costs. However, there are a couple of things to keep in mind: What about the operation? Who does the updates? Who sets it up securely? Do we have to enlarge the team? Do we have to monitor it? Nothing against OSS, as it may be the better solution if you need some features, but high-level managed cloud managed services deliver reliability and great performances which would require much more manpower if done in-house.
During low-demand hours, systems shall scale down, but the process shall be transparent to the user. Instead of letting a development team waiting for a test environment to come up every morning, this time could be used to add value to the product by working on user stories. Some cloud resources need to synchronize with each other like databases or cluster applications. It could be cheaper to let systems online as new scale-out event will generate synchronization traffic and additional time will be needed until the system is ready.
Being able to spin up instances on-demand is also a great cloud service, and some instances are cheaper than other depending on the configuration: do we already included the damaged reputation due to performance issues at the customer because of wrong instance choices? Did we consider the developer time, for analyzing why some logs arrive late, because the disks performances are slowed down strongly due to thresholds being reached? We would need a good concept to handle these cases if we want to scale down our cloud services.
Transparency within the organization
“Cloud cost reports shall be only accessible by few dedicated employees and developers do not care about costs”. You probably already heard such kind of statement. Organizations shall give much more transparency: trust your dev teams to consider cloud costs since the beginning of the project. They spend hours building services and often run them in close collaboration with platform teams.
Projects are usually doing cloud cost forecasting which gives a rough estimate, but it can be uncertain in many cases as the project grows: cloud service size, amount of data transferred, data retention policy, number of users, free tier service capacity exceeded... We should spend more time on cloud cost monitoring using cloud providers solutions as this gives quick feedback and a cloud cost trend: some measures suggested may be useful but still there is a risk of adopting counterproductive cost-saving measures.
Our message is: Consider the total cost of ownership “TCO” and not only the cloud bill. Know your cloud budget and use it at 100%.
About the author
Name: Pierre Lexis
Job: Senior DevOps Engineer
Working at MaibornWolff since: March 2020
Quote: "I do not spend my money quickly, but I enjoy spending it"