Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The appeal of serving your web pages with a single process

utcc.utoronto.ca

Post reply on HN
Print view View original

11–20 of 63 posts

Re: The appeal of serving your web pages with a single process

#11

Post by benoau »

kevmo314 wrote: post #3

Wholly agree. Too often we think about scale far too early. I've seen very simple services get bogged down in needing to be "scalable" so they're built so they can be spun up or torn down easily. Then a load balancer is needed. Then an orchestration layer is needed so let's add Kubernetes. Then a shared state cache is needed so let's deploy Redis. Then we need some sort of networking layer so let's add a VPC. That's…

Shed a tear for Heroku, they made all this go away such a long time ago but ultimately squandered their innovation and the ~decade lead they had on other thinking in this fashion.

Re: The appeal of serving your web pages with a single process

#13

Post by the__alchemist »

benoau wrote: post #11
kevmo314 wrote: post #3

Wholly agree. Too often we think about scale far too early. I've seen very simple services get bogged down in needing to be "scalable" so they're built so they can be spun up or torn down easily. Then a load balancer is needed. Then an orchestration layer is needed so let's add Kubernetes. Then a shared state cache is needed so let's deploy Redis. Then we need some sort of networking layer so let's add a VPC. That's…

Shed a tear for Heroku, they made all this go away such a long time ago but ultimately squandered their innovation and the ~decade lead they had on other thinking in this fashion.

Could you please clarify? I haven't noticed any impact to Heroku on my web applications; it.. just works, anecdotally. They send periodic mandatory upgrade emails re database and application stack, but they have been harmless so far; going back a decade.

Re: The appeal of serving your web pages with a single process

#14

Post by ajayvk »

kevmo314 wrote: post #3

Wholly agree. Too often we think about scale far too early. I've seen very simple services get bogged down in needing to be "scalable" so they're built so they can be spun up or torn down easily. Then a load balancer is needed. Then an orchestration layer is needed so let's add Kubernetes. Then a shared state cache is needed so let's deploy Redis. Then we need some sort of networking layer so let's add a VPC. That's…

Having a single process web/app server simplifies things operationally. I am building https://github.com/claceio/clace, which is an application server for teams to deploy internal tools. It runs as a single process, which implements the webserver (TLS certs management, request routing, OAuth etc) as well as an app server for deploying apps developed in any language (managing container lifecycle, app upgrades through GitOps etc).

Re: The appeal of serving your web pages with a single process

#15

Post by benoau »

the__alchemist wrote: post #13
benoau wrote: post #11

Earlier quoted context omitted.

Shed a tear for Heroku, they made all this go away such a long time ago but ultimately squandered their innovation and the ~decade lead they had on other thinking in this fashion.

Could you please clarify? I haven't noticed any impact to Heroku on my web applications; it.. just works , anecdotally. They send periodic mandatory upgrade emails re database and application stack, but they have been harmless so far; going back a decade.

They went from leading / pioneering horizontal scalability and database deploying and scaling and orchestration to "quiet-quitting" 15 years ago and doing almost nothing ever since - today they're barely worthy of mention in any discussion on any tech that solves these problems.

Re: The appeal of serving your web pages with a single process

#16

Post by bigfatkitten »

benoau wrote: post #11
kevmo314 wrote: post #3

Wholly agree. Too often we think about scale far too early. I've seen very simple services get bogged down in needing to be "scalable" so they're built so they can be spun up or torn down easily. Then a load balancer is needed. Then an orchestration layer is needed so let's add Kubernetes. Then a shared state cache is needed so let's deploy Redis. Then we need some sort of networking layer so let's add a VPC. That's…

Shed a tear for Heroku, they made all this go away such a long time ago but ultimately squandered their innovation and the ~decade lead they had on other thinking in this fashion.

Salesforce is what happened to Heroku.

Re: The appeal of serving your web pages with a single process

#17

Post by theideaofcoffee »

Then why not go to the extreme and just build a static version and serve that? Why do you need any dynamic content at all? Then you won't need shared state, then you won't need a database, then you won't need 90% of the stuff that dynamically driven pages need. Be the l33t h4x0r you are and just go static, save the complexity for your build process, because that shows the true hacker spirit. Hell, you may even be able to wring out another few blog posts from that.

Also, why are people submitting every single post from this blog recently? Does this person actually do any work at UToronto, or is he just paid to write? There are -8000- links to various pages under this domain. I hope it's just a collective pseudonym like Nicolas Bourbaki and one person didn't write 8000 pages.

I'm desperate to use some of the insights from a navel-gazing university computing center in my infrastructure: IPv6 NAT (huh? what? What?!), custom config management driven by pathological NIH (I know precisely zilch about anything at utcc but I can already say with 100% confidence that your environment isn't special enough to do that), 'run more fibers', 'keep a list of important infrastructure contacts in case of outages', 'i just can't switch away from rc shell', and that's just in the last six months. On second thought, I'll just avoid all links to here in the future to save my sanity.

Re: The appeal of serving your web pages with a single process

#18

Post by the__alchemist »

benoau wrote: post #15
the__alchemist wrote: post #13

Earlier quoted context omitted.

Could you please clarify? I haven't noticed any impact to Heroku on my web applications; it.. just works , anecdotally. They send periodic mandatory upgrade emails re database and application stack, but they have been harmless so far; going back a decade.

They went from leading / pioneering horizontal scalability and database deploying and scaling and orchestration to "quiet-quitting" 15 years ago and doing almost nothing ever since - today they're barely worthy of mention in any discussion on any tech that solves these problems.

We define worth. I mention Heroku as a great way to make web applications at various scales. Reliable, and easy to use.

Re: The appeal of serving your web pages with a single process

#19

Post by Aurornis »

AlotOfReading wrote: post #7
kevmo314 wrote: post #3

Wholly agree. Too often we think about scale far too early. I've seen very simple services get bogged down in needing to be "scalable" so they're built so they can be spun up or torn down easily. Then a load balancer is needed. Then an orchestration layer is needed so let's add Kubernetes. Then a shared state cache is needed so let's deploy Redis. Then we need some sort of networking layer so let's add a VPC. That's…

In a former job, I wrote a static PWA to do initial provisioning for robots. A tech would load the page, generate a QR code, and put it in front of the camera to program the robot. When I looked into having this static page hosted on internal infra, it would have also needed minimum two dedicated oncalls, terraform, LB, containerization, security reviews, SLAs, etc. I gave up after the second planning meeting and put…

> When I looked into having this static page hosted on internal infra, it would have also needed minimum two dedicated oncalls, terraform, LB, containerization, security reviews, SLAs, etc.

In my experience there are two kinds of infrastructure or platform teams:

1) The friendly team trying to help everyone get things done with reasonable tradeoffs appropriate for the situation

2) The team who thinks their job is to make it as hard as possible for anyone to launch anything unless it satisfies their 50-item checklist of requirements and survives months of planning meetings where they try to flex their knowledge on your team by picking the project apart.

In my career it’s been either one or the other. I know it’s a spectrum and there must be a lot of room in the middle, yet it’s always been one extreme or the other for me.

Post reply on HN