It would seem that customers of public cloud providers are just loving life right now. And I would classify myself in the same group. We’re like kids in a candy store with the flexibility that goes along with “anything-as-a-service". We’re spinning up resources, building clusters, decoupling application functionality by adding load-balancers in-between - and all of this without the lengthy and expensive procurement process. With public clouds’ billing on a pay-as-you-go basis, reserved instances aside, this of course means that there are no upfront expenses to worry about, and companies (especially enterprises) are jumping for joy to convert their operational IT costs that the public cloud brings. But wait until someone from finance gets wind of what we’ve been up to. All the fun, agility and flexibility that comes with this new cool ‘toy’, also comes with a price tag.
If finance corners you at the coffee machine, and you have to answer to the hefty bill you racked up, here are a few pointers, and best practices you can use to ensure your cloud bill doesn’t run away with you:
Orphaned Resources
Managing resources in the cloud is quite different from managing them in an on premise environment. Traditionally we would build systems for maximum capacity to handle work-loads at peak traffic, and for testing environments as an example, we tend to start virtual machines and forget about them. In a public cloud environment, there’s a bit of a mind-shift needed – we are charged for the time we are using a specific service. We can spin up resources as and when we need them, but the key part is to also terminate them when we’re done using them. Be aware of boot volumes that are stored when instances are stopped/paused, or if the user created the volume without ‘Delete on Terminate’ selected. This storage cost can easily be forgotten about.
Also, do we really need 8x CPUs and 32GB of RAM to run our web server? Just because the virtual machine in our datacenter is provisioned with this amount of resources, doesn’t mean we need the same when moving it to the cloud. Always keep the cloud’s billing model in mind – the more you use, the more you pay. This is a common fit-fall for companies whom are starting to embrace the cloud.
It is a much better cost savings design to have a number of instances with fewer resources to handle ‘quiet’ periods, and we can spin up (deploy) more of the same instances if and when user demand increases.
Switch off QA and Dev environment.
If we simply stop/pause instances that we’re not constantly utilizing, we’ll save money on the compute power that would have gone to waste.
If it seems like a hassle to start and stop instances every day, do keep in mind that we’re living in the future. It’s all too possible to schedule your QA and Dev environments to start only on weekdays, at 8am, and stop again at the end of the day. And this is just one example – Scaling your resource pools up and down, based on incoming requests is one of the major benefits of the public cloud today.
Use Serverless where possible
It’s not always required to run your workloads on virtual machines that you manage yourself. For every instance that’s running in your environment, you’ll have to manage operating systems, security patches, firewalls etc. Why not utilize a serverless service where possible? Serverless is a service that takes care of the management of your instances. Why pay for idle resources when the code that it runs, is only executed every now and then? Well, serverless can definitely work for you. And you don’t have to worry about managing infrastructure. You can simply upload your code to your serverless provider, and specify triggers and run-time parameters, and the provider will ensure that your code is executed when needed.
Now, serverless doesn’t fit every use case – and not every application can be run from a serverless environment. But it does alleviate some operational pressure and saves money on idle compute resources.
Choosing your region
Cloud providers select specific geographical regions around the world to host the servers that you as their customer utilize to spin up/deploy your compute instances, or store your files, among all their other services. The amount that, we as the customers, are charged for a specific service, can vary depending on the cloud providers’ operational costs like energy expenses and real estate costs to run their datacenters in every region. Basically, what I’m trying to say is that, your service-A can be cheaper in Region-X vs Region-Y.
Often, choosing the right region for your workload requirements are more often than not, driven by latency requirements, and with that, user experience. However, as your cloud footprint expands, keeping your cloud costs down can be an even greater concern. Besides, with CDN-type services, and the big cloud providers now having a presence around the globe, latency is no longer at the forefront of region selection decisions.
Fine tune your IT infrastructure
Picking up from my earlier point around serverless; cloud providers offer a wide range of different services, and several them with a mixed level of responsibility to the user. A service where the user isn’t responsible for any of the upkeep of the underlying components, is classified as a managed service.
A managed relational database service is a popular one – and just one example. By signing up for this service the cloud provider takes full responsibility of your database. They will manage everything from the underlying infrastructure, the OS-level management, updates thereof, high availability of the database, the patch management of the database engine, even backing up of your databases. Which is rather convenient - you wouldn’t have to manually set up any of your database mirroring, failover clusters or take care of scaling.
And at times of disaster? Once again, you don’t have to worry about managing your backups as the provider automate this process as well.
Comparing this to running your own virtual machines and installing the database engines, you’ll have to take care of all administrative tasks on the underlying infrastructure and platform side on which your application runs.
However, a managed service does remove some flexibility from the equation. Where you have less responsibility, you also have less flexibility. These services are never a one-size-fits-all solution, and should be considered based on your organization’s requirements. They are a great fit for organizations who:
- Don’t have the capital for expensive teams of database administrators (following the example of managed relational database service used) to manage and patch systems.
- Want software developers to focus on the product and accelerate productivity.
From a cost point of view, and at face value, managed services tend to be marginally more expensive. However, the time, effort and above-mentioned operational costs, saved managed services can go a long way in speeding up your time to market, and time to reach a minimal viable product – which saves in the long run.
Conclusion: Optimizing your cloud spend
Optimizing your cloud spend is an ongoing task – Make peace with it now, this is just another thing to take care of on a daily basis when managing cloud-based solutions. And of course, it’s not always as easy as deleting a few stale resources or writing a quick schedule to shut down your instances when it’s home time.
Since the uptake of the cloud we’ve seen a big shift in how cloud-based environments are architected and managed – and I believe this will be an evolving effort. Today’s big cloud providers are continuously releasing new services, and enhancing their existing ones, and this could mean a cheaper alternative to how you’re delivering a specific function to your business at the moment.
The solution to yesterday’s problem can be fixed with a cheaper approach, today