Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

121–130 of 670 posts

Re: The Serverless Revolution Has Stalled

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

Literally nothing in that list is unique to Serverless. There is in fact at least 2-3 ways to do that in AWS alone using VMs.

Re: The Serverless Revolution Has Stalled

#122
post #97
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…

Wait until you get to work with the CDK, it's worse.

Can you elaborate why?

Re: The Serverless Revolution Has Stalled

#123
post #99
post #84

Earlier quoted context omitted.

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…

They can do the same thing with fargate, and that’s tons easier to manage.

Fargate is considered a serverless service. Serverless generally encompasses FaaS + BaaS. Think anything whose infrastructure you can use without touching the underlying VM(s): SQS, SNS, EventBridge, RDS, Lambda, Fargate, Athena, Kinesis and so on.

Re: The Serverless Revolution Has Stalled

#124

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…

Seconded. Serverless has the benefits and drawbacks of Microservices: you build and deploy smaller units, at the consequence of having to debug the interconnects between everything, with poor tools. I'm a fan of OpenFaas: you get the benefits (but not all the drawbacks) of containers and serverless. It's easy to mix and match running 100% locally, or mix-in baked 3rd party components, or running in Kuberenetes or oth…

+1 for openfaas. I haven’t used it in production, but the option to run an entirely custom container underneath the function opens up the possibility of running a “proper” application underneath (the use case I’ve been meaning to test is a fully-featured rails app)

Re: The Serverless Revolution Has Stalled

#125
post #66
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 found firebase functions pretty easy and painless. Worth a look.

Deploying is super slow. Usually it takes a minute or two, which is already quite long, but sometimes something goes wrong and then you can't redeploy immediately. You have to wait a couple of minutes before being able to redeploy.

To be fair, Firebase recently released a local development tool which alleviates the need to deploy on every change, but I haven't used it yet.

https://firebase.google.com/docs/emulator-suite

Re: The Serverless Revolution Has Stalled

#126
So many comments saying "Serverless just added complexity", then you read what they did and it's, "so I tried to move our entire infrastructure to Serverless and..." Umm, yeah?

And did we mention there's still a server?

Serverless is really not that complicated. But trying to plug a toaster into a super collider just might be.

Re: The Serverless Revolution Has Stalled

#127

Earlier quoted context omitted.

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…

I use that a lot. There's the joke lambda spackle sticker ( https://www.thecloudpod.net/product/lambda-spackle-sticker/ ) but that's exactly the great use case.

Thanks for mentioning our Lambda Spackle sticker. :-) Just throw a little lambda at all your op problems.

Re: The Serverless Revolution Has Stalled

#128

Because serverless is not serverless. Fundamentally this doesn't work because if you've gotta have a server in the end, why not either admin yourself or use one of the cloud vendor's other products for more control?

Serverless just means that your infrastructure is programmatically defined through configuration files rather than manually stiched together, so (in theory) the underlying silicon is abstracted away in a similar fashion to the x86 ASM that your code gets compiled to. In practice that isn't always the case (horror stories of rogue $xx,xxx/day lambda functions) but from my understanding that's the serverless end game.

Re: The Serverless Revolution Has Stalled

#129
The Serverless Revolution is still happening all around us, with products like Netlify and the new DO App platform, not to mention all the enterprises moving into the cloud and moving more of their systems into managed products, using serverless components to tie it all together.

Serverless is part of many different mini-revolutions that have been going on for around the same amount of time, with micro services, rebalancing to have more processing on the client side, managed cloud services within private clouds, and the no-code/low-code movement.

Some applications aren't meant for serverless; they need containers or even on-prem on occasion. But most applications are clients with some basic APIs, and many of those are being thrown up on Netlify and AWS and no one outside of the developers are really noticing.

Re: The Serverless Revolution Has Stalled

#130
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.

I've never used AWS Beanstalk but if it's like Heroku I don't think it qualifies as you are still provisioning infrastructure (much like with EC2).
Post reply on HN