4 ms·

Honest enshittification is good but rare. Like a cloud telling you what specific CPU SKU is in the hardware (not just 1 vcore). They should say what you are pa

Honest enshittification is good but rare. Like a cloud telling you what specific CPU SKU is in the hardware (not just 1 vcore). They should say what you are paying for in terms of technicals, either spill the beans on the architecture or have some SLAs on how good the thing is.

opportune 3y ago
I work in cloud-land, the problem with exposing every little technical detail is that 1. part of the point of purchasing a cloud product is to abstract that away 2. coding to the implementation instead of the API creates huge headaches for everybody because there are often good reasons (make things more efficient) to change the implementation 3. sadly, there are “features” such as overcommit which you don’t want to know about as a customer. While some of those are anti-customer on their face, the “we shouldn’t commit to implementation details and instead just to our API/feature surface” may seem anti-customer while actually making things much better for customers. When implementations are supported in perpetuity development grinds to a standstill. Even overcommit ends up helping customers - cloud companies can offer lower sticker prices. In the case of both regular Public cloud and OpenAI - if you need stability beyond publicly supported APIs you are probably not a good fit as a customer and should instead find a company willing to commit to lower level implementations (eg bare metal, truly major/minor versioned software) or roll-your-own.
- quickthrower2 3y ago
  That is fine, then you need some kinds of comparable metric that stays the same over time. FLOPS maybe? Ideally the same across clouds, or more likely cloud-specific. Or even re pin it every 5 years. E.g. a 2020-CPU, 2025-CPU etc. We need a "horse power" for the cloud I guess!

4 ms·

Honest enshittification is good but rare. Like a cloud telling you what specific CPU SKU is in the hardware (not just 1 vcore). They should say what you are pa

by quickthrower2 3y ago

opportune 3y ago
I work in cloud-land, the problem with exposing every little technical detail is that 1. part of the point of purchasing a cloud product is to abstract that away 2. coding to the implementation instead of the API creates huge headaches for everybody because there are often good reasons (make things more efficient) to change the implementation 3. sadly, there are “features” such as overcommit which you don’t want to know about as a customer. While some of those are anti-customer on their face, the “we shouldn’t commit to implementation details and instead just to our API/feature surface” may seem anti-customer while actually making things much better for customers. When implementations are supported in perpetuity development grinds to a standstill. Even overcommit ends up helping customers - cloud companies can offer lower sticker prices. In the case of both regular Public cloud and OpenAI - if you need stability beyond publicly supported APIs you are probably not a good fit as a customer and should instead find a company willing to commit to lower level implementations (eg bare metal, truly major/minor versioned software) or roll-your-own.
- quickthrower2 3y ago
  That is fine, then you need some kinds of comparable metric that stays the same over time. FLOPS maybe? Ideally the same across clouds, or more likely cloud-specific. Or even re pin it every 5 years. E.g. a 2020-CPU, 2025-CPU etc. We need a "horse power" for the cloud I guess!