[thepasswordis]

Blog posts like this always strike me as…weird.

This seems like “how to build a web app for a very tiny subset of people who don’t want to learn about deploying web apps”.

Maybe I’m in a bubble? It seems like 99% of the people I know actually running profitable companies have an infrastructure that roughly matches to “some Linux server somewhere”, and then upward from there it all just moves to AWS/azure, but it’s still just some Linux machines maybe with a load balancer in front of them.

If you’re writing software and don’t seem covered by this blog post, don’t feel like you’re out of the loop on something. I think this author is just writing about the subset of the ways that he knows about.

I mean honestly “HUGO static sites”…how about a directory of html files hosted by nginx or Apache?

[hathawsh]

I read it differently. It looks like a good outline of 4 basic approaches to building and hosting web sites. I would word them as:

1. Stateless static site. There is a variety of ways to build it (such as React or Svelte or purely by hand) and a variety of ways to host it (such as a directory of HTML files hosted by nginx).

2. Function services like Cloudflare workers, AWS Lambda, Google Cloud Functions, Azure Functions, etc. This is a way to store state without having to manage servers.

3. Single conventional Linux server.

4. Distributed containers.

All web developers should familiarize themselves with these 4 basic approaches and prefer them in approximately the order given. It's good to avoid jumping to distributed containers if you can get away with functions, a single Linux server, or even static HTML. It's also important to move down the list as the app grows rather than reinvent K8s.

[crabmusket]

I can't have my database on a separate Linux box? Seems odd to insist on either precisely one server or go straight to container orchestration.

That said, I agree with you about the other generalisations!

EDIT: actually, where do PaaSes fit into this taxomony? I'd argue that level 2 is actually the PaaS level. You might choose an edge PaaS (Workers), distributed (Fly.io), or centralised (Elastic Beanstalk) depending on your needs. But ultimately this level is: "I write code, you run it". FaaSes are a subset of PaaS providers which focus on stateless models, but there's no reason you can't combine FaaS for your code with a managed database offering.

[NikolaNovak]

I assumed that option 3 was a "Fermi estimation", I. E. "single handed number of servers"

I'm used to 3 tier legacy apps (web / app / dB) but I assumed that would fit into number 3 the best, I could be wrong...

[crabmusket]

Maybe it's "on the order of a single server", or conveys that the servers are "statically" arranged and/or manually managed rather than automatically (auto scaling, service discovery)?

[hathawsh]

Yeah, that's a better way to put it. #3 is a static arrangement of a small number of servers.

[tbeseda]

This is a much better outline of the article than the article's own table of contents. Makes much more sense, even if it's still incredibly narrow in scope.

[tony-allan]

It's not obvious but you can host an entire website or simple web app on AWS Lambda (as simple as a single function).

[hendry]

I host a full Web app on Lambda like so https://github.com/kaihendry/ltabus

[holler]

Nice, I host a public chat app off lambda https://sqwok.im

[indymike]

This is much better than the article.

[dgb23]

> I mean honestly “HUGO static sites”…how about a directory of html files hosted by nginx or Apache?

Whether you put HTML files on the mentioned services or have a build step with a static site generator is not the point.

Where does your nginx server run, how do you keep it up and running, how you do provision it, how do your files end up on the server?

You can write a bunch of shell scripts and do all of this on a cheap VM for 5 bucks. Or you can get it for free on some of these services with git integration, global caching, web hooks, previews, cheap storage, image optimization etc. You get unlimited or at least a lot of sites and it's all automatic. On some you can even just drag and drop a directory into their web interface and the website is there in a couple of seconds.

It's basically a different layer of abstraction that's free/cheap and works nicely for simple use cases or as a specialized part of a more complex deployment architecture.

I have personally recommended netlify, cloudflare etc. to people who have the technical ability to write HTML/CSS or use a static site generator. Those things are very easy to use and carry around less risk than having to provision and configure a web server yourself.

[satvikpendem]

Free, for now. Once the higher interest rate environment becomes more normalized, I would not be surprised to see many services become paid.

[nine_k]

They may cut the extent of a free offering, but I suppose they won't drop it. An ability to make a quick proof of concept, to just try something and play with it, is very important for bringing in paying customers. People tend to buy with more confidence things they already know and comfortable with. People tend to pay for things that are widely known, with tons of examples and explanations online; free services generate much more of these.

[satvikpendem]

That might be true but it really depends how many can convert. Recently Heroku dropped their free tier as well as Fly.io having a credit card only free trial in order to deter scammers.

[crabmusket]

I don't disagree with you, but I do think the economics of static sites are pretty different which may keep the free tiers around for longer. Even if it's "free for sites under 1MB", which would cover a lot of sites.

[flippinburgers]

I agree with you here. I find that certain kinds of "hosted" services have their own home grown techno-babble and they rely on the ignorance of their potential customers to lure someone in. They sound like they are hiding some insanity level complexity made easy for consumption... but really all one needs is to run a single linux instance + nginx + some files.

Scale up from there as required.