La Fourche is an online grocery store that won the hearts of thousands by making the highest-quality, organic products accessible to everyone.
Like every startup, La Fourche needed to prepare for its platform to take off anytime. One mention in mainstream media could bring lots of people to their store.
So, the company needed a solution that would allow scaling resources rapidly
to handle a sudden surge of traffic.
Building such scalability into a data center was next to impossible.
La Fourche turned to the cloud and ran its applications on Amazon EC2 instances.
When the company’s CTO Martin Le Guillou joined the team, he decided that this setup couldn’t scale easily and chose Kubernetes instead, running it on Amazon Elastic Kubernetes Service (EKS).
If La Fourche waited any longer, they might have fallen victim to the never-ending cycle of growing cloud bills and long-term savings plans.
“In a business like ours, you never know when you’ll need extra resources. Someone might mention your service on national TV and boom! Without any warning, you get thousands of people coming to your online store. I’ve lived through this in one of my previous jobs - the startup wasn't prepared for that and couldn’t handle the load. I wanted to make sure that a crash like that never happened to La Fourche.”
One year into running Kubernetes on Amazon EKS, La Fourche started to spend around $4-5k on compute resources from AWS and noticed these expenses growing over time.
“When I joined the company, the AWS bill was less than $1k. But seeing it gradually rise made me realize that we need to get interested in cost optimization. We were overprovisioning our Kubernetes nodes and fixing that would be difficult.”
The wake-up call came in March 2021, when the company received a bill of more than $10k, with $5,708.47 of compute costs.
“When I saw that bill, I thought:
Ok, we could do better than that. If we managed to save up on the cloud, I could hire an additional developer and grow our team. This is when I started looking for a solution and learned about CAST.AI.”
Martin started with the CAST.AI Savings report. He created an account and ran the CAST.AI agent in read-only mode in the EKS infrastructure. The Savings Report showed that moving to different virtual machines would bring benefits in terms of both cost and performance.
La Fourche was using fifteen t3.2xlarge and two t3.xlarge instances that at the time of running the analysis generated the cost of $4,349.95.
CAST AI suggested moving workloads to five c5a.2xlarge instances. The cloud bill would then amount to $1,310.40 - a smashing 69.9% savings on the current setup.
This recommendation was based on the thorough benchmarking of over 100 instance types across major cloud providers CAST.AI carried out to determine the best performance vs. price combinations.
La Fourche started to get interested in cost optimization around the time when it got mentioned in a major European TV show. That’s why the CTO provisioned more resources to handle the incoming traffic - only to find out that autoscaling didn’t remove unused resources.
“When I scaled the pod down, the nodes didn’t scale down. That’s because of how the AWS autoscaler works. It doesn’t remove nodes when they’re not needed anymore. I realized that having an autoscaler mechanism that would do this for us would be amazing. CAST.AI has a feature for this called Evictor.”
La Fourche has already installed other CAST AI features in the pre-production environment and looks forward to seeing the results.
“Startups like us need to have the ability to scale really fast when we get covered by the media and suddenly lots of people start coming our way. We tried a few solutions, but none supported us properly because they couldn’t autoscale using the best nodes matching our needs. CAST.AI is a good product because it offers features that aren’t available in most node autoscalers on the market. I think its autoscaling capabilities can make a real difference to an e-commerce company.”