Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

221–230 of 670 posts

Re: The Serverless Revolution Has Stalled

#221
post #217
post #216

I've read through a bunch of comments but don't see anything to answer this question. Is there a way to use one "serverless" framework in one place and then use another in another place? For example, I love dokku. It is so easy to have the heroku like experience on the cheap. But I wonder: what happens if I need to scale my application bigger than the dokku server it's on right now? I really like the immediate protot…

I think the answer is yes, but you have to figure it all out yourself.

That seems like an opportunity for a smart PM to build on an awesome development environment. I wish, for example, that the Google Cloud Run people would talk about that. They probably need to plan for world domination and have a roadmap that includes their own way of doing it, sadly.

Re: The Serverless Revolution Has Stalled

#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 times I have implemented "when this user signs up, send them a welcome email." It's one of those things where you construct your email, point it at your MTA, do a ton of configuration, then it may work. Now I have one lambda that gets pointed at a new record stream from Dynamo, which calls SES, and I'm done.

I cannot tell you the number of times I have implemented "clear the Redis cache if a user changes their preferences". You write a clearUserCache hook into your DAO, or you paste it manually into your crud functions, and you always forget something, and six months down the line you start getting bug reports of people's zip code not updating, or something. Now I have one lambda that takes record streams from Dynamo, removes a key from Elasticache, and I'm done.

It's not that you couldn't do this before serverless, of course you could and you still can. 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.

Re: The Serverless Revolution Has Stalled

#223
post #163

Earlier quoted context omitted.

> I realized that local development was difficult because I was coupling my code to the delivery. Of interest, I've spent some free time crunching on CNCF survey data over the past few months. Some of the strongest correlations are between particular serverless offerings and particular delivery offerings. If you use Azure Functions then I know you are more likely to use Azure Devops than anything else. Same for Lambd…

I think his point was that you should be able to run and test the Lambda code independently of Lambda. After all the entry point is just a method with some parameters, you can replicate that locally.

Yes, this is a great way of doing things - I have no problems TDD'ing business logic hosted in Lambda, because the business logic is fully decoupled from the execution environment. SAM should be for high-fidelity E2E integration testing.

Re: The Serverless Revolution Has Stalled

#224
post #118
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.

With that definition, wouldn’t something like beanstalk qualify? I think that definition is overly broad. However, you’re right in that it does make me wonder where the definition should start or end.

You're responsible for managing the server in beanstalk, but it's not far off. I suppose it's just an earlier generation of the same idea. WHat I mean is, beanstalk runs on EC2 instances that you are responsible to make sure are patched, configured correctly and have everything you need for your application to run.

Fargate/Cloud Run are probably better serverless examples - you bring a container and config and the cloud provider will handle the rest.

Re: The Serverless Revolution Has Stalled

#225
I don’t believe that the FaaS revolution has stalled, though I fear it will follow the tech adoption curve because people are over hyping it.

I do wonder if AWS’s leadership in the area has stalled though.

GCP has innovated with their hybrid Cloud Run to allow running more traditional apps in a serverless way.

Azure and CloudFlare have paved the way to what I believe is the future with stateful functions with Durable Functions and Durable Objects respectively.

Meanwhile Lambda just seems to be gold plating it’s (admittedly great) but stale offering.

Re: The Serverless Revolution Has Stalled

#226
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)

Nope. As the GP mentioned, billing is delayed, but you could set alarms on your lambda usage. You could even use something like X-Ray to get more insight into what your usage looks like.

The problem is there's not a clear way to tell the difference between recursive calls and heavy traffic.

AWS components are fundamentally a network of nodes that are sending traffic to other nodes. But there's no unifying language that can model this, so you can't describe what this graph ought to look like. (e.g. you want to be able to say "lambda Foo should be called twice for each event to Bar".)

And that'd be hard to do since most nodes are general purpose computers, like Lambda and EC2, that can send traffic anywhere for arbitrarily complex reasons.

Since you can't describe what it ought to look like, trying to alarm on it becomes a problem of detecting anomalies. You can sort of do it, but AWS doesn't want to do it because they'd be making a promise they couldn't generally keep.

Re: The Serverless Revolution Has Stalled

#227

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…

How is owning an AWS account easier than a cheap dedicates server? You should have a code repo and backups in either case.

At least some people mention "but I can scale this lambda x1000" and that's one advantage... But you can do all those tasks on a hetzner server in same amount of type, just python scripts.

Re: The Serverless Revolution Has Stalled

#228
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…

As a systems developer, comments like yours make me amazed at the state of web development. From the outside looking in, it seems like 10% code and 90% monkeying around with tooling and frameworks and stacks.

Re: The Serverless Revolution Has Stalled

#229
post #147

Earlier quoted context omitted.

Take a look at the [CDK]( https://aws.amazon.com/cdk/ ) if you haven't already. It lets you define your infrastructure using TypeScript, which then compiles to CloudFormation. You can easily mix infrastructure and Lambda code in the same project if all you're doing is writing some NodeJS glue Lambdas which sounds like what you're looking for. There's a couple of sharp edges still but in general it just 'makes sense'.…

CDK made IaC accessible to me. I hated raw CloudFormation and never bothered with it because of that reason. I had a crack at Terraform, but never got passed the learning curve before my enthusiasm died. Currently using some CDK in a production app and finally I found a way of doing IaC I actually enjoy.

You might really like pulumi. I'm kind of on the opposite end, ops>swe so tons of IAC and i'm using pulumi now as I'm more swe focused https://www.pulumi.com/ (ive no relation to them)

Re: The Serverless Revolution Has Stalled

#230
post #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 switc…

Can your business adapt to change well? That’s the first issue with any monolith.
Post reply on HN