Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

81–90 of 670 posts

Re: The Serverless Revolution Has Stalled

#81

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…

Infrastructure is always much harder to maintain (and test) than application code. Serverless architectures can risk moving complexity from (easy-to-test) application code to (hard-to-test) infra.

Re: The Serverless Revolution Has Stalled

#82
post #22

The issue is that they represent in some manner an 'alternative architecture' that's less mature and hard to piecemeal break out of. You need to move a few pieces around. I don't agree that 'once you've gone K8 why bother, just use that' - I don't think K8 is as elegant as the promise of serverless, and it has it's own 'lock in'. Just so happens you may need to have K8s anyhow ... so the pragmatic question then is 'W…

K8s lockin isn't the same. You can run it on any cloud, or run it locally. None of that is true for serverless functions (unless you go for knative, which is, yep, built on K8s).

Re: The Serverless Revolution Has Stalled

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

Serveless platforms like AWS Lambda are great for "glue" between services, or for workloads that are used infrequently. It can also be a great replacement for scripts that need to be run via a cron job (its surprisingly hard to create a highly available idempotent cron system using servers) provided all of the dependencies fit in the small space allotted.

I'm not sure I understand your point about not needing a deployment chain. I developed a framework (open sourcing it soon) using Jenkins Pipeline DSL for deploying Lambda functions and its very useful and helpful.

Regardless of the target environment the reasons for using a deployment pipeline are still there even if you use a server less platform.

Re: The Serverless Revolution Has Stalled

#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, connection draining, etc.)

Re: The Serverless Revolution Has Stalled

#86
post #2

"Limited Programming Languages" AWS Lambda can run all programming languages via layers. Cloudflare Workers can run all programming languages that compile to WebAssembly. "Vendor Lock" True, but being locked into Kubetnetes isn't a cakewalk either. "Performance" Cold-starts aren't a thing for Cloudflare Workers and can be mitigated for AWS Lambda. AppSync and API Gateway don't even have them if you directly integrate…

K8s can go almost anywhere any time with fairly minimal ramp. With the frequency I am hearing about AWS billing disputes these days it's probably best to not seal the keys to your kingdom in their service.

The problem is getting K8s to the point that it can go almost anywhere.

Re: The Serverless Revolution Has Stalled

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

Keep in mind Firebase has a big caveat. Firebase is great... for what it does. However, there's no way to easily migrate the Firebase resources to the larger GCP ecosystem. Firebase does what it does, and if you need anything else, you're out of luck.

Firebase is magic... but I never recommend it for anyone, until there's some sort of migration path.

Re: The Serverless Revolution Has Stalled

#88
post #49

I am still on the serverless high, and I don't see it going away any time soon. For the large corporation that I work for, things like soc2, patching, server maintenance, etc. are a giant pain every single month. The quicker we switch as many things as possible to serverless the better. One of the services I converted over went a year and a half with absolutely no attention from our engineers. It was great seeing how…

How do you use Terraform with Lambda? That's been one of the huge painpoints in my limited Lambda experience. All the CI tools (SAM, Serverless Framework, e.g.) seems to want to handle the IaaS part themselves and step on Terraform's toes. I just want to set everything up with Terraform and then have a nice simple tool to build and deploy the application.

We use terraform and terragrunt by themselves to deploy lambdas. No frameworks. It's slightly more work, I guess. But deploying and understanding how deployments happen is easier this way. Plus, getting any kind of framework approved in a corporation is annoying as heck, whereas we already use terraform and terragrunt.

https://registry.terraform.io/providers/hashicorp/aws/latest...

The biggest annoyance is unit testing, although it forces certain good habits on us. So for example, since we don't use SAM, we have to do unit testing separately (our code is in Python). But because we can't exactly run a lambda via Python, we have to put most of our code in the layers that our lambdas import.

So we run unit tests on the layers, and the positive is that we can essentially copy and paste the code that our lambdas would run into the unit tests. And then we can keep it DRY because almost all the code is in layers, and that incentivizes us to create generic functions that can be used across all of our lambdas.

For things like unit testing DynamoDB, we use Moto which works exceptionally well.

https://pypi.org/project/moto/

More detail:

Our terraform has infrastructure code for:

API Gateways

Hard-coded API keys we use for testing

DynamoDB tables

IAM roles used by the Lambdas and Step Functions

Lambdas themselves

s3 buckets used for the Lambda zip files and state

Step functions

Re: The Serverless Revolution Has Stalled

#89
post #11
post #2

"Limited Programming Languages" AWS Lambda can run all programming languages via layers. Cloudflare Workers can run all programming languages that compile to WebAssembly. "Vendor Lock" True, but being locked into Kubetnetes isn't a cakewalk either. "Performance" Cold-starts aren't a thing for Cloudflare Workers and can be mitigated for AWS Lambda. AppSync and API Gateway don't even have them if you directly integrate…

Sure, everything can be done serverless with a bunch of workarounds, that's one of the reasons it stalled IMO. Serverless makes somethings easier and other things harder, so it's advantages over good old fashioned servers are clear cut.

In my experience there are only a few edge-cases that need workarounds and even those get fewer with every release.

Re: The Serverless Revolution Has Stalled

#90

Earlier quoted context omitted.

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

is it, though? Every person I know with side projects writes them in either nodejs/ + react/vue or django/flask + react/vue/templates

That is just the divide between frontend devs and backend programmers.
Post reply on HN