I’ve been blogging for quite a while on “edge computing”, pointing out that to enterprises it’s accomplished through deployment of their own servers, co-located with the processes they’re intended to support. Cloud providers, recognizing that the increased demand for real-time process control is a big opportunity or risk, getting a piece of the local edge is critical. All the major public cloud providers have been offering tools to allow companies to extend cloud-centric applications outward to a local edge device, but Google wants to take that further with a new feature for the Google Distributed Cloud. GDC isn’t new, but there’s some new thinking here, resulting some new emphasis and targeting, and we need to look at what it all might mean.
All the cloud provider edge strategies have focused on the idea of distributing their cloud middleware to user-provided edge devices in order to create a favored link between a local edge and their own cloud services. These strategies, say enterprises, have had limited success because most of these local edges were developed before the notion of “cloudification” of the edge came along, and because the idea really didn’t get a lot of ink, and thus build as much user awareness as it should have. I think Google’s evolving Distributed Cloud strategy aims at addressing both these points.
Google announced GDC back in 2022, responding to initiatives from Amazon and Microsoft to push cloud features onto the premises, particularly for edge applications that, for reasons of latency, cost, or security, were unlikely to be suitable for traditional cloud services. For strategic reasons, there are three reasons for the approach. First, edge computing is seen by CIOs as a form of distributed computing, and in my own case I’ve always seen it as a subset of that broader category that aims at real-time processes. Second, the cloud itself is a distributed hosting model, and it makes sense to consider edge strategies that unite these two points. Finally, it plays on the notion that cloud affinity can be created in emerging applications that require applications run close to the processes they support. In short, it connects Google’s offering with validated market trends and buyer interests.
These points, obviously, are most compelling where an edge application is developing rather than where one has existed for some time. Real-time process control isn’t something enterprises want to change at a whim, and developing cloud affinity for no specific business reason isn’t likely enough to drive change. A new application, though, could easily be seen as justifying a cloud connection even if the value of that connection is still to be proven. Which is probably why Google is linking this to AI.
New real-time application opportunities are often created by new technologies that open the new opportunities. AI is the hottest new technology, and there are obviously cloud-hosted AI application components. The cloud can also be a development tool for AI, a place where users can build and train models with tactical resource-as-a-service elements, then transfer the resulting model to the premises to satisfy data security/sovereignty governance policies. The number of enterprises willing to trust real-time process control to the cloud is near-zero, whether AI is involved or not, but is total zero with AI.
GDC’s newly announced air-gap capability is ideal for situations where absolute security is needed. There are a lot of applications, and even entire verticals, that demand the highest level of sovereignty. Air-gapped GDC can create a fully policy-regulated framework where needed, even in theory to places that might not be really typical edge situations. Some enterprises tell me they have “policy zones” in data centers to handle situations that require extreme security and isolation.
A technical link to the notion of distributed processing comes from the fact that Google supports Kubernetes as a means of deploying Distributed Cloud. The cloud side obviously supports it, as well as Anthos for multi-cluster management, and so does the data center, and now the new edge. All of this creates the technical framework needed to operate a true distributed cloud. Even the new air-gapped system is Kubernetes-orchestrated.
And speaking of “system, another interesting thing Google is adding is the model for productizing their new edge. Instead of looking at it as an open-source middleware tool, Google is turning it into an appliance based on open-source software tools customized to run as a policy-controlled, air-gapped, element.
What I think this adds up to is an enhancement to an initiative by Google, one other cloud providers are already following in their own way, to redefine the role of the cloud. Rather than making it a replacement for the data center, a strategy that almost all enterprises say now is too costly, has too many security problems, and is too risky from a reliability perspective, they want the cloud to be an agile element in an over-arching distributed computing model. To get to that, Google is framing the edge as the point of introduction, with AI and data sovereignty as the specific features that would drive new applications, and thus facilitate adoption.
I think this is smart, based on inferences I can draw from enterprise comments on the cloud, and on the way their vision of the cloud has evolved. I think that eliminating the “move everything to the cloud” approach, while justified and inevitable, creates a kind of vacuum. I’ve said that the front-/back-end model of applications is a logical successor, but it may not be general enough to capture all the applications, and may not in particular be called to mind in regards to the new applications under consideration. Greenfield stuff is always easier to influence than brownfield stuff, because nobody wants to propose changing an application that’s working and because stranding cost is always a risk in a replacement approach. GDC seems like it might dodge these problems at least, and perhaps solve them.
The qualifier here is necessary for two reasons. First, I don’t yet have enterprise views on the approach. Second, a full vision of all the ways the new air-gap capability would interact with data center, cloud, and Internet isn’t something we can easily pull from the Google material. Yes, there are some reference applications mentioned, but a broader picture and very detailed technology models are needed. Finally, we need to see how competitors will refine and perhaps modify the approach, and what settles out in this dynamic. Most enterprises will wait to see how AWS and Azure deal with the same challenges before they spend a lot of time working on a plan, unless of course they are either already Google Cloud users or have a need an air-gap enhancement to GDC could address and that cannot be delayed.
There’s also, of course, the question of just how far an air-gap notion will be taken. Could we see a trend toward a greater isolation of even data-center elements? Could cloud features to establish a kind of “virtual air gap”, a mechanism to prevent Internet attacks of a cloud front-end element propagating to the data center? Could we see the idea of air-gaps within the cloud, even mimics of the enterprise “policy zones” emerge? With all the emphasis on security, that all seems possible, and a possible evolution of the air-gapped edge trend.
This is an interesting move that could turn out to be a critical step in edge computing, but also even for the cloud. There’s an unusual undercurrent of realism here, something that properly aligns the elements of an evolving set of application deployment options to address an evolving set of applications and their business cases and requirements. Could it be just what we need today? Maybe not quite yet, but it seems to at least point to a path to get to that happy destination.
