Hacker News Reader

Comment by fennecfoxen | Hacker News Reader

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 receive a webhook a few times a day and send a Slack message to your team? Perfect.

Not the core of your app, but a tool of great utility. On the other hand, this isn't exactly the Serverless Revolution either.

View on HN

I'd add on top of that, that it provides even more value when volume is usually low and sparse, but unpredictable.

If you have a server that can handle up to 100 requests at a time, but you're only getting one or two a day, you could probably save money by switching to serverless. On the flip side though, you're also a bit screwed if 1000 requests all come in at once, since, even if you have some autoscaling solution, it probably won't be able to bring new servers up in time. Serverless provides a solution for that case as well, since you have almost unlimited resources.

But yeah, serverless is a tool for solving a certain set of problems. This idea of the "Serverless Revolution" was kind of silly from the start

> Serverless provides a solution for that case as well, since you have almost unlimited resources.

Not really, since it takes a few seconds to spin up all the serverless instances, so your app response becomes really erratic.

Then you need some magic to deal with database connections from 1000 lambda functions. All of them use their own since they cannot pool.

multiple seconds??

what platform?

AWS, inside a VPN. To be fair, it used to be 10ish seconds, and they improved it quite a bit.

All the platforms (GCP, Lambda, Azure Functions) have fairly long cold start times, but some platforms let you essentially pay for one or more cold start instances that are always on (I saw Azure had this, others are sure to follow). According to the article this "undermines" the model, but I disagree, as instance start time measured in the seconds is crazy difficult to achieve when doing VM automation. Typically it'll take 5m to get a fresh VM into the load balancer during scaling, could be as low as 1-2m if you do it just right. Buying one or two instances and then having the rest of the requests billed per invocation with a fast scale up time is very appealing.

We happily connection pool using sequelize by leveraging the fact that lambdas run in reusable containers.

If the next lambda invocation happens within minutes of the previous one ending, you can carry forward a db connection from the older lambda, no magic needed. Just place your db connection object in global scope (nodejs).

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 deal with this, but it all just feels like a big kludge to deal with a problem that shouldn’t have to exist in the first place.

My view is that logic shouldn't be retrieving or storing data. Separation of Church and state, so to speak.

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 known about the need for connection pools and connection reuse from before AWS was a thing, no?

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.

Lambda does hold onto it in order improve response time. It connects to the database in a handler outside the context of a request, so you do hold onto N connections persistently (at least until the lambda scales down).

With a connection pool, you don’t need to hold onto a connection longer than necessary, but you are right that you could implement it in such a way that you hold it for life of the request.

I believe there’s a setting in RDS to enable connection pooling.

I've never understood why people who would never dream of using a single-instance application server are ok with using a single-instance datastore. Of course your datastore needs to autoscale just like your application does. Duh.

That only works if you’re relatively latency tolerant. Serverless systems currently suffer badly from cold start issues, particularly when large spikes arise. This can be solved, but it involves enough silliness that paying for a VM is probably cheaper once you factor in engineering time.

Exactly our use case, esp. for things that are outside of k8s, for example, standard tasks that every cloud account of ours needs to perform (they are heavily segmented due to regulations) and developers or k8s ops do not get to touch. Almost all are on events or timers. Cronjobs without infrastructure to worry about are nice. Basically I wrote some of this stuff 5 years ago and didn't have to look at it since; it just runs.

I use that a lot. There's the joke lambda spackle sticker (https://www.thecloudpod.net/product/lambda-spackle-sticker/) but that's exactly the great use case.

Thanks for mentioning our Lambda Spackle sticker. :-) Just throw a little lambda at all your op problems.

I called it "dabs of glue", usually in the context of warning against going crazy with the glue gun.

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

I use Node-RED for this. Cheap and very flexible.

This is why Serverless will be huge in enterprise IT. You just described 90% of workloads.

Reply on news.ycombinator.com