4 ms·
Do people really prefer to see vCPU pricing in per-second increments? Is this useful for any person? Presumably no information is conveyed by the first 4 signi
by runako 6mo ago
Do people really prefer to see vCPU pricing in per-second increments? Is this useful for any person?
Presumably no information is conveyed by the first 4 significant digits. And can anybody compare this pricing to e.g. AWS or Google Cloud? I have never known my compute cost to second resolution, so I'd need to do calculations to even ballpark this.
Suggestion: Don't obfuscate the price, just remove it. Clearly you don't really want casual browsers to know how much you're charging[1]. Which: fine, this is the current trend in tech. So just remove the pricing and put your calendar link there as a CTA instead. Be classy. Don't play games with your audience.
1 - anybody who plugs this into a calculator will a) understand why you don't show monthly pricing and b) think this is screamingly expensive. Which reinforces my recommendation to just replace the price with a CTA and your calendar link.
- Glemllksdf 6mo agoFor CI/CD Jobs? Yes. For a VM running for a month? No. For highly scalable batch tasks? Yes. For small experiments? Yes. For Full e2e tests creating a full env and killing it a minute later? yes.
- runako 6mo agoOne of the info blocks is headed "Persistent VMs" and suggests "Always-on VMs..." They are not pitching this for any of the "yes" tasks you identified.
- rcxdude 6mo agoThere is a useful signal in such a way of indicating pricing: it signals that the billing is done at such a resolution, which, for some workloads, can make a difference compared to say, a minimum increment of an hour or a day. Though I would prefer that you can see the conversion to longer timescales on the page itself.
- runako 6mo agoI thought about that, which is indeed what AWS Lambda does, but one of the pitches here is "Always-on VMs," which is not what Lambda is selling.