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

491–500 of 670 posts

Re: The Serverless Revolution Has Stalled

#491

Post by jeroenhd »

nicky0 wrote: post #404
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.

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.)

Just run PHP and MySQL locally? Native PHP on Windows is horrible to set up, but with WSL/WSL2 you suddenly can get a normal Linux environment without much hassle.

sudo apt install nginx php mysql, point the www directory of nginx to something on your computer (/mnt/c/projects/xyz) and you've got a running setup. Or run Linux in general, that's what most people I've seen work on backends seem to do. You can run the same flavour of software that your deployment server runs so it'll save you time testing and comparing API changes or version incompatibilities as well.

I don't know any solution for macOS but you can probably get the necessary software via Brew if you're so inclined. Then run the built-in PHP web server (php -s) and you get the same effect.

Re: The Serverless Revolution Has Stalled

#492

Post by nicbou »

jeroenhd wrote: post #483
numlock86 wrote: post #464

Earlier quoted context omitted.

That's exactly the argument why you should go serverless. If all you do is keep a vanilla Linux distro running in a VM with occasional updates and some initial config-magic (webserver, certs, ip tables, ssh etc.) why even bother? The serverless isn't going to be any different, other than it just runs. No need to make a cron for updates, no iptables, no certs or webserver-stuff ... just put your app on it and let it g…

One reason serverless isn't the solution for most applications is that you're basically making yourself entirely dependent on the API of one specific cloud host. If Lambda decides to double its price, there's nothing you can do about it but pay. If you need to store your data in a specific place (for example, in Russia, because all Russian PII must be stored in Russian borders), then you're out of luck. And best of l…

You can also predict the costs, and shop around if your provider gets greedy. If Amazon changes its pricing structure, what are you supposed to do?

Re: The Serverless Revolution Has Stalled

#493

Post by collyw »

fizixer wrote: post #145
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…

> ... stack is vue/python/s3/lambda/dynamodb/stripe Did you chose python for backend dev? Any framework like flask or django? Also no preference of single-language for both backend and front-end, by using node.js backend? Just trying to get into web-dev.

Benefits of a single language are outweighed by the fact that the language is JavaScript.

Re: The Serverless Revolution Has Stalled

#494

Post by saimiam »

ec109685 wrote: post #361
saimiam wrote: post #325

Earlier quoted context omitted.

If you are expecting one thousand simultaneous requests, serverless or not, you will need a db and an appserver which support one thousand simultaneous connections. There is no getting around that. You will have to analyze your burst rate and the lifetime of each request to figure out the size of your connection pool. I also am not clear how AWS introduced the problem of not being able to connect to the DB. We've kno…

If your function spends 80% of its time on logic and 20% on database time, with a server app, you can get by with 200 DB connections to handle that throughout, but will need 1000 connections in a serverless setup.

I don't think connection pooling works this way. Happy to be corrected.

A process is given a connection from a pool when it requests the connection and holds it until it relinquishes the connection regardless of whether the process was in the logic or data access portions of their lifecycle. It is up to you as the developer to ask for the connection and to return it on an as-needed basis...Which is exactly what you should be doing in a lambda as well.

Just because a lambda container is persistent does not mean the connection given to it is stuck to that lambda even after that lambda returns the connection.

Re: The Serverless Revolution Has Stalled

#495

Post by nicbou »

michaelt wrote: post #442
methodin wrote: post #430

Earlier quoted context omitted.

I disagree. Every AWS Lambda function I've ever written can be ran as a regular node/python process. The lambda-specific part is miniscule. If I wanted to run these on Azure or Google only the most inconsequential parts of the function would need to be changed.

In my experience, having started and abandoned side projects in both aws lambda and google app engine, half your project becomes: * Well, obviously we use a hosted database * And obviously, AWS provides our logging and all our analytics. * Obviously when people call our lambda functions, they do so either through an AWS-specific API, or one constrained to a very limited set of forms. * Of course, we can't blindly let…

This, but it was told by serverless experts, on stage, in front of hundreds of people. If that was their sales pitch, their reality was likely even less impressive.

Re: The Serverless Revolution Has Stalled

#496

Post by nicbou »

nicky0 wrote: post #404
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.

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.)

I always run stuff inside docker. If it runs on my machine, it will run in production.

Re: The Serverless Revolution Has Stalled

#497

Post by darkwater »

sippingjippers wrote: post #471
randomsearch wrote: post #406

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…

It's not clear to me how much experience with serverless architectures the author of the parent comment has, but speaking as someone with plenty, the operational costs of serverless are at least equal to managing stateful infrastructure, with much less control when things go wrong. Lambda was a major step up in long term predictability compared to for example App Engine, where there have been plenty of instances of o…

This. 100 times this. Also, in several places most of the services downtimes are due to, you know what? Application bugs, not infrastructure outages. Sure, they happen as well and being on a good cloud provider mitigate a lot of them (but not all of them!) but if you increase the application design complexity you will increase also those downtimes. Yeah sure, there are tens of really good engineering departments where everything is properly CI?CD, automated, they can scale to thousand of services without skipping a beat... but that's not the reality for thousands of other smaller/less talented shops. So, "moving to serverless" will not just automagically fix all of your problems.

Also - and I'm an infra guy so I'm probably biased - I don't really get all this developer anxiety to outsource infra needs. Yeah if you are 2 devs working on your startup it makes sense, but when you scale up the team/company, even with serverless, you WILL need to dedicate time to infra/operations and do not dedicate it to strictly-business-related code. Having somebody dedicated to this is good for both.

Re: The Serverless Revolution Has Stalled

#498

Post by chriswarbo »

jfoster wrote: post #420
noncoml wrote: post #415

Earlier quoted context omitted.

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

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

We have some already, e.g. RFC3875 and its descendents https://tools.ietf.org/html/rfc3875

Re: The Serverless Revolution Has Stalled

#499

Post by throw7889 »

zelly wrote: post #448
randomsearch wrote: post #406

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…

It's not nuts to run servers. If an application is operating at any scale such that there is a nonstop stream of requests, then it will be cheaper, faster, and more energy-efficient to run a hot server. This follows from thermodynamics. No matter how good the cloud vendor's serverless is, it's always going to be less efficient than a server, unless it doesn't do any setup and teardown (i.e. no longer server less ). I…

We use serverless in a project and our monthly revenue is $6K. It is not true to assert that only people with no revenue are using serverless.

Re: The Serverless Revolution Has Stalled

#500

Post by fragmede »

randomsearch wrote: post #406

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…

Serverless is already here, it's just unevenly distributed. Instead it's called (managed) Kubernetes and yeah, you need a devops team and there's still a bunch of overhead but like you say - the writing's on the wall.
Post reply on HN