3 ms·

I like how some of the services are very cheap (S3, Lambda), but then at some point you end up using a bunch of other complements, one of which is very expensiv

I like how some of the services are very cheap (S3, Lambda), but then at some point you end up using a bunch of other complements, one of which is very expensive and makes the profit. At which point, as you say, the cost and complexity of a move is huge so you are stuck with a recurring bill. Another interesting thing is that you pay for 100% of a VM virtual CPU even if it is only utilised 40%, but the cloud is selling your other 60% capacity to another user. They have no incentive to charge you “based on CPU usage” for VM’s that are always on, even though it is possible. I think this would be a better approach than Lambda - to dynamically add more cores to your OS as you need them.

sofixa 5y ago
> Another interesting thing is that you pay for 100% of a VM virtual CPU even if it is only utilised 40%, but the cloud is selling your other 60% capacity to another user AWS don't overprovision CPUs outside of the t instance range, in which you get vCPU credits, not full vCPUs. If you rent an apartment but don't use it, is it the landlord's fault you don't? The landlord can't rent the same appartement to another client. Especially on AWS/GCP/Azure, where there are many alternatives ( Lambda, Google Cloud Run, Google App Engine, etc.) where you pay per compute used.
- justsomeuser 5y ago
  At the hyper visor level, I was under the impression that many VM’s are scheduled onto the same hardware CPU core. One hardware core can be running 5 VMs at 20% capacity, and each VM owner will pay for 100% of their CPU capacity right? So in this case the landlord is renting your unused apartment to other customers then evicting them faster than you can open the door. My point is cloud is benefiting from that ability and not passing it on the customers, which they could.
  - sofixa 5y ago
    Your impression is correct for VPS-style "clouds", like Digital Ocean and co. Its fully wrong for AWS, where a vCPU you rent == physical core/thread.
    - justsomeuser 5y ago
      How do you know this implementation detail?
    - trtechhn 5y ago
      That statement is counter to how "vCPUs" related to "CPU" since early cloud implementation. AWS not taking advantage of the much more efficient "oversubscription ratio" versus thread pinning - unlikely. Are you certain of this statement?

sofixa 5y ago

> Another interesting thing is that you pay for 100% of a VM virtual CPU even if it is only utilised 40%, but the cloud is selling your other 60% capacity to another user AWS don't overprovision CPUs outside of the t instance range, in which you get vCPU credits, not full vCPUs. If you rent an apartment but don't use it, is it the landlord's fault you don't? The landlord can't rent the same appartement to another client. Especially on AWS/GCP/Azure, where there are many alternatives ( Lambda, Google Cloud Run, Google App Engine, etc.) where you pay per compute used.

justsomeuser 5y ago
At the hyper visor level, I was under the impression that many VM’s are scheduled onto the same hardware CPU core. One hardware core can be running 5 VMs at 20% capacity, and each VM owner will pay for 100% of their CPU capacity right? So in this case the landlord is renting your unused apartment to other customers then evicting them faster than you can open the door. My point is cloud is benefiting from that ability and not passing it on the customers, which they could.
- sofixa 5y ago
  Your impression is correct for VPS-style "clouds", like Digital Ocean and co. Its fully wrong for AWS, where a vCPU you rent == physical core/thread.
  - justsomeuser 5y ago
    How do you know this implementation detail?
  - trtechhn 5y ago
    That statement is counter to how "vCPUs" related to "CPU" since early cloud implementation. AWS not taking advantage of the much more efficient "oversubscription ratio" versus thread pinning - unlikely. Are you certain of this statement?