The rise of sovereignty

My first customer roadshow when I was at Red Hat highlighted governance (and security) as one of the concerns that many folks had about doing everything in a public cloud. This was at a time when the popular narrative, as well-written about in Nick Carr’s The Big Switch built on an earlier concept by computer scientist John McCarthy about utility computing. The gist was that computing was just a utility.

The basic idea, although it seems a bit outdated today given various distributed renewable power generation methods such as solar, was simple. How could you not go all in on centralized power plants and huge hydroelectric dams? At the time, power was something that self-evidently required large investments at any scale. And the concept expanded beyond compute itself to other forms of the compute hierarchy such as Platform-as-a-Service (PaaS) and even many forms of Software-as-a-Service (SasS). It suggested a winner-take-all and probably ultimately globally-regulated world. Sun CTO Greg Papadopoulos at the time even opined that “the world needs only five computers.” He was hyperbolic and echoing something IBM’s Thomas J. Watson probably never said but it did reflect a popular tech industry sentiment—even if Sun’s own cloud computing efforts never really got off the ground.

What wasn’t as much emphasized early-on was the location where data was stored and compute happened. Organizations like Amazon Web Services (AWS) did recognize this concern and started to expand their regions to more and more datacenters in different legal locales. This was partially for technical reasons like latency but it also recognized that governments and corporate governance were increasingly clamping down on where citizens and corporations were storing and executing on their information.

What was often perceived as a concern of “server huggers” who simply didn’t want to have compute operations and data stored off-prem—for reasons—has increasingly shifted to being a real IT management concern. It is no longer theoretical.

What were the real historical concerns?

In the early public cloud days, a lot of folks did have genuine security concerns—even if “security” often served as a shorthand for a broader set of governance matters. It was often mostly about control. Or just not being comfortable with outsourcing functions they weren’t used to effectively outsource—at least for business-critical functions.

Unless you’re a large enterprise, Hyperscalers probably have better security folks on staff than you do though I’m sure your staff are awesome. A lot of the early marquee customers for vendors like AWS weren’t really mission-critical. Though Netflix and Flickr did pretty well leaning heavily on AWS. But a widespread early-on thought in IT departments was at least your security people worked for you and this led to at least a comforting illusion that you were in control.

Over time, enough large enterprises including entities such as stock markets went into cloud in a big way though, and it became increasingly hard to argue that the hyperscalers were mostly for consumer services. There was certainly within many in the tech industry a question of when not if public clouds would become dominant.

Where are we today?

The first reason is sort of orthogonal to the rest of this discussion so I’ll dispose of it quickly. The superior finances of clouds versus industrialized data centers (including co-location facilities) never made a huge amount of sense to me as I wrote in 2009. Lots of reasons to use the hyperscalers (AWS, Google, Microsoft Azure) to be sure. But cost of services was often not one of them—especially for large organizations—and especially for specific types of services like data egress (which does tie at least indirectly into data sovereignty). I’m not sure to what degree FinOps ever took off as a formalized discipline even if I plugged it for a time, but I do think there has been an increasing awareness of the grass not always being greener on the other side of the fence in the public cloud. To be sure, many organizations aren’t great about understanding the burdened cost of engineers “just” doing a side-job. Cloud costs remain a background hum but that’s a topic for another day.

Today’s big topic is digital sovereignty. There are a couple of related threads to this. The first is sovereignty more broadly, perhaps especially data sovereignty. As I noted earlier, this has simmered at some level since the early days of public clouds. Portability and interoperability were part of an open cloud story even if it was never as easy and seamless as sometimes promised. However, both standards and open source do simplify portability, flexibility to use another (or multiple) vendors, or to move to hosting workloads yourself.

However, many saw these as theoretical concerns early-on that weren’t important for IT executives who had a business to run. Geopolitical risks in particular have transformed sovereignty into concerns that many boards are looking into. Is our data and IP safe from being looked at, copied, or even deleted unless we pay ransomware? This is not purely an issue with the actions of unfriendly nation states of course. Intelligence agencies and others around the world are interested in your data. You may not be able to stop every actor trying to access your data and workloads but the better you can put them out of easy reach and secure them, the better your odds.

You also need to be aware of maintaining compliance with government regulations like the type of data about citizens that is allowed to be stored or transferred/used elsewhere.

The latest wrinkle is AI sovereignty. This doesn’t require bringing all AI in-house. But it does suggest a deliberate approach to training data, models and their updates, and the locations and manner in which AI is deployed. To be sure, AI is still a rapidly developing area. Many, probably most, organizations are still unsure of the best way to use it to fit their business needs—and, indeed, what business needs it’s even best suited for. There are also various unresolved legal questions related to which data AI models can be trained on and a variety of other issues that mostly touch on copyright and privacy in various ways.

