Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

71–80 of 670 posts

Re: The Serverless Revolution Has Stalled

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

Part of the problem is that the hobbyist market is overwhelmingly PHP, which Lambda doesn't support natively.

Not natively, but fairly easily. We’re using Laravel Vapor - it handles all the setup and deployment of Lambda bundles that include the app code and a PHP runtime. Smooth and fast so far.

Re: The Serverless Revolution Has Stalled

#72
Serverless computing refers to an architecture in which applications (or parts of applications) run on-demand within execution environments that are typically hosted remotely.

Like CGI or FCGI programs! But with YAML!

FCGI really is a "serverless" environment. Launches an application when called for. Starts more copies of the application if there are enough requests. Shuts down idle copies when not needed. Starts a fresh copy if one crashes. You can even scale with load balancers. Really, that's most of what you need to get work done.

Re: The Serverless Revolution Has Stalled

#73

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 love any survey that showed some massive migration between vendors on a regular basis, but it does not exist.

Isn't this a sign of existing lock-in?

Also, I think lock-in comes in degrees. Some are worse than others. Even if we're slightly locked in right now, we can easily make it worse if we try.

Re: The Serverless Revolution Has Stalled

#74
Many apps don't need scaling. For B2B, getting first 100 customers is a big deed per say. But app owners buy the cool aid of cloud vendors and make things complicated. Don't trade simplicity for scaling unless you REALLY need it.

Re: The Serverless Revolution Has Stalled

#75

Earlier quoted context omitted.

Part of the problem is that the hobbyist market is overwhelmingly PHP, which Lambda doesn't support natively.

Not natively, but fairly easily. We’re using Laravel Vapor - it handles all the setup and deployment of Lambda bundles that include the app code and a PHP runtime. Smooth and fast so far.

Yeah; I'd imagine anyone technically savvy enough to use Lambda + API Gateway, in any form, is savvy enough to bundle PHP if they really want to use it. And if they're not savvy enough to do that, they're probably using hosted Wordpress somewhere and it's a moot point.

Re: The Serverless Revolution Has Stalled

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

Developer experience for serverless is such a pain point, spot on. AWS SAM has tackled some of the IaC modeling problem (on top of CloudFormation which is a mature choice) and they've had a crack at the local iteration (invoke Lambda function or API Gateway locally with connectivity to cloud services).

It's a little incomplete, missing some of the AWS IAM automation that makes local development smooth, environment management for testing and promoting changes, and some sort of visualization to make architecture easier to design as a team.

I work for a platform company called Stackery which aims to provide an end-to-end workflow and DX for serverless & CloudFormation. Thanks for comments like these that help identify pain points that need attention.

Re: The Serverless Revolution Has Stalled

#77
Serverless computing has been around for a while; it used to be called "shared hosting with CGI."

What's new is that it's become proprietary, instead of being based on open standards. This has made it hard to test serverless apps offline, and made it nearly impossible to move a serverless app from one cloud platform to another.

Re: The Serverless Revolution Has Stalled

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

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…

> Do you need a random web-facing snippet to receive a webhook a few times a day and send a Slack message to your team? Perfect.

How many people have that use-case but not in multiples? How many of those people have such a use-case but would not be better served by platforms such as IFTTT or webhooks on other services?

Re: The Serverless Revolution Has Stalled

#79

Earlier quoted context omitted.

Except that people actually used microservices and microservices are actually additive and helpful.

They are helpful in probably 10% of cases where they are indeed the right tool for the job and the benefits outweigh the downsides. For the majority of companies out there it's just a tool to overcomplicate your stack and turn it into an engineering playground so you can justify 2-3x the headcount despite no significant productivity increase. But hey, at least your company can now be giving talks about how they solve…

>justify 2-3x the headcount

As a worker, and not a company owner, this sounds awesome.

Re: The Serverless Revolution Has Stalled

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

To be honest, the serverless environments I dealt with had worse deploy experience than plain servers. There's a bit of a ritual around deploying a lambda for example and it requires a specific packaging process. I can't easily use poetry for python projects there. I guess if we count fargate as serverless, it's much better for this use case.

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 don't leave requirements.txt because it will use that, you don't need that file if you use poetry).

Anyway it has warts, one big thing is that nodejs developers don't care about norms and standards and constantly reinvent the wheel so for starters you're pretty much forced to create project.json project-lock.json files, which then will create node_modules directory in root of your project. Then you need to start project through npx command (I believe you could still install serverless globally but looks like that's being depreciated).

The node_modules directory will contain over 200MB of javascript code after you install it.

But after all of those things, when you get it to work it is not terrible.

Post reply on HN