3 ms·

> it can’t wait on the database. In that case autoscaling cpus on the requester side makes sense but this is rare. You might be billed for a new CPU for each r

by kcexn 1y ago

> it can’t wait on the database. In that case autoscaling cpus on the requester side makes sense but this is rare. You might be billed for a new CPU for each request, but in practice this may not be how it's implemented by your provider. It may not be any more computationally expensive than Async callbacks you would implement yourself anyway. > Highly disagree. Imagine one of those command line utilities is “ls”. This overreliance on lambdas is akin to adding new Computers to the cluster in order to call ls. If your application needs to walk the files in a directory by name, you don't need to use 'ls' either. You can use standard library routines instead. However, by shipping 'ls' as a separate binary it is now significantly easier to reuse. There isn't a universal best solution. But serverless does have technical merits.

ninetyninenine 1y ago
>You might be billed for a new CPU for each request, but in practice this may not be how it's implemented by your provider. It may not be any more computationally expensive than Async callbacks you would implement yourself anyway. Independent of costs, it's far easier to commit an async callback to your existing code then spin up new infra structure. This isn't just a cost issue. It's 100x simpler to use your existing code to do this. >If your application needs to walk the files in a directory by name, you don't need to use 'ls' either. You can use standard library routines instead. However, by shipping 'ls' as a separate binary it is now significantly easier to reuse. This is just an example of the ludicrousness of provisioning an external CPU to do it. What you are suggesting with a lambda is equal in stupidity. But for your example here, I'm saying we agree that it's stupid to provision an entire CPU to run ls. Where we don't agree is that you think it's fine to provision an entire CPU to wait for another database CPU. >There isn't a universal best solution. But serverless does have technical merits. First off, there is. Don't spin up a CPU and all the related infra to wait for a database when your existing server CAN already do this. There is no trade off here. When a server waits for a lambda that waits for a database it is definitively slower then the server just waiting for the database. To top it off it is also more expensive, and more complicated in infrastructure. Literally. No. Tradeoff. How can you be talking apples vs. organges when one solution is obviously superior? Second I never said serverless doesn't have technical merits. I said using lambdas as task runners along side an existing server to do Database calls has no merit. It's totally fine to use lambdas to do CPU intensive operations. That would be the point of a lambda right? That's why lambdas exist? If you don't have a server and you want to use "serverless architecture" this makes sense. Use the CPU to do computations.... don't use the CPU to wait on another CPU (the database) to do computations. That's kind of wtf?? I'll grant you that for "serverless architecture" at the very least you need to provision a CPU create the query in the first place. This makes sense. But if you already have some fargate server or ec2 instance.... why?? I can only assume that you are responsible for some major architectural decision where a server spins up a lambda to wait for the lambda, while the lambda waits for the database. Basically by being responsible for something that uses lambdas entirely incorrectly you become too biased to admit that something is obviously wrong. Literally you can't argue with the absurdity of spending more effort to provision and pay for additional CPUs to wait for the database when your existing server already can do the waiting. Spinning up more computer power to only pass off the actual computing action to a database? How many times have I repeated that this is absurd?

by kcexn 1y ago

ninetyninenine 1y ago

>You might be billed for a new CPU for each request, but in practice this may not be how it's implemented by your provider. It may not be any more computationally expensive than Async callbacks you would implement yourself anyway. Independent of costs, it's far easier to commit an async callback to your existing code then spin up new infra structure. This isn't just a cost issue. It's 100x simpler to use your existing code to do this. >If your application needs to walk the files in a directory by name, you don't need to use 'ls' either. You can use standard library routines instead. However, by shipping 'ls' as a separate binary it is now significantly easier to reuse. This is just an example of the ludicrousness of provisioning an external CPU to do it. What you are suggesting with a lambda is equal in stupidity. But for your example here, I'm saying we agree that it's stupid to provision an entire CPU to run ls. Where we don't agree is that you think it's fine to provision an entire CPU to wait for another database CPU. >There isn't a universal best solution. But serverless does have technical merits. First off, there is. Don't spin up a CPU and all the related infra to wait for a database when your existing server CAN already do this. There is no trade off here. When a server waits for a lambda that waits for a database it is definitively slower then the server just waiting for the database. To top it off it is also more expensive, and more complicated in infrastructure. Literally. No. Tradeoff. How can you be talking apples vs. organges when one solution is obviously superior? Second I never said serverless doesn't have technical merits. I said using lambdas as task runners along side an existing server to do Database calls has no merit. It's totally fine to use lambdas to do CPU intensive operations. That would be the point of a lambda right? That's why lambdas exist? If you don't have a server and you want to use "serverless architecture" this makes sense. Use the CPU to do computations.... don't use the CPU to wait on another CPU (the database) to do computations. That's kind of wtf?? I'll grant you that for "serverless architecture" at the very least you need to provision a CPU create the query in the first place. This makes sense. But if you already have some fargate server or ec2 instance.... why?? I can only assume that you are responsible for some major architectural decision where a server spins up a lambda to wait for the lambda, while the lambda waits for the database. Basically by being responsible for something that uses lambdas entirely incorrectly you become too biased to admit that something is obviously wrong. Literally you can't argue with the absurdity of spending more effort to provision and pay for additional CPUs to wait for the database when your existing server already can do the waiting. Spinning up more computer power to only pass off the actual computing action to a database? How many times have I repeated that this is absurd?