4 ms·

Ok you're a perfect example. I think it's truly younger programmers who don't get it. Why wait for an aws lambda to wait for a database when you can just wait

Ok you're a perfect example. I think it's truly younger programmers who don't get it. Why wait for an aws lambda to wait for a database when you can just wait for the database yourself? You spin up an entire CPU just to ask it to wait for something when you can just fire off a coroutine. Spinning up CPUs are for spinning up new computational resources. It's pointless to ask it to wait for shit. It's like asking someone to wait in line for you while you stand next to him waiting for him.

bigyabai 2y ago
Because server providers charge by the hour, and I'm hired to replace expensive solutions.
- ninetyninenine 2y ago
  But the server already exists. You are already paying for it's existence as it handles other things. This is common if you worked for an IT company. In short: The server is the origin of the task. By definition the task doesn't exist without the origin/trigger. Why spend extra on a lambda? I think you're lost. Especially if you built architecture like this where servers wait for lambdas that just wait for database calls. (FYI waiting time is slightly longer this way, cost is slightly more expensive, and architecture becomes unnecessarily complex) Literally first reply is someone who thinks a lambda is the right tool. I wasn't sure how bad it was until this young man replied.
codingdave 2y ago
Do you know that your server will always have the extra capacity to wait? If so, you are probably correct. If you do not definitively know that, than your younger co-worker's solution will scale better. I don't think anyone can generically say one answer is better than the other without knowing more information about your infrastructure. It sounds like they do not respect your take on it, but you aren't respecting theirs, either.
- ninetyninenine 2y ago
  We're a small company. Definitely significantly less then 10k concurrent connections. I would say like 100 concurrent connections at most, 20 concurrent connections on average. Even at 10k concurrent connections you don't have to spin up a lambda. There is almost no case where you do unless you are using that lambda CPU to do blocking computations. If your server is your typical crud server that hits a database, your database will be overwhelmed before your server gets hit to the point where it can't even wait. It's not about respect, I don't mind the disrespect. It's more about how they're wrong and they don't realize it and this over engineering is pervasive in the industry. I don't think you understanding how cheap it is on the CPU for a server to wait for an external IO call.
  - codingdave 2y ago
    > It's not about respect, I don't mind the disrespect. But do they mind? Because so far you are saying anyone who doesn't agree with you doesn't understand. Sounds like while you might not mind being disrespected, you fail to realize that other people do mind. You also clearly have an over-sized server if you think 10K concurrent connections can be covered on it. If that is true, you could save a heap of money by downgrading that server and going to lambdas. The more you defend your position, the less tenable it becomes.
    - ninetyninenine 2y ago
      >But do they mind? Because so far you are saying anyone who doesn't agree with you doesn't understand. Sounds like while you might not mind being disrespected, you fail to realize that other people do mind. Is that disrespect or is that just sensitivity? From my POV this is fact. Like 1 + 1 = 2. I'm stating that. Or should I be inclusive and say that 1 + 1 maybe equals 2 but I respect your alternative opinion? If I believe in something as a fact. I should be able to talk about it as a fact and talk about it as if the other person is wrong. You have that right as well. Same with my young coworker. They probably do mind. But I feel that's just life. He called my way of doing it using "assembly language" even, and I let it go. If someone is wrong, we shouldn't be afraid to slightly offend them and tell them they are wrong. That goes both ways. I don't want to live in society where we have to dance around everyone's feelings even when they're utterly wrong and borderline delusional. >You also clearly have an over-sized server if you think 10K concurrent connections can be covered on it. If that is true, you could save a heap of money by downgrading that server and going to lambdas. The more you defend your position, the less tenable it becomes. This is not true. Your laptop on a 10 year old intel chip can handle 10k concurrent connections. Some guy pushed it up to a million here: https://unetworkingab.medium.com/millions-of-active-websockets-with-node-js-7dc575746a01 https://unetworkingab.medium.com/millions-of-active-websocke... The lambda architecture doesn't work for our case because our server maintains long running websocket connections. We just need async non blocking tasks. So I'm saying, launch a concurrent coroutine (aka go routine) and call it a day. I think you're not aware of how much concurrency modern servers can handle. Back in the days of LAMP this would be a problem. But not anymore.
kcexn 2y ago
There are technical benefits to using serverless functions. As mentioned, there is autoscaling and the delegation of infrastructure management to a vendor. But you also create clearer language/runtime independent code encapsulation. This means that you can reuse this code for other purposes in the future, even projects that use different programming languages. It's a little bit like the difference between writing a monolithic piece of software and writing a bunch of command-line utilities and scripting them together using the shell.
- ninetyninenine 2y ago
  > As mentioned, there is autoscaling Why would you autoscale more computation to wait for the database. Let’s be clear here. The database is the thing doing MORE computations. It makes more sense to autoscale the thing carrying out the task. It makes zero sense to autoscale the thing simply waiting for the task. The only thing where I see this making sense is if your database already has massive compute resources allocated to it and your server has so little resources it can’t wait on the database. In that case autoscaling cpus on the requester side makes sense but this is rare. It’s so rare it’s minuscule that you’ll have more than 10k concurrent connections. >But you also create clearer language/runtime independent code encapsulation. I don’t understand why a folder isn’t clear? Why must it be an entirely new repo and a new deploy process and an entirely new allocation of cpus to wait for the database? Guys. You want to organize your code? Consider folders. Don’t use new repos. Don’t use new deploy processes. Infrastructure exists to scale not to organize code. Adding new infrastructure makes code complexity, organization and accessibility worse while increasing scalability. Don’t use infra to organize code. Use infrastructure to scale performance. That’s a rule of thumb. There are exceptions but those exceptions are rare af. You want other services to touch this function? You can then make it an http route as well: So the server can trigger a coroutine in the handler OR the handler itself (which is also a coroutine) is the database call that reacts to other services calling the http route. Same effect as a lambda. >It's a little bit like the difference between writing a monolithic piece of software and writing a bunch of command-line utilities and scripting them together using the shell. 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.

