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

Why aren't we all serverless yet?

varoa.net

Post reply on HN
Print view View original

101–110 of 137 posts

Re: Why aren't we all serverless yet?

#101

Post by qaq »

sitkack wrote: post #98
qaq wrote: post #35

Earlier quoted context omitted.

the pricing is different for the same amount of compute is that news for you? Lambda is priced an order of magnitude higher than fargate which is priced significantly higher than EC2. For small scale workloads your TCO might be lower with higher level abstraction.

It is a billing switch, crazy that Amazon would publish a report of them do a rewrite of an application when the distinction is one of book keeping. You would think they would want to sell their expensive solution.

There is tangible overhead to all the extra tracking Lambda infra has to do.

Re: Why aren't we all serverless yet?

#102

Post by frereubu »

9rx wrote: post #75
frereubu wrote: post #55

Earlier quoted context omitted.

I hate the term "serverless". It's a misnomer to the extent that it feels like it was designed to deliberately mislead. Even vague consultant-speak like "externally provisioned infrastructure" would feel more accurate.

It seems it is only a misnomer if you are too young to remember how these types of applications used to be written. They weren't always servers. In the early days they were subprocess modules[1]. "Serverless" is a return to the subprocess model, seeing the application lose the server, or to put it another way the application is less a server. This must be why they say programming is dead once you turn 40: You can no…

