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

231–240 of 670 posts

Re: The Serverless Revolution Has Stalled

#231

Post by justinram11 »

Demiurge wrote: post #227
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…

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.

Mostly it's about the maintenance costs of owning and managing a server -- on Lambda most of these tools are "set and forget".

I don't want to have to manage security updates, disk usage, or any of the other multiple things that come with owning a server.

I also could probably debate on the friendly-ness of just dumping all of these one-off services onto a single server (seems like it could get messy pretty quick), but I think you could probably go either way on that.

We are also an AWS shop for our "production" stack already, so there is no added overhead for owning an AWS account.

Re: The Serverless Revolution Has Stalled

#232

Post by GFischer »

nickjj wrote: 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 can report that Azure Function App development is at least pretty decent, as long as you have the paid Visual Studio IDE and Azure Function Tools (haven't tried the free version yet).

I tried AWS Lambdas a few years back and it felt way more primitive.

Re: The Serverless Revolution Has Stalled

#233

Post by ByteJockey »

pixl97 wrote: post #45
lrem wrote: post #28

Earlier quoted context omitted.

Wasn't the point of serverless to reduce complexity?

It turns out that complexity is very hard to reduce.

Complexity always exists. Sometimes it just exists in the interactions between what you think of as your application pieces (most often the case with microservices and lambda architectures).

That being said, it's always possible to add a bit more complexity if you're not careful.

Re: The Serverless Revolution Has Stalled

#234

Post by ChicagoDave »

mrkeen wrote: post #51
ChicagoDave wrote: post #29

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?

Because it’s a part of long-term planning and the lock-in variable a lower priority than all of the other factors.

Re: The Serverless Revolution Has Stalled

#235

Post by mark242 »

Demiurge wrote: post #227
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…

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.

Because that "cheap dedicated server" isn't all that cheap. Just the documentation for backups on your Hetzner server is ridiculous. Why, in the 21st century, should I as an application developer ever have to worry about that?

Let's say that Hetzner server goes completely toast at 2am and you get a pingdom message. You log in, realize you have to restore from backup. You fire up a new instance, and go through your restore procedure, and everything works great. You're lucky to be offline for an hour.

I cannot even tell you what would happen if an underlying instance running a Lambda goes offline, because it never happens. But let's say that an underlying machine dies in us-east-1. Lambda just starts running more instances of your code on another underlying group of cpus, and you aren't offline.

Re: The Serverless Revolution Has Stalled

#236

Post by the__alchemist »

"For those new to the term, a quick definition. Serverless computing refers to an architecture in which applications (or parts of applications) run on-demand within execution environments that are typically hosted remotely."

That sounds like the opposite of serverless.

Re: The Serverless Revolution Has Stalled

#237

Post by heavyset_go »

rektide wrote: post #103
whalesalad wrote: post #93

Earlier quoted context omitted.

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 e…

I agree with your sentiments. I've found that OpenFaaS[1] has been nice to work with and you can deploy it wherever.

[1] https://github.com/openfaas/faas

Re: The Serverless Revolution Has Stalled

#238

Post by andrewmutz »

alpb wrote: post #168

Kind of also surprised I think this author has not heard of Google Cloud Run ( https://cloud.run/ ). Cloud Run employs a vendor-neutral container runtime and API (from Knative open source project). It simply accepts any OCI container that can listen on $PORT number. Similarly, the author talks about serverless not being able to run "entire applications", which again, doesn't apply to Cloud Run. Many people run fully-…

I came here to say this. We deploy production apps on cloud run and it is awesome. It directly addresses the problems that the author cites.

I think it, and the Knative project more broadly, is the future of serverless.

Re: The Serverless Revolution Has Stalled

#239

Post by nickjj »

kortilla wrote: post #202
wiremine wrote: post #199

Earlier quoted context omitted.

> 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 and "real" function invokes required way too much effort. Honestly, it reminds me of PHP development years ago: running it locally sucked, so you need to upload it to the server and test your work. It. Sucked.

It was actually pretty good if you had an IDE with sftp/scp support because you could save a file, refresh your browser, and have immediate new results.

Yeah this wasn't too bad and it was what I used to do back in the day with Notepad++. By the time you hit save in your editor, your changes were ready to be reloaded in the browser.

With SAM we're talking ~6-7 seconds with an SSD to build + LOCALLY invoke a new copy of a fairly simple function where you're changing 1 line of code, and you need to do this every time you change your code.

That's even with creating a custom Makefile command to roll up the build + invoke into 1 human action. The wait time is purely waiting for SAM to do what it needs to do.

With a more traditional non-Serverless set up, with or without Docker (using volumes) the turn around time is effectively instant. You can make your code change and by the time you reload your browser it's all good to go. This is speaking from a Python, Ruby, Elixir and Node POV.

Re: The Serverless Revolution Has Stalled

#240

Post by myrloc »

jacques_chester wrote: post #157
jpdb wrote: post #144

Earlier quoted context omitted.

I used to be complain about the same thing and even asked someone who was head of BD for Serverless at AWS what they recommended, and didn't get an answer to my satisfaction. After working with more and more serverless applications (despite the development pains, the business value was still justified) I realized that local development was difficult because I was coupling my code to the delivery. This is similar to t…

> 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’d be interested in seeing more of your results, no matter how raw they are.
Post reply on HN