bigyabai 2y ago

Because server providers charge by the hour, and I'm hired to replace expensive solutions.

ninetyninenine 2y ago
But the server already exists. You are already paying for it's existence as it handles other things. This is common if you worked for an IT company. In short: The server is the origin of the task. By definition the task doesn't exist without the origin/trigger. Why spend extra on a lambda? I think you're lost. Especially if you built architecture like this where servers wait for lambdas that just wait for database calls. (FYI waiting time is slightly longer this way, cost is slightly more expensive, and architecture becomes unnecessarily complex) Literally first reply is someone who thinks a lambda is the right tool. I wasn't sure how bad it was until this young man replied.

codingdave 2y ago

Do you know that your server will always have the extra capacity to wait? If so, you are probably correct. If you do not definitively know that, than your younger co-worker's solution will scale better. I don't think anyone can generically say one answer is better than the other without knowing more information about your infrastructure. It sounds like they do not respect your take on it, but you aren't respecting theirs, either.

ninetyninenine 2y ago
We're a small company. Definitely significantly less then 10k concurrent connections. I would say like 100 concurrent connections at most, 20 concurrent connections on average. Even at 10k concurrent connections you don't have to spin up a lambda. There is almost no case where you do unless you are using that lambda CPU to do blocking computations. If your server is your typical crud server that hits a database, your database will be overwhelmed before your server gets hit to the point where it can't even wait. It's not about respect, I don't mind the disrespect. It's more about how they're wrong and they don't realize it and this over engineering is pervasive in the industry. I don't think you understanding how cheap it is on the CPU for a server to wait for an external IO call.
- codingdave 2y ago
  > It's not about respect, I don't mind the disrespect. But do they mind? Because so far you are saying anyone who doesn't agree with you doesn't understand. Sounds like while you might not mind being disrespected, you fail to realize that other people do mind. You also clearly have an over-sized server if you think 10K concurrent connections can be covered on it. If that is true, you could save a heap of money by downgrading that server and going to lambdas. The more you defend your position, the less tenable it becomes.
  - ninetyninenine 2y ago
    >But do they mind? Because so far you are saying anyone who doesn't agree with you doesn't understand. Sounds like while you might not mind being disrespected, you fail to realize that other people do mind. Is that disrespect or is that just sensitivity? From my POV this is fact. Like 1 + 1 = 2. I'm stating that. Or should I be inclusive and say that 1 + 1 maybe equals 2 but I respect your alternative opinion? If I believe in something as a fact. I should be able to talk about it as a fact and talk about it as if the other person is wrong. You have that right as well. Same with my young coworker. They probably do mind. But I feel that's just life. He called my way of doing it using "assembly language" even, and I let it go. If someone is wrong, we shouldn't be afraid to slightly offend them and tell them they are wrong. That goes both ways. I don't want to live in society where we have to dance around everyone's feelings even when they're utterly wrong and borderline delusional. >You also clearly have an over-sized server if you think 10K concurrent connections can be covered on it. If that is true, you could save a heap of money by downgrading that server and going to lambdas. The more you defend your position, the less tenable it becomes. This is not true. Your laptop on a 10 year old intel chip can handle 10k concurrent connections. Some guy pushed it up to a million here: https://unetworkingab.medium.com/millions-of-active-websockets-with-node-js-7dc575746a01 https://unetworkingab.medium.com/millions-of-active-websocke... The lambda architecture doesn't work for our case because our server maintains long running websocket connections. We just need async non blocking tasks. So I'm saying, launch a concurrent coroutine (aka go routine) and call it a day. I think you're not aware of how much concurrency modern servers can handle. Back in the days of LAMP this would be a problem. But not anymore.

kcexn 2y ago

There are technical benefits to using serverless functions. As mentioned, there is autoscaling and the delegation of infrastructure management to a vendor. But you also create clearer language/runtime independent code encapsulation. This means that you can reuse this code for other purposes in the future, even projects that use different programming languages. It's a little bit like the difference between writing a monolithic piece of software and writing a bunch of command-line utilities and scripting them together using the shell.

ninetyninenine 2y ago
> As mentioned, there is autoscaling Why would you autoscale more computation to wait for the database. Let’s be clear here. The database is the thing doing MORE computations. It makes more sense to autoscale the thing carrying out the task. It makes zero sense to autoscale the thing simply waiting for the task. The only thing where I see this making sense is if your database already has massive compute resources allocated to it and your server has so little resources it can’t wait on the database. In that case autoscaling cpus on the requester side makes sense but this is rare. It’s so rare it’s minuscule that you’ll have more than 10k concurrent connections. >But you also create clearer language/runtime independent code encapsulation. I don’t understand why a folder isn’t clear? Why must it be an entirely new repo and a new deploy process and an entirely new allocation of cpus to wait for the database? Guys. You want to organize your code? Consider folders. Don’t use new repos. Don’t use new deploy processes. Infrastructure exists to scale not to organize code. Adding new infrastructure makes code complexity, organization and accessibility worse while increasing scalability. Don’t use infra to organize code. Use infrastructure to scale performance. That’s a rule of thumb. There are exceptions but those exceptions are rare af. You want other services to touch this function? You can then make it an http route as well: So the server can trigger a coroutine in the handler OR the handler itself (which is also a coroutine) is the database call that reacts to other services calling the http route. Same effect as a lambda. >It's a little bit like the difference between writing a monolithic piece of software and writing a bunch of command-line utilities and scripting them together using the shell. 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.