I’ve been following Bert Hubert on social media since coming across his posts a couple of years ago, and this weekend he asked an interesting question:
“Going to the cloud’ can mean anything from renting a VM, deploying containers, or building on top of advanced (hyperscaler) cloud services (queues, buckets, customer IAM etc). Is there a good term to describe the latter development style, going all in on cloud services? I’ve used ‘cloud native’ before but the meaning of that is not clear or useful. Better suggestions very welcome!
Link to original post from Bert Hubert
I wanted to dash this response out because I think I understand what he’s getting at, and in the context of geopolitical discussions about computing, I think it’s helpful distinction.
I’m referring to the building on top of advanced (hyperscaler) cloud services (queues, buckets, customer IAM etc) part of his post on Mastodon, as I think this is a qualitatively different way of thinking about how people build digital products.
Going to the cloud vs building “in” the cloud
When people talk about “going to the cloud”, they often refer the idea of consuming computing services rather than directly operating datacentres themselves. There are good reasons to do this, as most people don’t really want to run datacentres.
The thing this, this doesn’t do a very good job of capturing how the way large hyperscaler cloud providers work, because if you look at how their own services are built, you’ll often see that many of the higher level systems are composed of relatively low level systems, that expose the ability to do stuff like store data, or put work on a queue, control access to resources like specific files and so on. People in senior technical roles at AWs have written long technical posts that go into this – here’s one example from AWS Distinguished Engineer Andy Warfield on the All Things distributed blog, and Marc Brooker’s blog is a trove of insight too, if you want to understand how the same low level services keep being reused to build higher order systems.
I’ve tried putting together a quick diagram below, based on a bunch of existing we’ve spoke about at work. We’re largely talking about the bottom set of things – the kinds of digital resources we consume, and one level up, what are referred to as low level serviced – “primitives”. These are specific things we consume, that are billed like a fungible commodity (i.e. KWh of electricity, litres of water, gigabytes of object storage, vCPU’s worth of compute, etc)
This is not my idea. Here’s an article featuring AWS CEO Andy Jassey talking about these kinds of primitives, and why they use them.
How do I explain “cloud primitives” to policy makers?
One problem we have here is that cloud primitives make sense when speaking to engineers, but they’re not exactly easy concepts to explain to people, and honestly, I think lots of the discussions about Euro-stacks totally miss this.
If you try reading the recent Euro-Stack report, you can come away with the idea that the people who wrote it have never had to build a service themselves using these cloud primitives, and that their main exposure to cloud is the stuff at the top – the end user services.
One promising path – digital resources?
One way I think is helpful has been the work that the SDIA has done with digital resources – using a new term to help policy makers understand that datacentres all by themselves don’t actually create jobs. Instead they largely create digital resources – the things you need to run an software service that does something of value, and you still need to think about the next stage to understand where the value is created.
What are digital resources?
This diagram below is from a report the Green Web Foundation, “Critical Dependencies”, published last year, to try to help communicate this idea – that you need digital resources to run software, and software drives the digital economy, and control over how digital resources is really important in a democracy.
Anyway, this idea of datacentres creating digital resources is a bit like the idea of clean energy farms creating clean energy – both are fungible ‘primitive’ resources that are required to create higher value things you can sell, but you still require an ecosystem of people who know how to turn the primitives into higher value goods.
When you get a datacentre in your part of town, if you don’t have access to the digital resources on terms you have a say in, it’s a bit like having a wind farm plonked in your part of town, where all the energy is used used by someone else. On both cases someone else is getting to capture all the value that the fungible resources create instead of you.
If you forgive the analogy, it’s a bit like having an oil well which produces some unprocessed commodity like crude oil – it might help to produce it, and there might be some value captured by the people owning the land, but a lot of the time, much more of the value is being made when it’s processed into higher value things like plastics, or jet fuel and so on.
The other key idea is that primitives are somewhat fungible here. As long as the primitives can be created to a fairly consistent standards, then it doesn’t really matter how they’re created – the details, like the specific hardware used to provide a gigabyte of storage, or specific suppler don’t matter so much. This allows you to use different kinds of hardware, or different suppliers.
So just like the power I consume from a Chinese wind turbine compared a Danish wind turbine would be very difficult for me to tell apart, if you’re thinking in terms of these primitives, then it ought to be easier to get compatible digital resources from other, new providers too. Comparisons to the energy sector work here again too – most of the new investment into the clean energy sector is NOT coming from the incumbent predominantly fossil used big energy companies. Instead, it’s coming new investors, which changes the geopolitical power balances, and because it’s easier to enter, there’s more competition.
That’s a separate point though – for the most part, this notion of having primitives as a thing that’s fungible across providers is a long way off. The idea of something as wacky as a single market for compute where companies compete to efficiently sell cloud primitives is even further off, although there are some interesting signs out there. Spare Cores is one example of an aggregator of cloud primitive pricing, and based in Europe, and think tank Leitmotif has an interesting policy brief that refers to a single market for compute too.
Anyway.. back to this “going to the cloud” / “cloud primitives thing”.
What do you call this then?
The frustrating thing here is that I think I understand what Bert is getting at, and the closes term in tech right now probably is “cloud native”. But even that is frustratingly vague, and pretty impenetrable to people who are not working on cloud services every day.
If I wanted to come up with a term that might you might use instead of “going to the cloud”, to capture this idea of building digital services from cloud primitives instead, I might try something like “composed digital resources”, but TBH, that sounds pretty poor too.
I think one of the reasons we don’t have a term, is that honestly, the idea of cloud services being providers of fungible primitives draws attention that a lot of the time, companies are paying to consume fungible utility-style commodity services, but at paying premium product prices with premium product margins.
If you’re paying for a fungible commodity, the fungibility is a key thing – and if you have multiple suppliers of fungible goods, if you can freely switch between them, then they’ll likely need compete on price and service, and in many cases, compete away those juicy margins as they fight each other for your business.
If I was a cloud provider with very healthy margins, I’d do everything I can to avoid my product being thought of as a fungible utility for precisely this reason.
So, I think you’d likely need a new term, from a new place to capture this idea, as it’s not in my interests to draw attention to the fact that if I present myself as a provider of utility services, it might be reasonable to expect utility style margins too.
I think it’s needed though, as it’s an idea that isn’t really that well captured in current discussions about digital sovereingty, eurostacks and so on.