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

Back to the '70s with Serverless

evrl.com

Post reply on HN
Print view View original

21–30 of 310 posts

Re: Back to the '70s with Serverless

#21

Post by perfectspiral »

thethethethe wrote: post #15

> You deploy individual stateless functions. But not inside a Java monolith, that is old, but on top of a distributed system. You would have been laughed out of the door if you had proposed that in 2000, and you should be laughed out of the door right now, but such is the power of marketing. I’m sorry but this absurd and blatantly ignores the reasons why people choose serverless. No mention of scale to zero, virtuall…

Why is the alternative to serverless, colocating servers in a DC?

The alternative is renting VMs from those same clouds. It works fine and is cheaper when you work on software that actually has users. It also doesn't result in the cloud provider cramming a crappy under-baked programming model down your throat.

Per request pricing and "scaling to zero" is just old fashioned unbundling. You are selling a smaller quantity of a product at a higher unit price and putting a bit of lipstick on that pig to convince people they are not getting hosed.

Re: Back to the '70s with Serverless

#22

Post by empthought »

mattmanser wrote: post #8
cs702 wrote: post #5

> So what have we now? A “mono repo” codebase, because clearly a Git repository per function in your system would be too much, a large deployment descriptor per fine-grained component, which Spring maybe called “Controller” but is now called “Function”, and instead of combining them all on your desktop, you send them off to someone else’s mega-mainframe [AKA "the cloud"]. You deploy, get an error message, and login t…

Everyone's chasing "scalable", mostly for no reason at all. There's also this enduring myth you see repeated even here of how much saving there is by not having "devops", when only very big companies needed them in the first place. A few minutes per month is the most devops any startup would need to do in reality running their own VMs or servers, after an hour or two of setup. And that hour or two is often less than…

> A few minutes per month is the most devops any startup would need to do in reality running their own VMs or servers, after an hour or two of setup.

Right up until something crashes or some hardware fails.

Re: Back to the '70s with Serverless

#23

Post by markus_zhang »

daxfohl wrote: post #17

My company is migrating a huge monolith to microservices. One of the proposed benefits is that it makes end to end testing easier because each service only interacts with a couple other services, so each service will be easier to write integration tests for. But in the monolith, those services communicate over interfaces, and are currently tested as unit tests! So we're replacing unit tests with integration tests and…

Just wait until BA asks for data from different sources and you have to connect those parts...

Re: Back to the '70s with Serverless

#24

Post by throwaway2048 »

mattmanser wrote: post #8
cs702 wrote: post #5

> So what have we now? A “mono repo” codebase, because clearly a Git repository per function in your system would be too much, a large deployment descriptor per fine-grained component, which Spring maybe called “Controller” but is now called “Function”, and instead of combining them all on your desktop, you send them off to someone else’s mega-mainframe [AKA "the cloud"]. You deploy, get an error message, and login t…

Everyone's chasing "scalable", mostly for no reason at all. There's also this enduring myth you see repeated even here of how much saving there is by not having "devops", when only very big companies needed them in the first place. A few minutes per month is the most devops any startup would need to do in reality running their own VMs or servers, after an hour or two of setup. And that hour or two is often less than…

