Back to the '70s with Serverless
evrl.com
Back to the '70s with Serverless
1–10 of 310 posts
Re: Back to the '70s with Serverless
#2So 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.
Re: Back to the '70s with Serverless
#3The point on the level of complexity being unsustainable is a good one.
Re: Back to the '70s with Serverless
#4Great article, it resonates with everything that has gone wrong in the industry.
Re: Back to the '70s with Serverless
#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 to CloudWatch to see what actually happened - it’s all batch-driven, just like the bad old days, so progress is slow. At least we’re not having to walk to the printer on every try, but that pretty much sums up the progress of the last half century. Oh, and a “Function” will be able to handle a single request concurrently, so here’s your AWS hosting bill, we needed a lot of instances, I hope you won’t have a heart attack. Yes, we run workloads that your nephew can run on his Raspberry Pi 4, but this is the future of enterprise.
I've mentioned as much to several C-suite executives and professional venture investors I know who tend to wax philosophical about "exponential growth in cloud services and big data" and whatnot. Invariably, their response has been to tell me that I just don't get it, or that I make no sense. They give me puzzled looks and maybe even get a bit exasperated with me.
Surely others here on HN have run into similarly minded individuals too. They're not hard to find.
Plus ça change, plus c'est la même chose.
Re: Back to the '70s with Serverless
#6A lot of truth in this article, but dont get me wrong, the added complexity is what is fuelling the market and we are all parts of this.
Re: Back to the '70s with Serverless
#7So 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. Perhaps somebody with better recall than I can fill in the details.
Re: Back to the '70s with Serverless
#8> 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 faffing around getting all the labyrinth moving parts of AWS/Azure/etc. working.
And the whole thing becomes a transparent farce when you look at providers like Azure, where their own admin interface is so slow and prone to random breaks you have to ask:
How is this scalable?
It's clearly not scalable for themselves, so how is it "scalable" for everyone else?
There are benefits, mainly for me I'll use them for hassle free deploys[1], but the whole thing sometimes feels like a massive con to sell the performance of a potato by advertising it as a jet engine.
[1] Like a month back I deployed a demo prototype web app I wrote in 3 hours onto Azure straight from github with like two clicks, and got the contract, can't really beat that.
Re: Back to the '70s with Serverless
#9So 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.…
Indeed. Unix even has it.
https://www.rigacci.org/docs/biblio/online/sysadmin/ch21.htm
Re: Back to the '70s with Serverless
#10So 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 know on the Control Data Cybers the time was measured by the second with 3 digits after the decimal. Might have been measured with even finer granularity, but that's what they displayed.