Live data from Hacker News

Why aren't we all serverless yet?

varoa.net

131–137 of 137 posts

Re: Why aren't we all serverless yet?

#131
post #129

Earlier quoted context omitted.

This doesn't make sense to me because "fooless" means "lacks foo" You are describing a thing that is not a foo, or does not do foo, not a thing that posesses no foo. So, I say, this is just something you're saying and not a definition I ever heard or would have implied from context from others usage. And it's not a new term by now, so there has been several years for me to have gained this impression or understanding…

> "fooless" means "lacks foo" Exactly. "Serverless" lacks a server. Which, granted, wouldn't make sense with no context, but when you remember that the same types of applications were previously written to include a server and no longer include a server when written in a "serverless" fashion, that is exactly where the differentiation is found. It literally describes what it is. > And it's not a new term by now, so th…

To try and put my first comment more clearly: They both refer to distance removed from hardware. Neither refers purely to software things like webservers or application servers, which is how you and others described them in what I was first responding to.

"Server" does not solely refer to software, it is also a name used for hardware. Think along the lines of mainframe, host, hypervisor, and so on.

Re: Why aren't we all serverless yet?

#132
post #84

Earlier quoted context omitted.

> Serverless is all about outsourcing the infrastructure for scaling a micro service. Technically, it is all about removing the server from your application. The name literally tells you so. It is true that removing the server can offer some benefits in the scaling realm. In particular, it allows you to scale to 0 now that you no longer have to keep the process alive to serve requests. Of course, that is not tradeoff…

> Technically, it is all about removing the server from your application. Technically its about removing the server from my list of responsibilities. There is still a server running my app, it just isn't managed by me and likely comes with auto-scaling features.

> Technically its about removing the server from my list of responsibilities.

Not necessarily. Back in the serverless CGI days you would still typically manage Apache. What you say is probably why would you choose serverless in 2025, but not always. This is not the technical differentiation.

> There is still a server running my app

There may be a separate server (e.g. Apache) that runs your app, but that is someone else's app, not your app. Calling someone else's app your own would be rather silly. Your application is less a server, which is a change from how these applications had normally been written over the past couple of decades. At least since the death of CGI, you would traditionally see your application become the server (possibly proxied through another server, but that is ultimately immaterial to the discussion). That is what goes away with serverless.

Re: Why aren't we all serverless yet?

#133
post #131
post #129

Earlier quoted context omitted.

> "fooless" means "lacks foo" Exactly. "Serverless" lacks a server. Which, granted, wouldn't make sense with no context, but when you remember that the same types of applications were previously written to include a server and no longer include a server when written in a "serverless" fashion, that is exactly where the differentiation is found. It literally describes what it is. > And it's not a new term by now, so th…

To try and put my first comment more clearly: They both refer to distance removed from hardware. Neither refers purely to software things like webservers or application servers, which is how you and others described them in what I was first responding to. "Server" does not solely refer to software, it is also a name used for hardware. Think along the lines of mainframe, host, hypervisor, and so on.

> does not solely refer to software, it is also a name used for hardware.

A computer that primarily runs a server (or multiple servers) is often colloquially also called a server in recognition of what it is doing, but server is still in reference to the software. If you repurposed that hardware to sit on someone's desk to run Excel, most wouldn't call it a server anymore.

> Think along the lines of mainframe

I am not sure that works. I expect a mainframe running Excel on someone's desk would still be considered a mainframe by most as mainframe usually refers to a hardware architecture. A server, in the colloquial hardware sense, could be of any kind of architecture, including a mainframe!

Regardless, serverless is not associated with hardware as it is usually used. It is, as virtually everyone uses it, about removing/not needing the server in your application, typically used in the context of a service like AWS Lamba which offers the aforementioned runtime environment that negates the need for your application to be a server. In fact, Lambda is specifically named in what looks like a majority of the sibling threads here. It is abundantly clear where the typical use lies. If you know of instances of people using it to refer to another concept, I would love to see it.

Re: Why aren't we all serverless yet?

#134
post #77

Earlier quoted context omitted.

Lambda does as well. You can even use their runtime interface client to run your function within the same wrapped that Lambda uses irl

Can I upload my web server as a docker to Lambda and have it run forever there? I though Lambdas were supposed to be more short lived (like a couple hours), is that not the case? It's been a while since I actually looked at Lambda because GCP run is so clean.