Its like a well stocked grocery store with thousands of brands, I think the biggest draw of "the cloud" is the illusion of infinity plenty, all you need to do is press a button (even though the reality really doesn't measure up, at least not in ways people naively assume)

Re: Back to the '70s with Serverless

#25

Post by markus_zhang »

GrumpyYoungMan wrote: post #7
tybit wrote: post #2

So in the 70s you could pay per request billed to millisecond precision? Wow times haven’t changed at all. He has some good points on poor configuration languages and bad architecture, but it’s lost in the rant.

> " So in the 70s you could pay per request billed to millisecond precision? " It's been a while since I encountered it but yes, mainframe time was so blisteringly expensive that usage was accounted for on a per-job basis and billed to individual user accounts. I don't recall the resolution or pricing anymore but students would be issued an hour or so (?) of processing time to complete their coursework per semester.…

I remember seeing somewhere a Linux or Unix program or system that shows how much money it costs for running the program. I think it was from an online course but really couldn't remember where, but the cost is very expensive...

Re: Back to the '70s with Serverless

#26

Post by macintux »

v4nd0ck wrote: post #16

This is stupid. If you don’t recognize the benefits of serverless of the capabilities of this you shouldn’t be writing about it. Go back to retirement if you remember the 70s. Maybe you would have laughed people out the door in 2000 but that doesn’t mean you by any means are right. Serverless doesn’t add complexity but provides a service that manages everything for you without having to manage scaling manually. This…

There might be a useful rebuttal buried in your reply, but it's going to be killed by downvotes because you obscured it with ageism and arrogant dismissal.

Re: Back to the '70s with Serverless

#27

Post by chubot »

Wow, great post! I have the same complaints:

(1) Languages have gotten worse as distributed back ends have gotten more powerful. The IBM JCL and XML references in this post were good!

(2) Workloads that currently run on such back ends could run on a single computer, or at least with many fewer resources. This is one reason I got into shell in the first place! I wrote some shell scripts that saturated 32 cores instead of using distributed systems. In other words I try to avoid the "COST" or "parallelizing your overhead" problem.

We're paying a huge productivity tax and in many cases not reaping the rewards. I think a better better UNIX SHELL can help in the following ways:

(1) We need to bring the interactivity of Unix back to distributed systems. We're still in the days of "IBM Job Control Language" with Kubernetes config and similar kinds of "declarative cloud configuration". We need a flexible and efficient analogue of Bourne shell.

(2) Unix shell is already how you set up local development environments: Docker embeds shell; virtualenv changes your shell state, Ruby's bundler, OCaml's opam switch, etc. We need to evolve this into first class and polyglot environments specified in shell.

Debugging distributed systems locally could be the norm, but it's not.

The local topology should simply be a configured variant of the distributed topology, but it's not. I used to do this at Google with a trick of generating a shell script with BCL (Borg Config Language).

(3) A better shell should be able express configurations that evaluate to JSON, and also statically validate them before pushing, to solve this problem.

XML, however, was universally rejected in favour of things like JSON, Yaml, HCL, Toml - all free of structure, with zero indication whether a computer would find your prose gibberish or the next Shakespeare play until you actually pushed your code to some test cluster.

I want https://www.oilshell.org/ to go in this direction, and there is already some progress. (Feel free to contact me if this resonates with you.) And I have a draft of a blog post about shell, distributed systems, and languages that I need to publish, based on these comments from a couple weeks ago:

https://news.ycombinator.com/item?id=25343716

Those comments talk about the other problem with the cloud: that it locks you in to APIs! We need the POSIX of distributed systems. Kubernetes was trying to do that, but it's not good enough.

Shell can solve this problem more economically: it expresses UNPORTABLE glue code to leave your application PORTABLE. I did that with Oil's continuous builds, and the Unix-y gg FaaS framework also appears to do that in a pretty nice way.

Re: Back to the '70s with Serverless

#29

Post by la6471 »

cs702 wrote: post #5

> So what have we now? A “mono repo” codebase, because clearly a Git repository per function in your system would be too much, a large deployment descriptor per fine-grained component, which Spring maybe called “Controller” but is now called “Function”, and instead of combining them all on your desktop, you send them off to someone else’s mega-mainframe [AKA "the cloud"]. You deploy, get an error message, and login t…

[flagged]

Re: Back to the '70s with Serverless

#30

Post by still_grokking »

tyre wrote: post #11
cs702 wrote: post #5

> So what have we now? A “mono repo” codebase, because clearly a Git repository per function in your system would be too much, a large deployment descriptor per fine-grained component, which Spring maybe called “Controller” but is now called “Function”, and instead of combining them all on your desktop, you send them off to someone else’s mega-mainframe [AKA "the cloud"]. You deploy, get an error message, and login t…

I think what’s important to remember is that these kinds of “truth” are not the full story. Yes, a technology probably won’t live up to its marketing. Yes, what works is probably good enough. Yes, changing has switching costs and sacrifices institutional knowledge. Yes, we’ve seen these technologies before and switched away from them from various reasons. That’s all fine and sometimes frustrating as an engineer. But…

I don't think burning in sum hundreds of billions of Dollars (or even more) because "it's OK being irrational, because emotions" makes sense.
Post reply on HN