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

The Serverless Revolution Has Stalled

infoq.com

Post reply on HN
Print view View original

301–310 of 670 posts

Re: The Serverless Revolution Has Stalled

#301

Post by mark242 »

Supermancho wrote: post #281
joana035 wrote: post #264

Earlier quoted context omitted.

Are you really sure?

Tracking exactly what individual db entries ran and didn't run when there's one of these "serverless" "painless" interruptions to an ETL, ensures that you have an endless number of ever-changing status columns and re-run processes. Are you really sure that it all re-ran? No. You have to query your latest batch - which means you have to have arbitrary boundaries for when failures might have occurred like say, last 24…

Here's the beautiful thing about thinking serverless. "Are you really sure that it all re-ran?" Yes I am, because Dynamo streams or Kinesis streams guarantee message delivery. If my Lambda code has a bug in it, which yes sure that happens, I can as part of my exception catching, put that message into a dead letter queue and process it later or report on it. No polling, no querying, I know exactly what went wrong and when.

Meanwhile, I don't have to do things like /make sure the ETL process is running/ or /clear out a bunch of logs when a disk inadvertently fills up/ or any of those other stupid last-century compute problems. It's just a far, far easier way of thinking about application development.

Re: The Serverless Revolution Has Stalled

#302

Post by rrdharan »

leptons wrote: post #140
takeda wrote: post #80

Earlier quoted context omitted.

While I am not that big fan of serverless projects (I am strongly convinced lambda should be used as a glue to automate AWS infrastructure and any other uses is just abusing it) you can use poetry with lambda. I'm sure there are other ways of doing it, but the way I do it is using serverless framework (is a nodejs app) together with serverless-python-requirements plugin. The plugin understand poetry (make sure you do…

>(I am strongly convinced lambda should be used as a glue to automate AWS infrastructure and any other uses is just abusing it) I've created a whole photo sharing website in AWS Lambda, including a complete user accounts system (register, login, forgot password, email verification, profile photos, etc), social aspects, as well as other things like youtube video search and transcoding in the same system. I also had to…

> And, if I did build a system with a ton of active users, Lambda handles the scaling of that.

This is a bold claim to make without verifying it.

> Another reason I spent the time to create this build system and write all the code to handle user accounts, etc.

But did you also spend the additional time to scale test it and verify it won’t break in confusing and annoying ways when scaling / spiking up? (see the other discussions re: connection pooling above).

The reason a lot of folks are skeptical is that in practice there don’t seem to be a lot of great examples of stateful services using a “pure” serverless lambda pattern but with arbitrary dependencies that actually do scale smoothly and don’t break in annoying ways such that you end up building something more complicated than just using App Engine or Heroku...

Re: The Serverless Revolution Has Stalled

#303

Post by dolni »

mark242 wrote: post #222

Here's why I love serverless. I cannot tell you the number of times I have implemented "upload your photo and it'll get resized to (profile avatar size from design specs)". It's ridiculous, and it's one of those things that everyone burns time implementing their fun hook into Imagemagick. Now I have one lambda that gets pointed at a new record stream from an S3 bucket, and I'm done. I cannot tell you the number of ti…

> It's that it makes that level of code reuse that much simpler. You have all of these helper infrastructure functions that you implement for every single project you work on, and reusing that glue code is so, so much easier in Lambda/GCF/AF/etc.

That sounds great until you need to add a feature or fix a bug in the reused code. Then you deploy a change to a Lambda function that impacts X other projects immediately, with no chance to test each of them individually.

Re: The Serverless Revolution Has Stalled

#304

Post by [deleted] »

ErikAugust wrote: post #288
justinram11 wrote: post #220

As someone on a two-man-team who runs a lot of little "utility" functions in AWS Lambda with the Serverless Framework[1] to support our DevOps / Build processes, it's been one of the most productive tools in my toolkit (after the initial learning curve, of course). It allows me to stand up a practically maintenance-free endpoint in a matter of hours (usually to glue separate services together): * Want to run a quick…

They are good for message queue handlers. But not good for production REST API endpoints in my experience. In the context of AWS Lambda, you are talking a 29 second timeout in API Gateway. API Gateway is fairly expensive. Also, is connection pooling a solved problem? Many times you can do better with an EC2 instance running PM2 and Express, or whatever. Like, what does Serverless Framework do locally anyway? Express?…