If you're married to running your own Web server, you could use schedules to run your Lambda every 15 mins....but you might as well use Fargate at that point (easier and probably cheaper).

If you're not married to running your own Web server, you can use API gateway with your Lambda functions, which is the traditional approach. Your frontend and it's assets can be served from an S3 bucket with Lambdas powering your backend. Cold start times will be a concern with this approach, but there are "warm-up" strategies you can employ to prevent that.

Re: Why aren't we all serverless yet?

#135

For me, it's because Rails has continued to be an excellent solution in every application I've ever needed to build, whether it's a project with 1 user or 10 million, or with a dev team of 1 or 100. Every time I try to solve a problem with anything other than Rails, I run into endless issues and headaches that would have been already solved if I just. used. Rails.

It sounds like you have mastered Rails and know how to solve all of its "issues and headaches".

Re: Why aren't we all serverless yet?

#136
post #126

> Microservices made a canonical example of how easy it is to miscalibrate that bet. Since the trend started ~15y ago,.... What started was the rebranding from distributed systems. We have had Sun RPC (The network is the computer, a slogan now owned by Cloudflare), DCE, CORBA, DCOM, RMI, Jini, .NET Remoting, SOAP, XML-RPC, JSON-RPC,.... Client-Server, N-Tier Architecture, SOA, WebServices,... Apparently the new trend…

> What started was the rebranding from distributed systems.

Not really. Microservices normally refers to humans and how they work together, or, perhaps, don't work together. Microservices is the same service model found in the macro economy but applied to the micro economy of a single business, which was a novel idea at least to the general public, hence the name.

Due to Conway's law, the product ends up being a distributed system more often than not, but that is only a side effect. Theoretically you could have microservices without distributed systems, and we do see some instances of services found in the macro economy that are not offered as a distributed computing products, not to mention that services even predate the network. But distributed is definitely the way most things are going.

Re: Why aren't we all serverless yet?

#137
post #133
post #131

Earlier quoted context omitted.

To try and put my first comment more clearly: They both refer to distance removed from hardware. Neither refers purely to software things like webservers or application servers, which is how you and others described them in what I was first responding to. "Server" does not solely refer to software, it is also a name used for hardware. Think along the lines of mainframe, host, hypervisor, and so on.

> does not solely refer to software, it is also a name used for hardware. A computer that primarily runs a server (or multiple servers) is often colloquially also called a server in recognition of what it is doing, but server is still in reference to the software. If you repurposed that hardware to sit on someone's desk to run Excel, most wouldn't call it a server anymore. > Think along the lines of mainframe I am no…

I at least am not talking about hardware vs software uses of the word.

I don't think anyone is actually confused about that. We all know that server also can mean "computer that is being used to serve", and we all know that "serverless" does not mean that there is no computer that is being used to serve.

I mean that "thingless" means there is no thing. In "serverless" software, there is still a server. In both the hardware and software senses, but again forget the hardware part.

It's just that the software itself is not also it's own server for itself.

What doesn't make sense to me is it just seems weird to use a word like that to apply to that condition. "serverless", if it were anything other than "server", would mean there is no server, or does not use a server, or does not work by way of a server, etc. Like software that isn't client-server in the first place.

In this context of web apps, I would say that "serverless" would be impossible or meaningless, but the closest thing to a meaning would be "I don't need to worry about running the server".

Of course no matter what, you do need to run or at least use, some kind of server. If you program using all microservices in place of functions, you still have a piece of code somewhere that calls the microservices, and that code needs to be installed somewhere and run somewhere, and that is a server you need to run. Even if it's a fully managed service, you still need to subscribe to the service and manage your account, which is essentially "running the server". Fail to do it correctly and the app stops working.

I guess an "engineless" car is a car without an engine, and that maps exactly to what they're saying serverless means, software that doesn't include it's own server. But cars do generally include an engine, so an "engineless" car is a exceptional thing and so a meaningful term.

But software normally never includes it's own server. That is a recent thing and still only in the subset context of web apps. "serverless" in that sense is more like saying "roadless" car.

Sure, the car in fact doesn't include it's own road so it's true, but weird. Cars don't generally include their own road so it's weird to point out.

If you said "roadless car" out of the blue, just like "serverless" it wouldn't actually be quite meaningful at face value, but the closest thing to a meaning would be a car that does not require a road. An off-road vehicle. Not a car that doesn't include a road.

Post reply on HN