I did start dabbling in computers in the early 80s, but I think there are far more people doing that now who have no concept of what actually happens and are are often sold pups because things are given deliberately obscure and cool-sounding names. (And people who name it like that are often extremely hostile when you ask questions, see my comment here: https://news.ycombinator.com/item?id=42549723) Of course buyer should beware, but I still think it's not OK to do.

Re: Why aren't we all serverless yet?

#103

Post by 9rx »

Brian_K_White wrote: post #100
9rx wrote: post #75

Earlier quoted context omitted.

It seems it is only a misnomer if you are too young to remember how these types of applications used to be written. They weren't always servers. In the early days they were subprocess modules[1]. "Serverless" is a return to the subprocess model, seeing the application lose the server, or to put it another way the application is less a server. This must be why they say programming is dead once you turn 40: You can no…

I'm from even before that, and it makes no sense to me. I understand both what you say and what "serverless" commonly means, I'm just saying it's essentially arbitrary. A symbol with no etymology that holds water.

All words are arbitrary, but how does it not make sense? "Server" is a well understood term in software. "Less a X" is well understood in English to mean something akin to "without X", or "not having X". Serverless is short for "less a server", which succinctly indicates exactly what it is: The application is without a server. Which is a shift in how these types of applications are written, as since the mid-2000s it was common to include a server as part of the application. "Serverless" makes more sense than most terms we use in industry. It literally describes itself, although does require some historical context to understand why "server" is relevant.

Understandably, if you don't come from the software world you might think a server is a person who does work at your request, like serve you food at a restaurant. Is that where the problem lies? There are definitely still people, servers, serving the care to the systems that run the software. But that is clearly not the context in which it is used. It is very much used as a software term, and as a software term alone.

Re: Why aren't we all serverless yet?

#104

Post by cesarb »

> The median product engineer should reason about applications as composites of high-level, functional Lego blocks where technical low-level details are invisible.

We don't make buildings from Lego blocks. We do use modular components on buildings (ceramic bricks, steel beams, etc), but they are cemented or soldered together into a monolithic whole.

In my opinion, "serverless" (which, as others have noted, is an horrible misnomer since the server still exists; true "serverless" software would run code exclusively on the client, like desktop software of old) suffers from the same issue as "remote procedure call" style distributed software from back when that was the fashion: introducing the network in place of a simple synchronous in-process call also introduces several extra failure modes.

Re: Why aren't we all serverless yet?

#105

Post by deivid »

franktankbank wrote: post #81
deivid wrote: post #44

IMO, the dev workflow is significantly worse, integration testing is harder and I don't see the value on "scale to zero", when the alternative is a $5/mo VPS.

Agree with you but you're paying for the potential of a sudden burst in traffic planned or unplanned. Going to maintain 5000 servers when you may only use them for some intense period a few hours of a single day during a month. Thats the canonical serverless pitch. I'd hate to develop a new pipeline using serverless as my dev environment.

I understand the value of something like this for seasonal businesses / black friday / etc; but for normal companies, how likely is it to _suddenly_ blow up in traffic?

If you are lucky enough to have your company go viral and receive a sudden spike in traffic, will the rest of the infrastructure tolerate it? Will your database accept hundreds of concurrent connections, or will it tip over?

If you need to engineer and test the auto-scaling capabilities of the rest of your infrastructure, is there value in not needing to think about the scaling of your APIs?

These may sound snarky, but they are real questions -- I used to administer ~300k CPU cores, so I have some trouble imagining the use-cases for serverless

Re: Why aren't we all serverless yet?

#106

Post by cesarb »

9rx wrote: post #75
frereubu wrote: post #55

Earlier quoted context omitted.

I hate the term "serverless". It's a misnomer to the extent that it feels like it was designed to deliberately mislead. Even vague consultant-speak like "externally provisioned infrastructure" would feel more accurate.

It seems it is only a misnomer if you are too young to remember how these types of applications used to be written. They weren't always servers. In the early days they were subprocess modules[1]. "Serverless" is a return to the subprocess model, seeing the application lose the server, or to put it another way the application is less a server. This must be why they say programming is dead once you turn 40: You can no…

> It seems it is only a misnomer if you are too young to remember how these types of applications used to be written. They weren't always servers. In the early days they were subprocess modules[1]. [1] https://en.wikipedia.org/wiki/Common_Gateway_Interface

No, it's even worse a misnomer when you are old enough to remember these days. They were CGI modules... running under a server. They were not "without a server". They didn't work without a server.

And in these days, we did have plenty of applications without any server. For instance, desktop applications using local in-process databases were very common, and plenty of what people nowadays do within their browser (connecting to a remote server on the other side of the world) was instead done using these local-only desktop applications. These applications are what could legitimately claim the moniker of "serverless". Not something which can only work when under the control of a server.

Re: Why aren't we all serverless yet?

#107

Post by jedberg »

dolmen wrote: post #36
danieloj wrote: post #11

I still find the DevEx of serverless terrible compared to the well-established monolith frameworks available to us. The YAML config, IAM permissions, generating requests and responses, it's all so painful to get anything done. Admittedly I speak as a software engineer primarily building CRUD apps, where frameworks have had decades of development. I can see use cases for event-driven applications where serverless may…

Or maybe we just lack frameworks that provide the same developer experience but with transparent serverless deployment?

Here is an open source framework that my company makes that I think meets your requirements:

https://github.com/dbos-inc/dbos-transact-py

You can build your software as a monolith and deploy it with one command to your own cloud or our cloud.

Re: Why aren't we all serverless yet?

#108

Post by 9rx »

cesarb wrote: post #106
9rx wrote: post #75

Earlier quoted context omitted.

It seems it is only a misnomer if you are too young to remember how these types of applications used to be written. They weren't always servers. In the early days they were subprocess modules[1]. "Serverless" is a return to the subprocess model, seeing the application lose the server, or to put it another way the application is less a server. This must be why they say programming is dead once you turn 40: You can no…

> It seems it is only a misnomer if you are too young to remember how these types of applications used to be written. They weren't always servers. In the early days they were subprocess modules[1]. [1] https://en.wikipedia.org/wiki/Common_Gateway_Interface No, it's even worse a misnomer when you are old enough to remember these days. They were CGI modules... running under a server. They were not "without a server". T…

> They didn't work without a server.

Not true at all. You can use CGI scripts from the shell just fine. And you almost certainly did to aid with testing! Per the CGI specification, communication is through environment variables, stdin, and stdout. There was not a server in the application like we saw later. Since around the mid-2000s, when CGI fell out of fashion, applications of this nature usually meant them serving on port 3000 (probably). "Serverless" sees removal of the server from the application again, moving back to a process-based concept similar to what we did when CGI was the thing to use, although the protocols may be different nowadays. It is not in reference to a specific technology like CGI, rather the broader idea.

> And in these days, we did have plenty of applications without any server.

"These types of applications", not "all applications"...

Re: Why aren't we all serverless yet?

#109

Post by balder1991 »

callc wrote: post #67
bdcravens wrote: post #21

Earlier quoted context omitted.

Wireless routers also have wires.

Routers are much simpler to use when you connect to them with an Ethernet cable. Not all abstractions and simplified services are good in all situations. I really wish the 9mm headphone jack wasn’t being replaced with just Bluetooth. 9mm has worked for me 100% of the time. Bluetooth is regularly a piece of garbage.

Besides Bluetooth usually reecodes your audio before streaming it, which means even if you used the best codec to encode it from FLAC with carefully chosen settings, it will still suffer from being encoded from a lossy format to another lossy format at the moment you listen to it.

I read Apple avoids that with their AirPods if your audio is already encoded in a supported format, but I don’t know if other general systems are smart about it.

Re: Why aren't we all serverless yet?

#110

Post by 9rx »

qaq wrote: post #96
9rx wrote: post #91

Earlier quoted context omitted.

And even then it is not strictly necessary. Cloud Run comes to mind as offering the ability to scale to zero, yet allows (maybe even requires?) maintaining the server in the application. The real benefit of "serverless" is that you no longer have to worry about the server, it being removed. Granted, that is not a big worry much these days with all the great server frameworks available.

I’d much rather write 20 lines of boilerplate code and a Dockerfile than deal with 100s lines of CDK code, distributed tracing, and the associated observability challenges.

Some frameworks used to support serverless applications are completely over-engineered cesspools, no doubt, but it doesn't have to be that way.
Post reply on HN