Comment by mattmanser | Hacker News Reader

Comment by mattmanser | Hacker News Reader

Parent Full thread

I've used various hosts over the last 15 years in the UK and I honestly can't remember any downtime from anyone else. I do remember lots of AWS + Azure downtime though. Remember Netflix going down?

I'm not really sure where you're coming from.

As someone who's been doing this for years, the old days when you had a £10 virtual machine that could handle tens of concurrent requests don't seem to be handled by the low price AWS/Azure servers. Let's not forget, tens of concurrent requests is 100,000s of monthly users, a major win for most startups.

And even the expensive cloud options are utterly rubbish compared to what you can get for a bare metal, I like to compare the two as you can get a Ferrari for £1000 a year, or you can get a bicycle for £1000 but don't worry, it's a "cloud" bicycle so definitely go with that.

I am constantly having problems with an Azure app at the moment timing out because of some poorly optimized queries that are being throttled because they somehow exceed the ever mysterious DTU. On my laptop, a 5 year old laptop, the queries take 10ms. So it's is impossible to run on Azure because "reasons" unless I pay a ridiculous amount of money to upgrade the SQL server. Yes, I could fix the query, but why should I be spending time on that? They're part of the admin system and are simple reports.

Another app I worked on we ended up having to pay £1000 a year just so we could have multiple-domains + SSL, when we expecting to pay £80 p/y.

Personally, every time I use cloud servers I regret it. I keep trying or clients really want it, and can understand the lower devops cost and that with bare metal, every 5-10 years I need to migrate the app to get a better server, but I honestly find the cloud servers so completely underpowered for the cost. I don't understand how they've got so popular. Basic devops for most startups is a day or two task once every few years. Write a deploy script, backup script once, and almost forget about it.

(I absolutely love s3 though for backups though)

I have recently started a project of deploying kubernetes cluster at home and hosting some personal projects there. My top findings are:

1) bare metal is dramatically faster than most cloud instances. Many of us might have collection of old hardware that, by performance, would be equivalent to >$1,000 in monthly cloud fees.

2) If from the start of your career you have only dealt with modern cloud/Azure/AWS, there is a whole body of knowledge you are missing. Acquiring it from scratch is time consuming, and you are never quite sure you are doing the right thing. As a developer, I don't pay the AWS bill, so it would be more rational to spend my time on learning ML or something else that will be reflected in my paycheck.

So how do you do routing? I have an old Linux machine that I haven’t been using and don’t know how I can securely and efficient route that into the internet (don’t want to use my ip for connecting to Redis for example) which is why I as thinking of using some vpn hosted on gcp.

Any advice would be greatly appreciated. Can’t handle the monthly payments to gcp only to get a raspberry pi level of compute.

