This week the president of Broadcom's infrastructure software business said that "the only time you rent is because you are cash poor." Yes I know, that sentence travels well on social media. But honestly, the more interesting part of the week was everything published around it, because almost every other number I read in the last seven days was about the same thing: what it actually costs to own infrastructure well.
In a Computer Weekly interview published on 8 October, Ram Velaga, who runs Broadcom's Infrastructure Software Group, set a public target: by late 2027 more than half of the VMware installed base, measured in processor cores, should be running VCF 9. "We have goals more aggressive than that, but I think 50% is a reasonable number for us to target," he said. According to Velaga, server prices are now two to three times what they were a year ago, and Broadcom itself runs less than 20% of its own workloads in public clouds.
The line that got quoted everywhere was the one about renting. The line I find more useful is a different one: "One step ahead is, 'Do I save on cost?' Two steps ahead is, 'Do I own this infrastructure?'" And Krish Prasad, who leads the VCF division, added the operational side: "In the era of Mythos and the frontier AI models, you cannot afford to have fragmented operations and fragmented security."
I don't read the rent sentence as a provocation. It is a capital allocation argument, and for predictable workloads it is largely right. But "own" is not a balance sheet word. It is an operating word, and that is where most organisations get into trouble.
No. Owning is cheaper if you run what you own, and that is a much bigger "if" than most business cases admit. Capacity that sits idle, VMs that are sized for a worst case nobody ever measured, platforms that drift away from their hardening baseline and patch cycles that wait for a quarterly meeting, all of that is ownership too. At server prices two to three times last year's level, badly used ownership is the most expensive form of infrastructure there is.
So when I look at this week, I see four bills that come with every rack you decide to own. None of them shows up on the purchase order. All of them show up later.
Broadcom engineers published two pieces on AI workloads on VCF in the last two weeks, and together they are a pretty uncomfortable read for anybody who sized a GPU environment by gut feeling. In the first one (28 September), four under-utilised inference workloads (Llama 3.1 8B at FP4 on servers with four RTX 6000 Pro GPUs) started at a GPU SM utilization of about 34 to 38% and 2,328 tokens per second. With MIG-based vGPU sharing and eight VMs per server, utilization went to 79% and throughput to 18,621 tokens per second; in the MLPerf offline batching test it reached 94% and 23,365 tokens per second. The article also cites research (Gao et al., ICSE 2024) that enterprise GPU utilization is "often hovering at or below 50%".
The second one (5 October) looked at the VM around the GPU. Varying memory between 32 GB and 512 GB, or vCPUs between 16 and 128, "had little or no impact on the performance of AI workloads that use GPUs for acceleration." And running a HammerDB TPC-C database at 1.8 million TPM on the same server as Llama3 70B inference showed, in their words, that "neither workload experiences a measurable performance impact."
These are vendor tests, on vendor-chosen hardware, and they should be read that way. But the direction is clear, and it matches what you see when you actually look at the graphs instead of the original sizing spreadsheet: most AI VMs are sized by fear, not by measurement. Every core and every gigabyte you park next to a GPU "just in case" is capacity the rest of the data center is now buying at double or triple the price.
Bob Plankers wrote about the VCF Security Configuration Guide on 5 October, and one sentence in it should be printed on the wall of every operations team: "Settings drift, and upgrades and patches can change things." His recommendation is equally simple: "Rerun your audit after lifecycle operations and on a regular schedule, including the P2 controls that were already secure." And for the priorities: "P0 is where there is not a secure default, and you should do this immediately."
Most environments are not insecure because a control was never implemented. They are insecure because the setting that was right at go-live is no longer right today, and nobody went back to check. Hardening is not a project with an acceptance date. It is an audit you repeat, at the latest after every update. That is part of owning.
The patch bill is getting bigger, and fast. Broadcom now ships Express Patches for VCF 9.1, which "are released monthly and are downloaded and applied through VCF Operations," with the reasoning that "malicious actors use automated tooling to weaponize zero-days and newly disclosed security flaws within hours of disclosure." Help Net Security, summarising Google Threat Intelligence Group data, reported 5,045 CVEs disclosed in January 2026 and 10,740 in August. Only 0.23% of this year's vulnerabilities were exploited in the wild, but half of the AI-discovered ones lead to remote code execution, compared with 26% for other discovery methods. According to Velaga, customers now want to patch every few weeks without going through downtime.
Chris McCain from Broadcom summed up the mood in four words: "Nobody loves to patch." John Nicholson went further on 6 October: "Waiting 90 days for bugfixes and critical security patches is simply not acceptable." And he described a case where "the security of a large organization was effectively being held hostage by an incredibly minor dependency." A plugin, a vendor image, a monitoring agent nobody really uses anymore. That is not a technology limitation. That is a dependency somebody decided to keep, or more precisely never decided to drop.
And this is the bill that connects the other three. Who decides which team shares the GPU and who gets priority? Who decides that the drift audit runs after every lifecycle operation and not "when we have time"? Who decides that the change advisory board does not meet quarterly when the patches arrive monthly? Who decides that the minor dependency goes?
In more than twenty years of VMware architecture, my view on this has become very simple: the hardware is rarely the bottleneck, and the software rarely is either. The bottleneck is the decision that nobody owns. Ownership of infrastructure without ownership of those decisions is just an expensive way of storing problems.
Velaga said it himself: "Three years ago, who knew the cost in the IT industry was going to be what it is right now?" When servers were cheap and available, oversizing was cheap insurance and a slow patch cycle was a risk you could live with for a while. With server prices at two to three times last year's level, long lead times, and AI models that find exploitable flaws faster than most change processes can react, both of those habits turned into line items.
That is also why I think the own-or-rent debate is too often held at the wrong level. The question is not whether a CFO prefers capex or opex. The question is whether the organisation is prepared to operate what it owns with the same discipline a provider would. "The cloud guys are ruthless," Velaga said. "If you don't deliver the economics, they'll throw you out." The same standard applies inside your own data center. The difference is that nobody throws you out; you just pay, quietly, every month.
Not a strategy workshop. Five questions, and each one needs a name and a date behind the answer:
If you can answer all five in ten minutes, you are probably ready to own. If you can't, the honest answer is not "rent instead". The honest answer is: fix the operating model first, because a different location for the same habits does not change the bill.
Own what is predictable and what you are prepared to run well. Rent, consciously and with an exit plan, what is spiky or experimental. Never do either by default. "Do I own this infrastructure?" is the right question, as long as the next one follows immediately: "And am I prepared to run it like I mean it?"
Ownership is not a statement on the balance sheet. It is an operating promise, and the four bills come due whether you planned for them or not.
#DecideOrGoHome
At comdivision we spend most of our time on exactly these questions, designing and running VMware Cloud Foundation platforms that are actually used and not just owned. If you want to compare notes on your own four bills, reach out to me.