Conclusion

You might have been forgiven just a few years back if you thought the tech industry was entering one of those relatively stable lulls where a lot of energy would be going into stabilizing and improving something that looked a lot like the existing landscape. It never quite plays out that way, of course. But the combination of LLMs (and, presumably, what comes next in AI) and geopolitics/sovereignty have certainly upended a great deal.

Red Hat Summit: Early production and themes

The customary dating of AI is to the 1956 Dartmouth Summer Research Project, a gathering of elite researchers at Dartmouth College in New Hampshire. What would come to be called Cognitive Science dated to another gathering a few months later (at MIT with some attendance overlap) but that’s a topic for another day. We could also go back to some of Alan Turing’s earlier work and probably find antecedents before that. But we’ll fast forward past the various AI winters between then and now and fast forward to the present.

I’ll skip to the recent Red Hat Summit in Atlanta, not so much because Red Hat is an especially visible (though increasingly successful) player in AI in part by fusing their own cloud and AI products with their relationship with IBM and IBM Research in particular. They’ve plumbed their open source depth to bring more open approaches around AI. A deeper dive around AI and its relationship to open source is a topic for another day. The co-evolution of AI with cloud provides some interesting parallels and insights to AI as a whole. It is worthwhile to start with some context for Red Hat’s announcements at their recent event and how they represent an evolution with parallels to how cloud has evolved, how AI is moving into practical production uses, and what may lie ahead.

The context

I worked at Red Hat until a couple years back so it’s been both interesting and informative to view the progress of Red Hat’s AI strategy over that time. (I don’t totally love the use of AI in this context for various reasons I’ll get into at some point but not here and everyone does it.)

If we view it on the timeframe of Red Hat Summits, I put it this way.

At first, AI was aspirational. There was some there there. But it was more packaging of largely existing products together with IBM watsonx developments. There were also useful product architectures applied to real customer use cases in areas like retail.

But a fair bit of handwaving. To be honest, it felt a bit like cloud when I was brought on board to help weave a story around existing architectures and visions. Which did work towards Red Hat ultimate cloud success even if that involved some necessary adjustments over time. Last year, 2025, saw more concrete AI product firming up, but what about this year?

What were some of the themes?

If Year 1ish was the vision, 2025 was starting to look more like real product, and 2026 was starting to look more like proof points and legit, if early, customer stories.

I liked a lot of the emphasis. How can you not like NASA on stage talking about Artemis II and all the telemetry data involved? And they weren’t the only one talking about real AI use even if I’d probably characterize it as a lot of cherry-picked early days deployments in general.

Of course, AI heads the list. And it pervaded announcements in general.

Certainly, Red Hat’s OpenShift Kubernetes-based application development platform was prominent. But so were AI-related features in Red Hat Enterprise Linux (RHEL) which is still an important revenue source (and still the focus of many Red Hat Summit attendees).

Recent NVIDIA announcements were one highlight. NVIDIA’s GPU work ended up perfectly dovetailing with many of the needs of the current generation of AI. Probably not the endgame for AI processing but that’s a discussion for another day—but it certainly made sense for Red Hat to partner more closely. Red Hat emphasized its own strategy throughout but it is certainly intertwined with its IBM parent perhaps particularly through the AI work in IBM Research.

There was a general theme of freedom and choice through open source.That’s to be expected from Red Hat. But the world has also changed. Ashesh Badani, Senior Vice President and Chief Product Officer at Red Hat, emphasized the AI sovereignty and other data sovereignty-related issues that make portability and flexibility of infrastructure increasingly important. This has been true since Red Hat initially started emphasizing an open hybrid cloud strategy. But more recent geopolitics has made it a far less theoretical concern. Certainly the idea that “cloud” would become this general utility like electricity, as some envisioned, is not the way things have developed.

Something CTO Chris Wright said especially resonated with me: “Sitting on the AI sidelines is a failed strategy.” You’ll probably get things wrong with various technology transitions—and many of us did over time in various ways. Also another story for another day. But Chris also argued that “No one prepared for this level of change.”

An important implication of jumping in and fast change? Build in flexibility. Own your key assets. But be ready to adapt. That’s what happened with cloud too.

Technology matters. But organization and culture do too.

