Hacker News Reader

Comment by jason0597 | Hacker News Reader

I often wonder why so many companies seem to spend tens of thousands of dollars per month on AWS services for their hosting. If most web apps nowadays are just CRUD apps, then why would you need to spend more than €300/month on hosting? All you'd need is data and the website itself, right?

I'm currently clicking through various European hosting services and they seem to offer great dedicated servers at good prices. I cannot wrap my head around these ridiculous costs I keep hearing about. A guy I know was telling me how they were spending tens of thousands of dollars per month on AWS at his company.

Is it because everyone is writing their stuff on node.js, putting 500kb of JS in every web page they serve, putting Docker everywhere when a chroot would suffice, microservices, Kubernetes, or hell even writing SAPs when we don't need them?

I am genuinely confused

View on HN

> If most web apps nowadays are just CRUD apps, then why would you need to spend more than €300/month on hosting? All you'd need is data and the website itself, right?

If you're building a basic CRUD app and you have low traffic numbers, you don't need to spend tens of thousands of dollars on AWS.

But it's not as simple as picking a dedicated server, setting it up, and hoping for the best. At minimum you need periodic backups, testing and staging environments, solutions for rate-limiting your API, and so on.

And the "everything is just a CRUD app" meme is just that: a meme. Usually engineers who repeat this have only ever worked on simple CRUD apps, so they don't understand what it's like to work on anything different.

> I'm currently clicking through various European hosting services and they seem to offer great dedicated servers at good prices. I cannot wrap my head around these ridiculous costs I keep hearing about.

If you're working on the types of problems that are a good fit for setting up a single dedicated server on a random hosting provider, you're not working on the same types of problems that necessitate $10K AWS bills.

> I am genuinely confused

I've worked on projects with $10K+ monthly AWS bills. It wasn't node.js or Docker or Kubernetes. It was the sheer volume of connections we had to maintain and data we had to process.

But even if we could reduce our $10K/month AWS bill to $1000/month with a lot of engineering effort and manual management of our own servers, what would we gain? If I had to hire a single additional devops person or engineer to help manage this custom solution, the entire savings would be wiped out. And then some!

Wasting AWS resources isn't smart, but trying to DIY your solution to everything rarely makes financial sense when you look at how much engineering effort it takes and how much engineers cost. If I can spend $10K/month to avoid hiring 1 additional engineer, it's a financial win. I do not care if someone thinks they can do the same thing in $1K/month with endless amounts of custom setup and maintenance. I don't want it.

It also reduces the number of moving pieces that we have to manage manually, which reduces the on-call burden, which keeps people happier.

I really don't understand the anti-cloud hate on HN. It doesn't mirror the real engineering world at all.

> Is it because everyone is writing their stuff on node.js, putting 500kb of JS in every web page they serve, putting Docker everywhere when a chroot would suffice, microservices, Kubernetes, or hell even writing SAPs when we don't need them?

My response may come off as rude, but that's not the intention. From the above quote you've vastly over simplified all but the most simplistic environments. Someone could run all of the above for well under 10k month - those are not the reasons why costs are high

> putting 500kb of JS in every web page they serve

that's not much and CDNs serve that without issue or significant cost

> putting Docker everywhere when a chroot would suffice

Docker does not have much overhead over chroot with a large drop in security/isolation

> microservices

there are good and bad ways to do this - does not need to cost much. saying "microservices" is so broad to have no meaning in this context

> Kubernetes

think about why someone might run kube. Again, not that expensive unless you're really small where having master nodes would have a big impact on costs

> or hell even writing SAPs when we don't need them?

Do you mean SAP? SAP is the largest non-American software company by revenue. I don't think anyone likes working with SAP. You think people use it for without reason? There are reasons. Think about what those might be

But those are just details - when building anything of a decent size, nothing is a simple CRUD. There are always exceptions, limitation, biz logic, migration issues, schema issues. I don't care if you use Postgres, Mongo, Kafka or $SOMETHING_COOL

Then there's data retention. It's very very easy to keep PB of data in s3 or other data stores for biz or compliance needs

Then AWS gives IAM, which is very helpful in teams > 5

> Docker does not have much overhead over chroot with a large drop in security/isolation

Docker adds plenty of attack surface that could easily be avoided by using any sandbox or a systemd unit file.

I'm guessing they meant to write SPAs.

Yes that is correct, it was a typo :(

> Is it because everyone is writing their stuff on node.js, putting 500kb of JS in every web page they serve, putting Docker everywhere when a chroot would suffice

Complexity inflates HN readers CVs and keeps them employed.

>If most web apps nowadays are just CRUD apps, then why would you need to spend more than €300/month on hosting? All you'd need is data and the website itself, right?

Because most web apps aren't simply CRUD apps. It's a meme said by armchair engineers who believe they could build twitter in weekend.

Here you confuse 'most apps' with Twitter and Facebook. Most apps are crud apps; there are some apps that are not. Those apps are the most used, but they are not most apps by app count.

Only people here on hn seem to think that everyone is slinging k8s and 1000 layers of microservices to build the most complex things on earth; the rest is earning their paycheck by building some forms in php.

Sadly many here are overengineering crud apps and then somehow making them out to be something more than crud apps because somewhere in the future they might be (probably not); as in, you can build 'a twitter' in 1 weekend and it will even probably handle good volume of users ( more than Twitter did at startup; it was often down or very slow) etc if you just take postgres with php on a few $/mo server. It is a crud app at that time (the flow for these user authored posts is built into every trivial and complex framework these days). Also it will most likely be bankrupt in a few months as that is what happens to startups; I rather spend money on building the business first and then scaling the tech; which is exactly what Twitter did. On hn it seems a lot of people work backward in that regard but that probably has also something to do with being a techie and VC interest in scalable tech.

I don't think that most workloads are webapps and many webapps are not just CRUD. HN is not the web either, in case HN formed such a viewpoint for you.

Until you're spending the salary of a large fraction of your engineers on hosting costs, there are much bigger things to worry about than hosting costs. AWS is user friendly and a lot of engineers are familiar with it, so developer productivity is strongly in its favor.

Also, you know what you're getting security-wise with AWS, and no one will blame you when your website / service goes down because AWS is down.

Wasn't that like IBM's business motto at some point? No one ever got fired for going with IBM. Then IBM definitely lost a lot of business to cloud modernization. Maybe the next logical step is the cheaper CloudFlare, which another comment mentioned is actually pretty profitable and then I'm sure the next cheaper incumbent will come in with just slightly less trust and reliability.

Reply on news.ycombinator.com