7 ms·

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 sha

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.

ryanmarsh 6y ago
This is why Serverless will be huge in enterprise IT. You just described 90% of workloads.
viraptor 6y ago
I use that a lot. There's the joke lambda spackle sticker (https://www.thecloudpod.net/product/lambda-spackle-sticker/ https://www.thecloudpod.net/product/lambda-spackle-sticker/) but that's exactly the great use case.
- jbrodley 6y ago
  Thanks for mentioning our Lambda Spackle sticker. :-) Just throw a little lambda at all your op problems.
  - jacques_chester 6y ago
    I called it "dabs of glue", usually in the context of warning against going crazy with the glue gun.
superfrank 6y ago
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).
SahAssar 6y ago
> 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?
2ion 6y ago
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.
RedShift1 6y ago
I use Node-RED for this. Cheap and very flexible.

ryanmarsh 6y ago

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

viraptor 6y ago

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

jbrodley 6y ago
Thanks for mentioning our Lambda Spackle sticker. :-) Just throw a little lambda at all your op problems.
- jacques_chester 6y ago
  I called it "dabs of glue", usually in the context of warning against going crazy with the glue gun.

superfrank 6y ago

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

SahAssar 6y ago

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

2ion 6y ago

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.

RedShift1 6y ago

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