Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

51–60 of 670 posts

Re: The Serverless Revolution Has Stalled

#51

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…

> 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 does not exist.

Why do you think companies stick with vendors for so long instead of switching?

Re: The Serverless Revolution Has Stalled

#52
post #38

Earlier quoted context omitted.

I’d be curious to see the data behind that claim that the hobbyist market is overwhelmingly PHP. I must not have any exposure to that ecosystem because PHP does not come to mind when I think of hobbyist development.

Maybe not hobbyists, but wordpress alone powers like a a third of the web.

Sure, but Wordpress is nothing to do with PHP lambdas.

Re: The Serverless Revolution Has Stalled

#53

I'd point out two other aspect not mentioned here - first is that the complexity doesn't go away. Application architectures running on a 'serverless stack' have a lot more moving parts than a traditional server based equivalent. Try showing the you from 10 years ago a modern serverless architecture and they'll think you're mad. More moving parts is more maintenance/problems, but on the plus side, does allow you to th…

I agree. I only generally use Fargate with containers, and control with cron or with always on APIs, with Cloudwatch for monitoring, and it’s seems like a good midpoint between ec2 and serverless.

The APIs cost a bit more a month (they’re on quite low cpu/memory) because they’re always on, but it minimises complexity and it’s nice to know that you can move those containers over to another platform if needed.

Re: The Serverless Revolution Has Stalled

#54

Has the noisy neighbor been solved when running serverless?

On Azure, I haven't really seen this problem. But you can also pay for dedicated serverless via Premium (but you pay per core/mem allocated vs. number of executions). It seems pretty interesting since multiple function apps can share the same infrastructure (allowing for more dense deployments).

"Dedicated serverless".

We've come full circle.

Re: The Serverless Revolution Has Stalled

#55
What the article author doesn't get: Serverless cloud platforms and APIs are the 21st century equivalent of OS APIs and libraries. They're still maturing, but the abstraction has moved up a level. Most people don't care (and fewer want to) what OS or other low-level stuff is running their code.

Today, we're still too focused on what's going on inside the boxes - in the future, more people will realize that the important part that brings value is how the boxes are "plumbed" together. We're already seeing the beginnings of this with serious no-code/low-code platforms, which are ideally suited for these kinds of services environments. (Soon, they won't all be cloud-based, either...)

Re: The Serverless Revolution Has Stalled

#56

Has the noisy neighbor been solved when running serverless?

On Azure, I haven't really seen this problem. But you can also pay for dedicated serverless via Premium (but you pay per core/mem allocated vs. number of executions). It seems pretty interesting since multiple function apps can share the same infrastructure (allowing for more dense deployments).

User/application density is the real potential win for serverless IMO, that no one ever really talked about (to my knowledge) and noisy neighbor was the problem to be solved. The real world indicator would have been hosting costs going to zero and 10-100x apps multiplexed onto the same "real" server substrate. Instead everyone is perfectly happy paying for cloud vm instances. In hindsight I guess "function as a service" wasn't the complete solution I thought it was.

Re: The Serverless Revolution Has Stalled

#57
post #5

Serverless is the new microservice. Fortunately, for the most part it’s fallen flat on its face and for good reason - most companies don’t need it: it adds unnecessary complexity for minimal gains.

It‘s not a new microservice, it’s a new name of grid computing with more than 20 years of history. I have been working with a grid in ~2001, running Java-based GUI apps on thin clients from a distributed cluster of several sparc machines. Was an interesting concept with unclear economics (likely useless with the internet connection speeds of that time). It’s not difficult to imagine it as an alternative to GSuite with much less resources required on the client.

Re: The Serverless Revolution Has Stalled

#58
post #11
post #2

"Limited Programming Languages" AWS Lambda can run all programming languages via layers. Cloudflare Workers can run all programming languages that compile to WebAssembly. "Vendor Lock" True, but being locked into Kubetnetes isn't a cakewalk either. "Performance" Cold-starts aren't a thing for Cloudflare Workers and can be mitigated for AWS Lambda. AppSync and API Gateway don't even have them if you directly integrate…

Sure, everything can be done serverless with a bunch of workarounds, that's one of the reasons it stalled IMO. Serverless makes somethings easier and other things harder, so it's advantages over good old fashioned servers are clear cut.

Did you mean aren't clear cut? Autocorrect?

Re: The Serverless Revolution Has Stalled

#59

From an evolutionary point of view, I find serverless appealing and exciting - a romantic idea. However, the frequent posts along the lines of "my Lambda function was buggy and now I owe Amazon three billion dollars" definitely kills the romanticism.

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)
Post reply on HN