Live data from Hacker News

We Are Saving Costs by Dumping AWS Cloud

news.ycombinator.com

21–25 of 25 posts

Re: We Are Saving Costs by Dumping AWS Cloud

#21

Yeah but you can spin up everything you need in a day. Then you can shut it all down. If you’re a startup, it can make a ton of sense.

sure, that's a good point. and scaling a one-node-cluster to a multi-node-cluster is also nearly no effort on AWS. but for the topics where we can predict the computing power for the next months, we migrated everything to baremetal.

Re: We Are Saving Costs by Dumping AWS Cloud

#22

If you've got funding (or immediate profitability due to traction) and a hockey stick growth rate, the cloud makes sense. It's just the cost of business to support rapidly scaling and developer velocity to try to capture as much of the market as fast as possible. As long as your profit stays ahead of your cloud costs, mission accomplished. If the above does not apply, of course you're going to be better off using a c…

This advice holds if you have a stock based compensation or a bonus based on profitability. Here wasting money on cloud directly impacts the profitability (and by extension, the worth of your stock).

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.

Re: We Are Saving Costs by Dumping AWS Cloud

#23
post #19
post #5

Not a big AWS fan or anything, but... > 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…

> The only people who are optimizing for three-figure costs every month are either: 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

> In our case, we are doing the same for around 50 clients, so it sums up :-)

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/

Re: We Are Saving Costs by Dumping AWS Cloud

#24
post #23
post #19

Earlier quoted context omitted.

> The only people who are optimizing for three-figure costs every month are either: 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

> In our case, we are doing the same for around 50 clients, so it sums up :-) 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 E…

We built a software (Botium Box - https://botium.ai) mainly for On-Premise use, and we delivered as Kubernetes, Openshift, Docker. We added a hosted plan later and thought it would be a good idea to just use managed Kubernetes for this offer as it didn't require much coding changes.

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.

Re: We Are Saving Costs by Dumping AWS Cloud

#25

If you've got funding (or immediate profitability due to traction) and a hockey stick growth rate, the cloud makes sense. It's just the cost of business to support rapidly scaling and developer velocity to try to capture as much of the market as fast as possible. As long as your profit stays ahead of your cloud costs, mission accomplished. If the above does not apply, of course you're going to be better off using a c…

I've talked* to a number of bootstrapped and non-profit companies who are all-in on cloud and I think there are a few use-cases you're missing beyond just "we value dev velocity over cost savings." The biggest one is ease of scaling vs something like colocation. I talked to a non-profit with incredibly spiky traffic based around whenever they get mentioned in the news. Since every dollar matters for them, being able…

> I talked to a non-profit with incredibly spiky traffic based around whenever they get mentioned in the news. Since every dollar matters for them, being able to scale down to a minimal infrastructure between spikes is key to their survival.

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.

Post reply on HN