I host a Plex instance on a server on my home network, and struggled with setting up external access because my ISP at the time had a double NAT. What I ended up doing was renting a super cheap VPS from TINYKVM (https://tinykvm.com/) which I pay $15 a year for.

I point my DNS at the VPS, then I use the Zerotier VPN to tunnel traffic to my home server (Zerotier is embarrassingly easy to set up - I struggled for a while with OpenVPN but gave up). I use iptables packet forwarding to route traffic on port 443 or 80 from the VPS over the VPN to my local server, which is running an Nginx instance to serve the traffic.

This works perfectly for me 99% of the time. Main pain points have been the unreliability of hosting a server locally where Internet can die and power drop off, and a small amount of sysadmining on the VPS, which is so tiny that I have to be mindful of disk space (e.g. removing old Linux upgrade images every so often, etc). All told though, it works surprisingly seamlessly, and there's a certain smugness to knowing traffic from my smart TV goes all the way round the world and back through a VPN just to talk to my server sitting one foot below the TV.

Interesting setup. Have you heard of Cloudflare Argo by chance? Was thinking of using that, although this seems like a perfectly fine setup itself.

I am not entirely clear on your question, but I am avoiding reliance on any third-party service to keep it a clean experiment.

I have it easy for external access -> static IP and a Gigabit connection without NAT, so all I have to do is setup ports on my router.

For my services like databases and Redit, I expose them only on Cluster-IP, and them you use kubeDNS and get something like 'redis.default.svc.cluster.local'.

If I need to access them for development purposes, I use kubectl-proxy, but a VPN is also an option.

If your DNS service has an API, you can just have your home server update it’s own record when it detects a change. It may be down for a little while while DNS propagates though.

Edit: I think I misunderstood, but will leave this up anyway.

> started a project of deploying kubernetes cluster at home and hosting

I am also thinking along these lines but not sure about reasonable paths to try. Care to share some pointers on your setup? Basically looking to serve web pages from a server cluster at home.

If you can run your app on a £10 VPS then you are not the target market for the big clouds. That's why it doesn't make sense for you. Larger users have very different priorities.

This really isn't true. People use them for everything. Tiny little enterprise apps with 10s of users. Startups with mere 1,000s of uniques per month. Side projects. Everything.

If you look at Microsoft's strategy with C#/Azure you'll see that every single tutorial uses deploying on Azure. Their instructions for how to deploy to a real server in their tutorial is pretty much "we're not telling you, figure it out yourself, sucker".

Their new business strategy is to get the entire of their userbase paying massively over the odds for hosting small apps.

And, in reality, almost every app by any startup you could go and look at on producthunt (and probably most of ycombinator startups) have such low volumes of usage they could run on a $5 VPS. But I bet all of them are on AWS (there's even a few comments on this thread that basically say "start on AWS, then move").

Everyone is using cloud now, go to any meetup and ask. Or simply look at the sales figures.

The thing is, maybe you're overpaying spending $100/month instead of $10/month, but those are both small numbers. Simply not having to standup a DB/server/getting certs/debug if something goes wrong somewhere/etc is worth more in my time than a few $100. If you're very small scale you can also use the "always free" tier of VMs.

I really like that for my side projects/solo hacks I don't have to think about anything other "here is my code that does the thing that I think is cool" and all the deployment/serving/data layer/ml model inference/etc just kind of happens.

For small/very early startups it's also similar. At least in the US, it's not the extra $5k/year you spend on cloud hosting vs doing it yourself that kills you; for many engineers that less than a week of comp.

At the same time, when you are large and spending $100s of k on your hosting then sure, look into alternatives and migrate if needed. This is where "start on AWS, then move" comes from.

I guess the point I was trying to make is that all that "extra" stuff isn't really much extra work at all and the same magic deploy tools could be just as easy on a VPS/bare-metal, but aren't because of $$profit$$ making it better that they don't make it super-easy to deploy on VPS/bare-metal.

I can make a script to do it all for me (and have in the past), but it's a bit of work.

That's really why the title of the article is apt being "the Amazon Premium", and not "the Amazon Rip-off".

Honestly if you are deploying an application to production, hopefully you have a level of knowledge beyond "click here, then click here'.

The other side of this is that documentation is hard, and Microsoft documentation is frequently lacking or out of date, especially for anything off the beaten path. I use IoT Hub for messaging, and it's documentation is scant, many limitations and failure modes are found by trial and error.

I don't understand where you would get this info from then? Tutorials provided by the framework makers themselves are pretty standard.

Magically absorb the knowledge in an incantation to the Redmond Gods in the ether?

haha, sometimes it feels that way, for their less-popular commercial services documentation is lacking and you can't even read the source!

On reflection my comment about level of skill is unfair, what I should have said is: generally the information is there, but it's not always in the form of follow-able 'How-to' guides, often it's a dry detailed documentation. If you need something other than the standard setup, it is up to you to know what you are looking for and put 2 and 2 together. Of course it is by no means easy.

They do have reasonable guidance on how to deploy ASP.net core on Linux, but it can be lacking for lesser used stuff

If you’re that small, you can probably stay under the always free lambda tier.

Honestly, why chime in with that? Not only is it sort of sneering (if you're that small), it's wrong and counter to the most practical advice we give out here, use what you know. It's hard enough starting a business without learning a whole new tech stack.

Ironically, we were having the discussion here yesterday about a guy with a failed startup saying he'd wasted the opportunity because he used too much new stuff and spent all his time on that instead of iterating the actual product. Several comments focused on it'd just be better to start off with a Rails app, it's quick, it's easy and it's understood.

And really, is lambda appropriate for anything more than a very focused niche app? I mean, try writing all the usual things you need to slot into a SaaS on it, billing, user management, signup, admin reports, admin functionality, emails, multi-tenancy, custom domains, etc. etc. Even a 20 user, internal, enterprise app needs most of that functionality. Put on top of that, you're forced to use a particular, proprietary tech stack and lock yourself into something that might very well die in a couple of years.

Not only is it sort of sneering (if you're that small)

Lambdas always free tier is 1 million requests per month and 400Gb/seconds per month.

https://aws.amazon.com/lambda/pricing/

It takes a lot to have any meaningful lambda bill. That in no way is meant to be an insult. If you’re spending even $100/month on lambda, you’re running a successful website.

It's hard enough starting a business without learning a whole new tech stack.

If you know how to write a program and create a function that takes two parameters - a payload and context argument - you know lambda. You can write it in the console if you’re using Python or Node and just run it from there.

Even if you don’t want to learn that, you can host your standard C#/WebAPI, Python/Django/Flask, Node/Express API on lambda just by adding code and changing your endpoint.

Several comments focused on it'd just be better to start off with a Rails app, it's quick, it's easy and it's understood.

There is also code to wrap a Rails app and run it on lambda....

And really, is lambda appropriate for anything more than a very focused niche app? I mean, try writing all the usual things you need to slot into a SaaS on it, billing, user management, signup, admin reports, admin functionality, emails, multi-tenancy, custom domains, etc. etc. Even a 20 user, internal, enterprise app needs most of that functionality

Yes. Especially in today’s world of client side frameworks and microservices, you host your static assets like Javascript, css, and HTML in S3 and call server side APIs hosted on lambda.

Put on top of that, you're forced to use a particular, proprietary tech stack and lock yourself into something that might very well die in a couple of years.

Well, two things. What’s more likely to die in two years / your startup or AWS?

Second, you can host your standard API just by adding four lines of code and you don’t have to make any changes to host it in Docker or on a VM.

There is a way to do this in every language that lambda natively supports. For instance for Node:

https://github.com/awslabs/aws-serverless-express

I have a Node/Express app that gets deployed to both lambda and Fargate (Serverless Docker) when I push it. The only difference is that lambda uses one entry point and Docker uses another.

I’ve done something similar with C#

https://aws.amazon.com/blogs/developer/deploy-an-existing-as...

Where it is deployed to both lambda and a Windows server running IIS.

I can be a lot more productive with all the resources that AWS has to offer when all I have to do is provision resources with a CloudFormation template and instead of doing the grunt work of infrastructure administration I can concentrate on writing software.

Reply on news.ycombinator.com