Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

411–420 of 670 posts

Re: The Serverless Revolution Has Stalled

#411

This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…

How about someone else is controlling your infrastructure and your project completely depends on their good will.

We need self-hosted serverless...

Re: The Serverless Revolution Has Stalled

#412

This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…

How about someone else is controlling your infrastructure and your project completely depends on their good will. We need self-hosted serverless...

Self hosted serverless has also been around for years. Lookup openshift, openwhisk, etc.

TFA is clickbait

Re: The Serverless Revolution Has Stalled

#413

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

Sounds like before you could run your code on a bunch of different providers, and now you can only run it on one that has S3, SES, and Dynamo.

Re: The Serverless Revolution Has Stalled

#414
post #404

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.

Out of genuine interest... is there a modern solution to this problem with PHP/MySQL? (I'm still doing the "upload to server to test" thing.... I've tried MAMP and Vagrant/VirtualBox for local dev but both of them seem horribly complex compared to what we can do with local dev with node.js/mongo and so on.)

"docker-compose up" and your OS, codebase, dependecies and data is up and running locally in the exposed local port of your preference. You can even split parts in different layers to mimic a services/cross-region logic.

Of course this won't fix the fact that you have a lambda behind api gateway that does some heic->jpg conversion and can't be hit outside the DMZ, or some esoteric SQS queue that you can't mimmic locally - but it should get you almost there.

Re: The Serverless Revolution Has Stalled

#415

This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…

> developers can produce generic code

There is nothing generic about the code that runs on serverless services. It’s the ultimate lock in.

Re: The Serverless Revolution Has Stalled

#416
post #45
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.

Well, sure. But you can outsource it pretty successfully in many cases. Absorbing someone else's complexity is what my job in Google is about.

Re: The Serverless Revolution Has Stalled

#417
post #252
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…

> Instead, you can write a function that takes parameters from elsewhere and call your business logic there. This is what I tried to do initially after experiencing the dev pain for only a few minutes. But unfortunately this doesn't work very well in anything but the most trivial case because as soon as your lambda has a 3rd party package dependency you need to install that dependency somehow. For example, let's say…

Unless I’be misunderstood, every knock against serverless above has actually been a knock against the complexity of having tiny, de-coupled cloud native services and how difficult it can be to mock... to which the answer is often “don’t mock, start by using real services” and then when that is less reliable or you need unit tests, then mock the data you expect. In the case of SNS, mock a message with the correct SNS signature, or go one layer deeper, stub out SNS validation logic and just unit test the function assuming the response is valid or invalid? In the case of Postgres, you could use an ORM that supports SQLite for dependency-free development but at a compatibility cost... worst case you might need to have your local machine talk to AWS and host it’s own LetsEncrypt certificate and open NAT port... but one can hope it doesn’t come to that...? Even so... that’s not exactly a knock against serverless itself, is it?

Re: The Serverless Revolution Has Stalled

#418

This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…

> developers can produce generic code There is nothing generic about the code that runs on serverless services. It’s the ultimate lock in.

Most actual FaaS code is quite portable; the configuration is what can’t move easily. And things like OpenFaaS and kNative make self-hosted runtimes completely flexible- it’s just a short-lived container.

Re: The Serverless Revolution Has Stalled

#419
post #330

Earlier quoted context omitted.

> Just the documentation for backups on your Hetzner server is ridiculous. Nothing a server template, code repo, and daily db dump cronjob can't solve

I’m assuming this is a joke, but this is exactly what most people who just want to run some code don’t want to deal with.

I like how people here pretend like this is some hard task that should only be done by experts when I know fifteen-year olds who figured this out all by themselfes for backing up their game servers

Re: The Serverless Revolution Has Stalled

#420

This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…

> developers can produce generic code There is nothing generic about the code that runs on serverless services. It’s the ultimate lock in.

At the moment.

Is there anything stopping an organisation from defining some standard types of serverless environments?

Is there anything stopping someone from turning that standard into implementations to help cloud providers offer it, or even be a fallback option that could be deployed on any generic cloud infrastructure?

I think those are the way forward from here.

Post reply on HN