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.
There 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.
> It couldn't care less about all the distributed system cloud goodness that we are all accustomed to. WordPress runs on servers. It reads and writes files. Managed VMs weren't around when WordPress was created, not speaking of containers and serverless and CDNs and the rest of modern cloud infrastructure.
Yeah, thanks, can you now also give us the downsides?
It means that the author has no idea what they are talking about.
Probably never heard of Kinsta, for example.
We ran a successful network of about 70 wp installs that had peaks of 8.000 concurrent visitors for hours per day already in 2011/2012.
Our sysadmin at the time deployed the whole thing over 2 server clusters behind a wonderful load balancer he fine tuned on OVH.
Total monthly costs: 800€.
That was 14 years ago. So imagine thinking that wordpress is “behind” in 2026 just because it doesn’t subscribe to the deranged cloud subscription culture that has infected the industry.
Wordpress has heaps of technical and non technical issues to solve (especially in governance), but being server-side ain’t one of them.
When you say 8000 concurrent visitors, is that per site or across the 70 installs? And what sorts of sites were they?
Because there's an immense difference when it comes to hosting between a blog/brochure site that is fully cachable and a woocommerce or, worse, social network/LMS/other highly dynamic site.
To be clear though, I'm not advocating for distributed cloud architecture - that sort of stuff is best done on a vertically-scaled server, which can get up to many hundreds of CPUs these days.
They where dynamic publishing sites, so not supercomplicated and absolutely cached to the brim. A big chung of the concurrent visitors (prob like 90%) where on two websites, so two installs.
Ok. Yeah, you could easily have 100k concurrent visitors with that, if the request isn't actually reaching php/WordPress. On e it does, you're down to something like 2-4, maybe 10, requests per cpu core, per second. Depends on the hardware and how the site is configured.
Interestingly, when you're typing in Notion I didn't see any em dashes. Is there some post-processing happening that's converting the hyphens to em dashes? e.g. the following paragraph appeared to have just regular hyphens when you typed on the Loom video:
<p className="text-[17px] leading-[1.75] tracking-[-0.1px]">
The difference is subtle but significant. Apache is a web server — it can host and
run any web application, for example one written in PHP. Whereas WordPress sits a layer
above; in fact it typically runs on Apache. What makes it a better analogy for the
"agentic workload" is what you do with it — or rather, who and how uses it.
</p>
This is great. I've considered doing the same thing. After all, I've always used em dashes in my writing, so I suppose all my blog posts are AI-generated as well.
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.
There 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.
I 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.
For 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.
One 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.
The idea that "agent harness" is the thing people actually want is laughable.
It seems it is the buzzword of the month.
> It couldn't care less about all the distributed system cloud goodness that we are all accustomed to. WordPress runs on servers. It reads and writes files. Managed VMs weren't around when WordPress was created, not speaking of containers and serverless and CDNs and the rest of modern cloud infrastructure.
Yeah, thanks, can you now also give us the downsides?
The fact that author automatically jumps to “distributed system cloud goodness” has me glazed over.
We don’t need a new Wordpress that subscribes to today’s current tech trends.
“It doesn’t scale well” what does that even mean?
It means that the author has no idea what they are talking about. Probably never heard of Kinsta, for example. We ran a successful network of about 70 wp installs that had peaks of 8.000 concurrent visitors for hours per day already in 2011/2012. Our sysadmin at the time deployed the whole thing over 2 server clusters behind a wonderful load balancer he fine tuned on OVH. Total monthly costs: 800€.
That was 14 years ago. So imagine thinking that wordpress is “behind” in 2026 just because it doesn’t subscribe to the deranged cloud subscription culture that has infected the industry.
Wordpress has heaps of technical and non technical issues to solve (especially in governance), but being server-side ain’t one of them.
When you say 8000 concurrent visitors, is that per site or across the 70 installs? And what sorts of sites were they?
Because there's an immense difference when it comes to hosting between a blog/brochure site that is fully cachable and a woocommerce or, worse, social network/LMS/other highly dynamic site.
To be clear though, I'm not advocating for distributed cloud architecture - that sort of stuff is best done on a vertically-scaled server, which can get up to many hundreds of CPUs these days.
They where dynamic publishing sites, so not supercomplicated and absolutely cached to the brim. A big chung of the concurrent visitors (prob like 90%) where on two websites, so two installs.
Ok. Yeah, you could easily have 100k concurrent visitors with that, if the request isn't actually reaching php/WordPress. On e it does, you're down to something like 2-4, maybe 10, requests per cpu core, per second. Depends on the hardware and how the site is configured.
[flagged]
[flagged]
no it isn't https://www.loom.com/share/a6461081f2bc4cba885eaf5cd233dca3
Interestingly, when you're typing in Notion I didn't see any em dashes. Is there some post-processing happening that's converting the hyphens to em dashes? e.g. the following paragraph appeared to have just regular hyphens when you typed on the Loom video:
This is great. I've considered doing the same thing. After all, I've always used em dashes in my writing, so I suppose all my blog posts are AI-generated as well.
[dead]
It's also full of wild inaccuracies. I dunno about AI, but the 'Where we are now' segment is some olympian level leaps.
Is "Written by a human" the new "Created with (heart emoji) in San Francisco" footer?