In this series, we have covered a handful of important business topics that can be tackled with container management and Kubernetes. We’ve talked about how a business can save money. We’ve answered why your architecture is important to the bottom line. And we’ve covered how Kubernetes and Supergiant can make the transition to containerized application infrastructure much easier.
Today I want to show you how to calculate the real cost savings of a switch to Kubernetes.
We will add up the real numbers that a well-configured cluster can produce. We will use Amazon Web Services in our examples, but these figures would look similar across many cloud providers. You should also get a good idea of the type of on-premise hardware savings you can expect.
I will cover the cost of running your applications on bare metal, vs. virtual machines, and vs. Kubernetes. When Kbernetes is implemented well, its infrastructure and support savings will arm your business with the means to lower prices, improve support, and give better performance to your customers.
Let’s set up a fictional scenario. Luh Elephant, Inc. is a small company that uses AWS to provide on-demand PostgreSQL database instances for customers. Since they offer full instances, the customers are very happy with the database performance they receive. However, full instances get expensive, and the price gets passed along, so customers have begun to gripe about prices.
Several competitors have also begun to offer postgres on demand but at much lower prices. Luh Elephant, Inc. suspects the use of containers, virtual machines, or some magic, but they have also noticed their competitors’ horrible performance. Luh Elephant wants to make a change to compete.
Alas, many customers are beginning to choose these cheaper alternatives, so here is the rub: how will our heroes offer competitive pricing and still meet or exceed their own current performance standards? Can they really lower prices and maintain the experience and performance their customers love and deserve?
First, let’s take a look at the infrastructure currently used to run Luh Elephant, Inc. They currently have 300 customers, and the top 100 customers are on pricey 3-server clusters. All servers for this example will be 4-core servers. In reality, the customer pool would be more diverse, but for simplicity’s sake, this will do.
This is the current hardware monthly spend of Luh Elephant, Inc. assuming AWS m4.xlarge class on-demand instances.
|200 (1 server clusters)||200||$34,894|
|100 (3 server clusters)||300||$52,341|
Pricing data: http://ec2pricing.net
RIs are a natural first step to lower spending, so let’s try that calculation first.
Academically, RIs get “1 year, partial upfront” pricing on all instances, and Luh Elephant could reduce their costs 41% to about $51,110 per month. However, reality has thrown our heroes a curveball: due to the unpredictable nature of their business, they cannot predict and reserve all needed instances for the next year.
Simply switching to a RI strategy hasn’t lowered costs enough. Getting the full amount of savings has not actually come to fruition, and in some cases, the competition’s pricing is still 50% lower. Even with a perfectly executed reserved instance scheme, the math is tight.
What has been plaguing Luh Elephant this whole time is a common problem to many organizations: one major application per server. This gets especially infuriating from a cost standpoint when servers sit underutilized or (gasp!) idle most of the time. Cramming more applications onto a server to get more value will cause all kinds of performance and noisy neighbor problems without some clever management in place.
We need to better utilize the hardware we pay for and, by proxy, the energy footprint of our businesses.
This is a highly viable option for a business, so I’ll elaborate. Over time, on-premise hardware could be the best way to offer compute power on the cheap; however, it comes with a few formidable barriers. Running hardware on premise brings costs for the hardware, costs to house the hardware, and costs for good, well-paid engineers to manage the hardware. If these roadblocks don’t present an issue, on-premise is by far the best way to go.
Exact figures for the savings of on-premise solutions are hard to provide because the savings depend entirely on execution. From experience we expect Luh Elephant could reduce infrastructure costs down to around $20,000 per month. But keep in mind this does not count additional engineer salaries, and this does not account for upfront capital outlay. Initial expenditures would be high because new hardware would require upfront purchase.
For our fledgling company, Option 1 will not work — at least not for several years. They don’t have the capital to spend upfront, and they have only 10 employees (who were hard to acquire in the first place). Finding more good talent could take months, and that is not an option in their competitive market.
Hardware cluster management tools (like Mesos, et al.) are great tools to be sure, but they don’t solve the “I want to use my hardware more efficiently” problem. They help reduce the knowledge required to effectively run production applications at scale, but scaling is handled manually. Further, these systems don’t lower your hardware spend — and they can even increase it.
Nevertheless, fret not, dear reader. Another option still exists over the horizon.
This is the perfect option for our heroes! In our first article on saving money with Kubernetes, you can get a good look into the type of resource management Kubernetes offers. Kubernetes ticks all the right boxes for a cash-strapped company that is trying to rule their market. And it does it all without sacrificing performance or user experience.
Another possible option would be to use a non-Kubernetes-based container manager. This might save a little in cost, but Kubernetes is currently the only current container manager that has the ability to allocate resource dynamically and to do it well.
Let’s break it down. We know from the previous article that in Kubernetes you could conservatively set up a resource scheme to allow you to pack 50% more resource consumption onto your hardware — and even this is adjustable. Every organization can find a ratio that best fits its applications and a desirable savings profile. 50-80% is a good place to start for most stateful applications.
|Customers||Applications||Servers (minions)||Old Cost||Kubernetes Cost|
|200 (1 server clusters)||200||100||$34,894||$17,447|
|100 (3 server clusters)||300||150||$52,341||$26,171|
Hey-Hey!! Now we’re talkin’! That’s a nice savings. And now the server counts are much more predictable. We can really get better usage from our Reserved Instances: $25,605 (41% up to about 60% for 3-year).
With these types of savings, Luh Elephant, Inc. would have no problems drastically reducing prices to be even lower than their competition AND keeping the same performance!
A nice side benefit of this infrastructure model is that Luh Elephant, Inc. can now use even larger instances if it chooses. Using larger instances in the same AWS instance class would have very little impact on server costs but would get their customers access to high-dollar cloud features that come with larger instances such as crazy high network throughput, higher storage speeds, and burstability. The larger instances can provide more space if one or a few customers temporarily burst over their usage limits. All of this gains this startup more checks in their website advantages checkbox thingy then any of Luh Elephant’s competitors can provide.
Kubernetes can be daunting at times, so Supergiant runs on top of Kubernetes and ensures that things are easier to configure for engineering and support teams. It doesn’t obscure Kubernetes in any way — it simply brings deep Kubernetes features to the surface and makes them easy to manage.
Supergiant’s packing algorithm also augments Kubernetes’ built-in resource allocation by automatically handling instance provisioning and allocation for you. If you are running large instances for your cluster, it does not make sense to start another large server for just one customer. The packing algorithm will automatically choose the correct servers that meet the specific needs of your environment.
We hope you have enjoyed this article. Check us out at supergiant.io, visit the Supergiant subreddit, or chat with us about Supergiant in the comments or in our shiny Slack channel. Contribute your thoughts, code, or issues at the Supergiant Github.