Due to the rapid pace of cloud innovation, cost optimization is a continuous process. Cloud environments are not stagnant. They are ever-changing, constantly evolving. Afterall, one of the main benefits of cloud computing is agility.
With the cloud, we no longer need to wait for lengthy procurement processes. Usually, teams have control to provision the resources they need immediately and remove them when they don’t need them anymore. Of course, this paradigm impacts costs. Unlike traditional infrastructure, these costs are drastically fluctuating as resources are created and taken down on demand. I won’t lie by stating that cloud cost control is easy – if that were the case, there wouldn’t be cost optimization service offerings, dedicated training, and teams of people ready to help you.
What about Right Sizing?
The phrase right sizing is thrown around a lot in terms of cost optimization. If you are using variable size resources, then right sizing is all about choosing the perfect size to maximize value and minimize cost. Some people believe they can continually throw resources at a problem to improve performance, yet at some point, they will start to see diminishing returns.
This mindset can quickly inflate costs as resources scale to meet business requirements in a less-than-ideal way. I witnessed this firsthand as a company chose EC2 instances with more memory than what was required in order to prolong a memory leak in the application code. The extra memory that was allocated enabled the application to last longer at a higher hourly rate, before experiencing the dreaded OutOfMemoryError.
As the saying goes, hindsight is 20/20. Many people will read that statement and think that their team would never do something like that. Remove the deadlines, the late night calls, and the thousands of lines of legacy code around the memory leak and it’d be easy to avoid. However, that’s not realistic. Teams that have split priorities may not always be able to choose the most cost-conscious choice. It’s common to band-aid problems to resolve issues with the plan to eventually circle back. It’s less common to actually circle back.
The Right Product
I encourage people to think about this as a product challenge instead of a right sizing challenge. Using the right product can be much more effective, even though right sizing is typically where people start. Just like you wouldn’t use a wrench to hang a picture, you shouldn’t use EC2, or any other popular service, to solve all of your business problems. Another benefit of cloud computing is access to purpose-built services.
Cloud providers serve millions of customers, and they know a thing or two because they’ve seen a thing or two.
Oftentimes if they see a problem that many customers are facing, they will develop a solution specifically to solve that problem. Cloud native applications will use the best service for the job. Their landscape can be complicated because of its various technologies. They may be using multiple databases for specific use-cases as opposed to a massive database that handles everything. These teams are trading the complexity of their environment for other benefits like reduced costs.
Choosing the right product for your use-case is trickier than scaling up, or down, what you already have running. It requires rearranging, upskilling, migration, and much more. There is no magic tool—yet, at least—that will analyze your application and spit out the optimal way to host it. Although, perhaps AWS Refactor Spaces is a good start.These types of decisions will usually take experienced individuals to carefully understand what you have and where you’re trying to go in order to make these decisions. For example:
Does it make sense to re-architect a system from virtual machines to AWS Lambda when the company is doubling down on Reserved Instances? Probably not.
Is it wise to run your most critical apps on Google Kubernetes Engine (GKE) when your team doesn’t know what Kubernetes is? Definitely not.
Should you migrate on-premises cron jobs to AWS Batch? It depends.
Does the Right Product Exist?
Yes and no. Cloud providers are constantly releasing new products to meet customer feedback. It’s possible that the right product for you simply hasn’t been created yet. It could be like using a wrench to hang a picture: the right solution is out there, but a different ill-suited tool is being used in its place. This is just another reason why competent cost optimization is an ongoing procedure.
One example is AWS ElastiCache, which was released in 2011. During AWS re:Invent 2023 ElasticCache Serverless was announced. Before ElasticCache, Serverless, teams longed for a way to stop ElasticCache clusters when they weren’t using them. Common workarounds included snapshotting and recreating or resizing the cluster to reduce costs during off-hours. Both workarounds were far from ideal as they usually meant downtime and manual effort.
With ElasticCache Serverless, the scaling is automatic. I agree that ElasticCache Serverless doesn’t handle this perfectly yet, as it can still rack up decent charges while idle. I do believe that this is a step in the right direction, though. For some teams, the reduced overhead of managing these clusters could be worth the increased costs for the serverless offering. Besides, if the cost savings opportunity is right, then it could result in savings in the end.
The only way to know when the perfect product for you is created is to try and keep up with all of the cloud announcements. Or, work with someone who will track those on your behalf.
Ready to Save?
With all things discussed and considered, do you know if you are ready to start saving and how to get started? Maybe you need a helping hand. Bravo LT can be that help. Do you want to schedule a free consultation? The best time to start is now.
Written by Justin Wheeler, Senior Software Developer.