Google Cloud takes a gap year • The Register

Opinion “We pretend to work, and they pretend to pay us” is an old joke from the former Soviet Union. Many tech hacks feel the same way about earnings stories – those quarterly reports on the top-level bottom-line numbers from the big guys. We pretend they’re important, you pretend to read them.

They do matter but – like the results from the 2:30 at Goodwood – if you’re not invested, not very much. Perhaps a small profit uptick here, perhaps a world-record company valuation collapse there, but unless you’ve just lost the GDP of Estonia from your personal net worth (sorry about that, Zuck), nobody much notices.

Sometimes, as with the latest numbers from Google/Alphabet, there’s stuff in there worth a double-take. In this case, it’s that Google Cloud has lessened its habitual loss by leaving its old services in harness by a year, and some of its other infrastructure for longer.

Google is not a bit player on the market; it could push ahead with its upgrade cycle with some adjustments if it wanted to, and say as much, but no. It is opting out

So what, says anyone still wearily playing along in the office with kit that gets refreshed less often than an octogenarian teetotaller. But this is Google Cloud, one of the headline players in the most important enterprise IT market of our time.

If it’s saying that it’s improving its competitive offer by not bothering to upgrade its core CPU farm, that says a lot about the cloud, the processor market, and the future of both.

You can see the cloud as it is sold to you, easing the capex/opex ratio, adding flexibility, dialled-in scale, and performance while reducing managerial overhead. In a different light, it’s also a fantastic experiment in abstracting what IT actually means in business, paying other people to worry about all the boring stuff on your behalf.

Security, energy, hardware tending, meeting demand at a global scale – or just giving you an instant few cores of server to run up an idea or proof of concept without you having to buy so much as a multiway plug.

So when Google says in effect it doesn’t care about upgrading CPUs this time around, you can believe it. Issues like the chip shortage and global economic uncertainty will factor into the decision, but reports from the front line of the server industry indicate that if you’ve got the clout, you get your share. Google is not a bit player on the market; it could push ahead with its upgrade cycle with some adjustments if it wanted to, and say as much, but no. It is opting out.

It’s even more significant because Google is one of the most processor-focused providers. It reveals the processors used for different classes of task, sometimes even letting you pick the ones you want, and sometimes they’ll even be in the region and available configuration you fancy.

Compare that to the choices with Amazon AWS EC2, which are number of cores per instance and whether you want multithreading. That’s it, and that’s much more typical of CSPs. For most workloads, they don’t compete on CPU. Storage tiers get the works with latency versus capacity versus cost, but compute performance? Acceptable is good enough. You get virtual machines running on virtual CPUs, and you’ll like it.

Which leaves the chip companies with some hard questions needing answering somewhat sooner than they may have hoped. They really can’t shake the performance metric as the drug of choice, and it’s still easy to sell as the real shiny.

Headline numbers look good, HPC is always a happy place to be, and you can find plenty of other places where you need lots of grunt. General-purpose CPUs have to face off GPUs and other hardware-optimised silicon there, though, massively parallel tasks mostly don’t care about x86’s legacy.

As Apple has proven with its M1 architecture, x86 legacy doesn’t have to count for that much elsewhere these days. It’s not that CSPs and data centres are gagging for M1s, which work so well because they are so highly evolved for Apple’s market.

The x86 emulation overhead is perfectly bearable there while the ecosystem catches up with native versions; acceptable is good enough, and the path forward is clear. Meanwhile, enjoy the great battery life.

But CSPs aren’t gagging for the latest x86 magic either; they’ll happily take it at the right price and at the right time, but they’ll leave it for a while too. That’s a gap which is suddenly much more interesting; MacBook owners like battery life, but CSPs really don’t like the new era of accelerating energy costs.

The ARMification of servers at scale has been predicted a few times now, it’s never been quite clear how you get there from here. The M1, however, is a great proof of concept: the energy bills a great motivator to pay attention.

It is easy now to imagine the M1’s cloud-component cousin. A system-on-chip with a set of computing cores that are intrinsically efficient and can be very much more so with the right workload, very tightly coupled to IO and integrated memory, but instead of being tuned for a box of fruit, it works very well for a particularly configured VM – and works acceptably for others. Nothing here in beyond a competent design team, no matter where they work.

With a sea of these, a CSP could have a new, performant, and very competitively priced tier that rewards workloads that are optimised for the native, highly efficient modes, but remain competitive for the older tasks that would otherwise be happy running on the older stuff already in the racks.

The CSPs would get enough wriggle room to price-nudge the clientele into the low-energy workload domain while still picking up a bit more margin.

The world has already moved into the sort of containerised, multi-platform, open-dev, automated regime with the necessary tools and techniques for making apps for such an architecture. Not much novel engineering needed at the codeface.

The motivation is there, the methods are at hand, and the barriers to transition are much reduced. Maybe Google’s gap year is an indication that business will not resume as usual. ®