[deleted]

Re: The Serverless Revolution Has Stalled

#305

Post by recursive »

gitgud wrote: post #296
qayxc wrote: post #137

Earlier quoted context omitted.

But you forgot that always-on server it lives on. The idea behind serverless includes the fact that you don't pay for what you don't use. So if no requests are served, you owe nothing. Your FCGI solution shuts down idle copies, but keeps the server running...

> But you forgot that always-on server it lives on. A better comparison would be "Serverless" is "FCGI in shared environment"... if such a thing exists...

I recall running perl and php on shared hosts in the 90s. Probably not FCGI, but probably close in spirit.

Re: The Serverless Revolution Has Stalled

#306

Post by crehn »

kranner wrote: post #278
crehn wrote: post #241

Earlier quoted context omitted.

And I’d argue the mere possibility of the server breaking at any time contributes to non-negligible amounts of sustained psychological stress.

What about the psychological stress of a massive AWS bill because of a misconfiguration by you or someone on your team?

It’s acute.

Re: The Serverless Revolution Has Stalled

#307

Post by dolni »

rrdharan wrote: post #302
leptons wrote: post #140

Earlier quoted context omitted.

>(I am strongly convinced lambda should be used as a glue to automate AWS infrastructure and any other uses is just abusing it) I've created a whole photo sharing website in AWS Lambda, including a complete user accounts system (register, login, forgot password, email verification, profile photos, etc), social aspects, as well as other things like youtube video search and transcoding in the same system. I also had to…

> And, if I did build a system with a ton of active users, Lambda handles the scaling of that. This is a bold claim to make without verifying it. > Another reason I spent the time to create this build system and write all the code to handle user accounts, etc. But did you also spend the additional time to scale test it and verify it won’t break in confusing and annoying ways when scaling / spiking up? (see the other…

> > And, if I did build a system with a ton of active users, Lambda handles the scaling of that. > This is a bold claim to make without verifying it.

I mean, Lambda's ability to scale is a well documented thing. It will happily do more if you ask it to.

The real scaling problem is your wallet, because Lambda is damn expensive once you have any somewhat serious compute requirements.

Re: The Serverless Revolution Has Stalled

#308

Post by dolni »

Silhouette wrote: post #276
Havoc wrote: post #18

I think it's more a case of it coming full circle. People realising that it's just another tool in the toolbox rather than 1 tool that can replace their entire toolbox. Much of the cynicism seems to come from that. I do agree with jason though - open ended serverless things charged per use are no fun. Now you can bankrupt yourself at scale with that bug & the 1000 instances.

I was baffled, bemused even, by the article's premise that anyone rational ever thought serverless was going to take over the software world. It's a tool for solving a certain niche problem, not a general replacement for the vast majority of software we run. It's quite a good example of both the potential benefits and the potential difficulties of working in the cloud. Whenever I read these articles, I always wonder…

> I was baffled, bemused even, by the article's premise that anyone rational ever thought serverless was going to take over the software world.

The way people talk about it, I certainly get the impression that a lot of people think that way.

But I agree with you in full otherwise - there is no way that Lambda is going to completely usurp all forms of computing in the cloud.

Re: The Serverless Revolution Has Stalled

#309

Post by dolni »

pier25 wrote: post #113

There is a great misunderstanding as to what serverless actually is. So many people, including this article, equate serverless to cloud functions. There are plenty of services like Google Cloud Run or FaunaDB that are also serverless. IMO what makes something serverless is that you don't need to provision or manage infrastructure, and also no need to worry about scaling as it will go up and down as needed.

> IMO what makes something serverless is that you don't need to provision or manage infrastructure, and also no need to worry about scaling as it will go up and down as needed.

This is why serverless is such a stupid term to begin with, IMO. It's not even an accurate descriptor (the stuff is running on a server _somewhere_), so it really could mean anything.

Something like "cloud functions" to describe Lambda and "managed Kubernetes" for Fargate. Of course, these terms are less sexy, so they'd never catch on.

Post reply on HN