4 ms·

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 1

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

deleted 6y ago
[deleted]
Aeolun 6y ago
> 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.
- chrisweekly 6y ago
  multiple seconds?? what platform?
  - Aeolun 6y ago
    AWS, inside a VPN. To be fair, it used to be 10ish seconds, and they improved it quite a bit.
  - rezonant 6y ago
    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.
- saimiam 6y ago
  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).
  - Aeolun 6y ago
    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.
    - jacques_chester 6y ago
      My view is that logic shouldn't be retrieving or storing data. Separation of Church and state, so to speak.
    - saimiam 6y ago
      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?
      - ec109685 6y ago
        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.
- rangoon626 6y ago
  I believe there’s a setting in RDS to enable connection pooling.
- lmm 6y ago
  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.
ashtonkem 6y ago
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.

deleted 6y ago

[deleted]

Aeolun 6y ago

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

chrisweekly 6y ago
multiple seconds?? what platform?
- Aeolun 6y ago
  AWS, inside a VPN. To be fair, it used to be 10ish seconds, and they improved it quite a bit.
- rezonant 6y ago
  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.
saimiam 6y ago
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).
- Aeolun 6y ago
  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.
  - jacques_chester 6y ago
    My view is that logic shouldn't be retrieving or storing data. Separation of Church and state, so to speak.
  - saimiam 6y ago
    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?
    - ec109685 6y ago
      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.
rangoon626 6y ago
I believe there’s a setting in RDS to enable connection pooling.
lmm 6y ago
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.

ashtonkem 6y ago

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.