Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

101–110 of 670 posts

Re: The Serverless Revolution Has Stalled

#101
post #59

Earlier quoted context omitted.

Honestly, we've had a lot of fun with OpenFaaS and services that can publish to it. You'd be surprised how great it is to pass a parametized query and have it turned into a function quickly. Doing stupid things on AWS is really easy and sadly billing can be up to 24 hours delayed.

Isn't there some sort of security built-in, like "if suddenly the bill becomes 1500% the norm, kill the instance and start serving 404s"? (I know nothing about cloud, honestly curious)

It's in cloud vendor's interests to charge more money regardless of mistakes. They do offer charge limits, but they don't want you to use them.

There are lots of posts online that document "talk to amazon and they'll take out the extra charges" but there are even more cases where the people just pay the bill and thus amazon makes money and profit.

Re: The Serverless Revolution Has Stalled

#102
post #90

Earlier quoted context omitted.

is it, though? Every person I know with side projects writes them in either nodejs/ + react/vue or django/flask + react/vue/templates

That is just the divide between frontend devs and backend programmers.

Not necessarily. After I discovered node/typescript I don’t think I will ever go back to PHP.

Re: The Serverless Revolution Has Stalled

#103
post #25

Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…

I felt your pain immediately and decided to write my own mini-framework to accomplish this. What I have now is a loosely coupled, serverless, frontend+backend monorepo that wraps AWS SAM and CloudFormation. At the end of the day it is just a handful of scripts and some foundational conventions. I just (this morning!) started to put together notes and docs for myself on how I can generalize and open source this to mak…

A lot of these DX (developer experience) concerns are, imo, rooted in what the article describes as "Vendor Lock".

Sure, you can write a bunch of tools to work around the crufty, terrible development environment's shortcomings. But ultimately, you are just locking yourself further & further & further in to the hostile, hard to work with environment, bending yourself into the bizarre abnormal geometry the serverless environment has demanded of you.

To me, as a developer who values being able to understand & comprehend & try, I would prefer staying far far far away from any serverless environment that is vendor locked. I would be willing & interested to try serverless environments that give me, the developer, the traditional great & vast powers of running as root locally that I expect. Short of a local dev environment, one meets both vendor lock in, & faces ongoing difficulties trying to understand what is happening, with what performance profiles/costs. I'd rather not invest my creativity & effort in trying to eek more & more signals out of the vendor's black box. Especially if trouble is knocking, then I would very much like to be able to fall back on the amazing toolkits I know & love.

Re: The Serverless Revolution Has Stalled

#104

I take issue with all of the complaints here... - performance: first rule of architecture is that you don't build the entire thing on the needs of high performance...you only address performance as-needed - vendor lock in: this is the worst reason. Most companies choose cloud vendors and stick with them over many years. I'd love any survey that showed some massive migration between vendors on a regular basis, but it…

>"I'd agree that it's stalled, but moreso out of fear and ignorance than anything else."

How about simple common sense instead of "fear and ignorance". I have a C++ monolith that serves me just fine already for years. The performance is great and I am able to rent dedicated servers that can serve at least 10 times more requests that I have at a price that is a tiny fraction of AWS for the same work.

Why would I switch and incure more expenses? What's the ROI?

Re: The Serverless Revolution Has Stalled

#105
Interestingly what ultimately sold me on a serverless deployment for one of our apps was security. When I compare the attack surface area of us deploying our own OS in the cloud vs just a handful of lambdas, it seems like a great way to let Amazon do the security work for us. If we were doing more in the cloud it may make sense for us to own that, but otherwise it would require us to spin up a whole set of dedicated devops just to maintain it and monitor it that we can avoid with serverless.

Re: The Serverless Revolution Has Stalled

#106
post #7

I never quite understood what problem serverless platforms were solving for companies that already deployed their own SAAS solution. As the article says, serverless is one of many (many) ways to wrap a quantum of functionality inside an internet-accessible environment. You could have a chunk of python in a serverless setup, a small flask server in a container in k8s, as an endpoint in a monolith, etc. Each of these e…

Another niche where it shines is the small, low-volume tool. You don't want to give it an entire VM, because that's a major waste. You don't want to have it share one "tools box," because it is awkward sharing like that, security becomes more of an issue, and it generally devolves into a mess. So if you've got other things running on AWS, then AWS Lambda is great for this. Do you need a random web-facing snippet to r…

Exactly our use case, esp. for things that are outside of k8s, for example, standard tasks that every cloud account of ours needs to perform (they are heavily segmented due to regulations) and developers or k8s ops do not get to touch. Almost all are on events or timers. Cronjobs without infrastructure to worry about are nice. Basically I wrote some of this stuff 5 years ago and didn't have to look at it since; it just runs.

Re: The Serverless Revolution Has Stalled

#107
post #68

LOL infoq. Srsly. > One of the advantages of serverless models is supposed to be that obscure, infrequently used programs can be utilized more cheaply, No-one: Literally no-one: Infoq: thinks serverless is all about obscure programs. > Vendor Lock Well try migrating a massive Java codebase to .NET or a deep Oracle application to Postrges. That's life. > Functions that have not been run on a particular platform before…

Mostly agree, but:

> Well try migrating a massive Java codebase to .NET

Java is a language, and an ecosystem of associated technologies. That's not equivalent from switching from one cloud provider to another, or even to your own machines. The equivalent might be, say, maybe switching between JVM implementations.

Re: The Serverless Revolution Has Stalled

#108
post #25

Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…

Developer experience for serverless is such a pain point, spot on. AWS SAM has tackled some of the IaC modeling problem (on top of CloudFormation which is a mature choice) and they've had a crack at the local iteration (invoke Lambda function or API Gateway locally with connectivity to cloud services). It's a little incomplete, missing some of the AWS IAM automation that makes local development smooth, environment ma…

Stackery is great. Doing serverless without an extensive toolset is impossible, which is sad.

Re: The Serverless Revolution Has Stalled

#109

An interesting rant to be sure, but what the author misses (in my opinion of course) that serverless isn't new, it just isn't recognized by a lot of programmers for what it is. Serverless computing is exactly mainframe computing. And by exactly I mean exactly. You see when I was taking CS classes for my degree students bought something called "kilocoreseconds" (kCs) and they are exactly what they sound like, they are…

Bows and hats off. I was thinking along the same line but your post is just a gem.

Re: The Serverless Revolution Has Stalled

#110
post #84
post #7

I never quite understood what problem serverless platforms were solving for companies that already deployed their own SAAS solution. As the article says, serverless is one of many (many) ways to wrap a quantum of functionality inside an internet-accessible environment. You could have a chunk of python in a serverless setup, a small flask server in a container in k8s, as an endpoint in a monolith, etc. Each of these e…

Among other reasons, enterprises love serverless b/c it relieves them of many server maintenance costs and risks. This includes things like: - OS patches and emergent fixes - Compliance certification - SSH access control and auditing - Secret distribution - Log rotation and storage - TLS termination - Configuring and testing auto-scaling policies - Deployment configuration (rolling deploys, blue/green deployments, co…

You don't need serverless for that. Any PaaS such as heroku provides those benefits.
Post reply on HN