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

361–370 of 670 posts

Re: The Serverless Revolution Has Stalled

#361

Post by ec109685 »

saimiam wrote: post #325
Aeolun wrote: post #158

Earlier quoted context omitted.

Yeah, they can use the same connection for a while. The problem is that 1000 lambdas cannot use 50 connections while waiting their turn. Each of them wants a connection to the DB server. Now if you somehow get a spike of requests to some endpoint that goes over your DB connection limit, suddenly all your newly scaled functions fail because they cannot get a connection to the database. AWS added a service for RDS to d…

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.

Re: The Serverless Revolution Has Stalled

#362

Post by hendry »

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…

https://github.com/apex/up is a godsend for deploying on AWS Lambda for me. By the same author as Express JS, TJ Holowaychuk.

TJ abstracts the Lambda nonsense so you just get to use a standard HTTP res/resp interface. https://github.com/apex/up-examples/

Deployment iterations for me in Singapore can be as low as 2s, but tbh I use https://github.com/codegangsta/gin locally for development iterations.

Re: The Serverless Revolution Has Stalled

#363

Post by [deleted] »

maxcbc wrote: post #358

A fifth reason it has stalled, cost. For constantly running applications it can be cheaper just to run a server. This fact has been used to avoid migrating to serverless by a lot of orgs i’ve worked with, even when it doesn’t apply to their use case.

[deleted]

Re: The Serverless Revolution Has Stalled

#364

Post by marmshallow »

x86_64Ubuntu wrote: post #355
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…

Is anyone else worried about the proliferation of disjoint processes that people can whip up using Serverless? At least with a monolith, you've got a relatively coherent grouped together codebase. But with Serverless, you can have some lambda that is infinitely important, but not documented or well known to anyone else in the org.

I think it all depends on how searchable and generally well-maintained the codebase is. Having some obscure critical function hidden in a monolith is totally possible too.

Re: The Serverless Revolution Has Stalled

#366

Post by vanviegen »

nurettin wrote: post #347
t0astbread wrote: post #327

Earlier quoted context omitted.

A middle ground between both would be ideal. Does AWS offer settings to cap your spendings? (I googled and found AWS Budgets but it seems to be only an alerting system, not a cap.)

AFAIK at the moment there is no cap. It's pretty much like going long on a crashing market. However, you can later have a bunch of emails and tweets basically begging to be reimbursed and it works most of the time.

Going long will limit your losses to the amount invested. The point is that your AWS bill has no such limit whatsoever.

Re: The Serverless Revolution Has Stalled

#367

Post by com2kid »

Latty wrote: post #63
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…

Yeah, I took a look at using a serverless framework for a hobby project, and it was just a real pain to get started at all, let alone develop a whole application in. I tried AWS, and then IBM's offering which is based on an open source (Apache OpenWhisk) project, thinking that it might be easier to work with, but that was also a pain. I just lost interest as I was only checking it out. For something constantly market…

> Yeah, I took a look at using a serverless framework for a hobby project, and it was just a real pain to get started at all, let alone develop a whole application in.

Look into Firebase functions. Drop some JS in a folder, export them from an index.js file and you have yourself some endpoints.

> exports.helloWorld = functions.https.onRequest((request, response) => { response.send("Hello from Firebase!"); });

The amount of work AWS has put in front of Lambdas confuses me. Firebase does it right. You can go from "never having written a REST endpoint" to "real code" in less than 20 minutes. New endpoints can be created as fast as you can export functions from an index.js file.

Re: The Serverless Revolution Has Stalled

#368

Post by vanviegen »

klodolph wrote: post #344
franciscop wrote: post #282

Earlier quoted context omitted.

99.99% of the websites out there don't need 99.99% uptime (from a business point of view)

Once you get to 99.9% uptime you’re still less than 1 hour per month. I used to run apps for companies at work and it was standard operating procedure to have two app servers + load balancer for upgrades. Drain a server, upgrade it, boot it, check that it works, let it accept traffic. Repeat once more. Done. It may be true that most businesses don’t need the uptime, but I’d say it’s usually easier to give them high a…

But where does the data sit? Would you be using some fancy multi-master synchronous replication for that, or is there a database server behind it?

Re: The Serverless Revolution Has Stalled

#369

Post by com2kid »

pier25 wrote: post #125
spcebar wrote: post #66

Earlier quoted context omitted.

I found firebase functions pretty easy and painless. Worth a look.

Deploying is super slow. Usually it takes a minute or two, which is already quite long, but sometimes something goes wrong and then you can't redeploy immediately. You have to wait a couple of minutes before being able to redeploy. To be fair, Firebase recently released a local development tool which alleviates the need to deploy on every change, but I haven't used it yet. https://firebase.google.com/docs/emulator-su…

The emulators have been around for years, just not well documented.

Super useful though!

Re: The Serverless Revolution Has Stalled

#370

Post by rmdashrfstar »

tomc1985 wrote: post #332
crehn wrote: post #330

Earlier quoted context omitted.

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.

Then maybe they should learn how to deal with it

This is a peak HN comment right here.
Post reply on HN