We Are Saving Costs by Dumping AWS Cloud
Amazon is using the same trick with AWS pricing as cellphone providers: they rely on bad math capabilities of their clients. The costs for one single item, in the case of AWS this is one hour of computing, is incredibly low, parts of a cent - but most people out there are not able to do simple maths like multiplication (by 720, the number of hours in a month) or summation (with the costs of the other services you have to implicitly use).
When hosting a simple one-node Kubernetes cluster the costs are easily at a three-figure number per month - the fees for EKS, the fee for the EC2 node, the fee for the inbound load balancer, the fee for storage, ... compared to a root server for $10 that easily outperforms a $60 EC2 instance that's really overpriced.
24 comments
[ 2.7 ms ] story [ 63.3 ms ] threadAnother example of this scam is Firebase (aka Google Cloud). Popular with mobile devs who not only risk getting locked in, but are offered limited functionality (Firestore) that charges for reads which that optimises for a huge bill if one is not careful.
For servers, as soon as you add Kubernetes, just remember to not show the 'operating costs' section of the balance sheet to the investors, unless you have a healthy recurring revenue stream.
> they rely on bad math capabilities of their clients
No, they don't. Showing hourly prices makes sense for hourly services.
They also provide a detailed cost estimator, because the arithmetic gets pretty detailed: https://calculator.aws
> compared to a root server for $10 that easily outperforms a $60 EC2 instance that's really overpriced.
Let's say a developer costs $75/hr. If AWS saves my dev team 10 hrs/mo., then I'm willing to pay a $750 premium for it.
Developer costs are also unpredictable. Turnover will cause spikes in my costs, for example.
Server costs are predictable. If I need to pay AWS more to save my developers time, I can always do that. I can't always just throw another developer onto my team when I need one.
The only people who are optimizing for three-figure costs every month are either: 1) paying very, very low salaries to their developers, or 2) not thinking about their biggest cost, which is developer time.
> When hosting a simple one-node Kubernetes cluster
Who would do this and why? Why would you have a load balancer in front of a single server?
In our case, we are doing the same for around 50 clients, so it sums up :-)
> Who would do this and why? Why would you have a load balancer in front of a single server?
afaik, for publishing something to the outside world from EKS, that's the only way - even for single node clusters
Wow, so AWS is actually a better value for you than for most people. Being able to easily script and deploy your infra is hugely valuable when you have so much overhead.
We heavily use Elastic Beanstalk for dozens of running services, and it's amazing. We don't think about infra at all.
> for publishing something to the outside world from EKS
But why are you using Kubernetes at all? What problem is it solving for you?
See also: https://endler.dev/2019/maybe-you-dont-need-kubernetes/
We have to support multiple clouds (Azure and AWS), but with Rancher, it is really easy in usage - setting up new clusters, deploying new services, restarting, logging etc. But now that we built up container technology know-how we are transitioning every service where we don't need the scaling capabilities of Kubernetes to plain old docker-compose on baremetal.
Thanks for the interesting article, didn't know about Nomad and will try it for sure.
If the above does not apply, of course you're going to be better off using a combination of Cloudflare (CDN, networking), Backblaze (object store, also has S3 compatibility layer), and either dedicated service providers (OVH) or VPS providers (Digital Ocean). Perhaps even colocation if you've got the experience in house (Stackoverflow and Wikipedia, for example).
AWS and other cloud providers are designed for the price insensitive, who prefer having a single vendor, more abstraction away from the metal, or require support for bursty workloads. Shop around and model your run rate based on expected workloads. There is no best or worst solution, only a scale of solutions for your use case(s), ranging from suboptimal to optimal.
Thankfully, I've never had a popular enough service that made the bandwidth a meaningful cost.
Reliably decouple whenever possible.
[1] https://www.cloudflare.com/bandwidth-alliance/ (Control-F "partners")
[1] https://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrl...
I agree that the velocity/cost tradeoff is one of the better reasons to go cloud, it's far from the only one, and it's certainly not the case that cloud is only for the price insensitive. If nothing else, the proliferation of cloud cost management tools shows plenty of companies care about their cloud spend.
* I work on an aws cost management tool and am doing a lot of customer research interviews this month.
Please consider publishing your research findings in the future if it doesn't put you at a competitive disadvantage. A rising tide lifts all boats, and cloud spend tracking and modeling is a pain in the ass (as your success demonstrates).
Frankly, I don't understand this point. For €40 a month with Hetzner you'll get an i7 with 64GB RAM and 2x512 SSD that will easily handle any traffic spike (we're talking about a website, right?). €40 is not a lot of money, even for a non profit, and especially for one experiencing a huge spike after being mentioned in the news.
On the contrary, I would advise against AWS here as they're completely unpredictable. You can be charged any amount, and the costs only partly depend on you. Developers have been demanding hard caps for over a decade to no avail.
If you are a dev that's paid to churn out features, and your compensation isn't stock based, just use whatever allows you the greater flexibility and velocity.