With cloud, we had server huggers. And they weren’t always wrong in spite of calls that economics just made it obvious that everything needed to go into the public cloud. And we’ve seen that hasn’t played out, important as the hyperscalers are. With AI we have… we have humans in the loop and they’re certainly not always wrong. So the challenge that companies have is not to over-rotate and thoughtfully integrate new technologies where they make sense and pivot as needed.

It’s easy to focus on tech developments with blinders on. But the reality is that they happen in the context of organizational momentum and the fact that important established business processes and domain knowledge aren’t things that can be shoved aside by the new shiny thing.

The zeitgeist of Kubecon in Amsterdam 2026

For various reasons, the past year has seen me devoting way too much time and mental energy to house and related matters (middle-of-the-night kitchen fire--no one hurt but very disruptive--MAKE SURE YOUR SMOKE DETECTOR BATTERIES ARE CHANGED!) which are pretty much resolved at this point. In any case, that's water under the bridge, and am jumping back into post-Red Hat analyst work again.

In addition to my personal BitMasons LLC, I'll be working with IronSpark Analysis along with my former manager (Lis Strenger) and others with a focus on open source, container ecosystem, and hardware generally. I just got back from Europe with Monkigras in London and Kubecon in Amsterdam (plus a bit of actual vacation in Paris). Tough life, I know.

Kubecon has grown into a sizable event. I caught an early one in Seattle with maybe a few hundred attendees. There were about 13,500 folks in attendance at this one--the largest yet. I don't necessarily love events getting up to this size. Given my druthers, I generally prefer more intimate gatherings such as Monkigras in London. On the other hand, it's a great opportunity to either run into or deliberately schedule time with lots of folks and to get an overall feel for the landscape--the zeitgeist to use one of those delightful German loan words.

So, what grabbed me?

1. Is Kubernetes really the story?

One of the things I've made a minor nuisance of myself about over the past couple of years (a general core competency) is asking "what comes after Kuberenetes?"

My thought is that very little lasts forever in this biz. That said, certain patterns at least, endure. The basic Unix (including Linux) process model and structure go back decades. But virtual machines (VMs) have come to be increasingly folded into the Kubernetes management plane.

My observation from Amsterdam was that Kubernetes, taken by itself, is increasingly part of the base-level infrastrucure. That doesn't mean a lot of work isn't still happening. But, like Linux, it seems as if it's evolved into a substrate that needs to be maintained and updated but not necessarily the layer where a lot of obvious changes will happen routinely. As Kelsey Hightower puts it: "Kubernetes has become sort of boring. People expect it to be stable and just works." Not a new idea, Kelsey was preaching this idea at a long-ago show--maybe a Container Camp.

For a show that most people refer to as Kubecon, there was relatively little explicit mention of Kubernetes on the show floor.

2. What about AI?

Oh. That.

I found there was (thankfully) a relatively minor amount of in-your-face AI-washing on the show floor but, unsurprisingly, AI was omnipresent to greater or lesser degrees.

And the landscape is changing rapidly.

I've probably been somewhat in the skeptic camp. Not dismissive exactly. But not ready to bet the whole pot. But a lot of rapid change is happening. One line from a press and analyst luncheon stood out: "AI slop has changed to stuff we can't ignore." There are downsides as well. Software supply chain attacks are now on steroids. We need better trust mechanisms. One question among many is how do we patch faster than the attacks?

3. Observability

Joined at the hip with AI is observability. If you don't know what's going on the system, AI can't help you much

. Observability has been a complicated issue over time. There's often been a tendency to capture lots and lots of data, put it in a big tub, and hope good things come out. Think data warehousing in the 1990s. Doesn't work so well. The basic challenge is to get from observability/data to outcomes. This is often not primarily a technical challenge. People at a complany need to think about the results they get back and take meaningful action based on those results.

AI can find insights from large volumes of data but constructing the right questions and gathering the most appropriate data matters a lot. Observability is also ultimately reactive. You need to understand the problem you're trying to solve going in.

4. Where does AI fit?

The nub.

There's a lot of hype. But my sense is that there's also a there there in ways that may not be the case with everything and certainly wasn't necessarily the case in years past.

Will be still be calling it AI in the coming years? Or will it just be part of how we deal with computing? (So many things are just part of what we take for granted, whether navigation, or search, or identifying a song or a bird.)

I remain deeply unconvinced that Large Language Models (LLMs) are any sort of an ultimate end-state. The collective we have punted again and again on related to AI fields such as cognitive science while shiny (and very successful) tools like LLMs and deep learning have popped into view.

I suspect that deeper explorations into cognitive science and other AI-related tasks will be needed beyond current LLM obsessions.