5 ms·

The trendy (meaning both that it is hyped and that it follows the trajectory of the trend you identified) answer is serverless/scale-to-zero (Lambda, Cloud Run,

The trendy (meaning both that it is hyped and that it follows the trajectory of the trend you identified) answer is serverless/scale-to-zero (Lambda, Cloud Run, etc.). That said, Lambda has been out for a while and seems to have avoided taking over the world. Generic vCPU-hours are so cheap now though that it isn't compelling from a a cost perspective (serverless will either cost you more at the high end of the scale, or else save you a few bucks a month on your idle instances at the low end). Also, the developer experience isn't as good yet IMO. Thinks like LocalStack help, but it's still not natural-feeling to deploy a big application this way. (scale-to-zero it's great for small side projects though -- I have a few apps in Cloud Run that cost me like a nickel a month, a few dollars if I have a good month in terms of traffic).

ghaff 3y ago
And serverless isn't even all that distinct from containers, see e.g. Knative. You're mostly still doing stuff around a Unix process model.
ashrafulla 3y ago
This is a fantastic take (seriously, no sarcasm here). I'll add that serverless platforms have not actually shown the ability to scale _efficiently_. It feels like every software architect has been talking about the 2023 March post^ from Amazon Prime Video on migrating from serverless to serverful. That is a direct response to the inability of serverless to scale because under the hood it is serverful but limited. Besides AWS Lambda and Google Cloud Run others have tried OpenFaaS and Cloudflare Workers. I think only Cloudflare Workers have "scaled" but that's because it's limited scale for each service at the edge with lots of edge devices. I do not know if this is solvable: a permanent service with light autoscaling handles even inconsistent load so well and reduces operational complexity so much that I don't know if serverless will be anything more than toys. It is no coincidence that AWS Lambda's first language was a frontend language* (Node.js). Those use cases have low to moderate scale (because after that you split frontend and backend). ^Amazon Prime Video post: https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90 https://www.primevideotech.com/video-streaming/scaling-up-th.... *First mention of AWS Lambda languages in AWS Compute Blog only mentioned nodejs: https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/ https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...
- matus_congrady 3y ago
  I agree with some of the points you've mentioned, but I also think that there definitely are great use-cases for AWS Lambda, and that they are (especially when using a good deployment tool) a great option for many different types of applications. The biggest problem is that the computing model, or the architecture that is commonly required for this sort of apps (event-driven and asynchronous) is hard to develop, manage and reason about (especially with the async-lambda integrations that by default retry their work if they fail). This means that you need to think about them and architect them in a way that makes them idempotent. If you configure everything properly, event-driven, AWS Lambda-based apps can be extremely useful. I just don't believe that the complexity required to add them to your application is worth the complexity that needs to be added to your app to make it all work. What I wanted to say is that Lambda functions have their use-cases, and that if used reasonably, they can heavily simplify the application that they are used within. Our product (https://stacktape.com https://stacktape.com, disclosure: Im a founder), makes it easy to deploy both container-based (ECS Fargate and ECS EC2) apps, and lambda functions, with almost no changes in the configuration). This allows our users to always choose the right technology/computing model for the use-case they are working on.

ghaff 3y ago

And serverless isn't even all that distinct from containers, see e.g. Knative. You're mostly still doing stuff around a Unix process model.

ashrafulla 3y ago

This is a fantastic take (seriously, no sarcasm here). I'll add that serverless platforms have not actually shown the ability to scale _efficiently_. It feels like every software architect has been talking about the 2023 March post^ from Amazon Prime Video on migrating from serverless to serverful. That is a direct response to the inability of serverless to scale because under the hood it is serverful but limited. Besides AWS Lambda and Google Cloud Run others have tried OpenFaaS and Cloudflare Workers. I think only Cloudflare Workers have "scaled" but that's because it's limited scale for each service at the edge with lots of edge devices. I do not know if this is solvable: a permanent service with light autoscaling handles even inconsistent load so well and reduces operational complexity so much that I don't know if serverless will be anything more than toys. It is no coincidence that AWS Lambda's first language was a frontend language* (Node.js). Those use cases have low to moderate scale (because after that you split frontend and backend). ^Amazon Prime Video post: https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90 https://www.primevideotech.com/video-streaming/scaling-up-th.... *First mention of AWS Lambda languages in AWS Compute Blog only mentioned nodejs: https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/ https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...

matus_congrady 3y ago
I agree with some of the points you've mentioned, but I also think that there definitely are great use-cases for AWS Lambda, and that they are (especially when using a good deployment tool) a great option for many different types of applications. The biggest problem is that the computing model, or the architecture that is commonly required for this sort of apps (event-driven and asynchronous) is hard to develop, manage and reason about (especially with the async-lambda integrations that by default retry their work if they fail). This means that you need to think about them and architect them in a way that makes them idempotent. If you configure everything properly, event-driven, AWS Lambda-based apps can be extremely useful. I just don't believe that the complexity required to add them to your application is worth the complexity that needs to be added to your app to make it all work. What I wanted to say is that Lambda functions have their use-cases, and that if used reasonably, they can heavily simplify the application that they are used within. Our product (https://stacktape.com https://stacktape.com, disclosure: Im a founder), makes it easy to deploy both container-based (ECS Fargate and ECS EC2) apps, and lambda functions, with almost no changes in the configuration). This allows our users to always choose the right technology/computing model for the use-case they are working on.