{"id":192,"date":"2026-11-01T11:05:01","date_gmt":"2026-11-01T10:05:01","guid":{"rendered":"https:\/\/michiel.vanotegem.nl\/?p=192"},"modified":"2026-11-02T21:03:01","modified_gmt":"2026-11-02T20:03:01","slug":"what-does-it-take-to-build-a-seal4hyperscale-cloud-and-is-it-worth-it-part-6-paas-and-saas-and-ai-services","status":"publish","type":"post","link":"https:\/\/michiel.vanotegem.nl\/index.php\/what-does-it-take-to-build-a-seal4hyperscale-cloud-and-is-it-worth-it-part-6-paas-and-saas-and-ai-services\/","title":{"rendered":"What does it take to build a SEAL4hyperscale cloud, and is it worth it? \u2013 Part 6: PaaS, and SaaS, and AI services"},"content":{"rendered":"\n

In part 1<\/a>, I presented the Cloud Sovereignty Framework and the question of whether SEAL4 is necessary at all, and for whom. Then we climbed from bottom to top: the data centers in part 2<\/a>, the infrastructure in part 3<\/a>, the platform in part 4<\/a> and the core services in part 5<\/a>. In this part, we go up another layer, to everything that is above the core services: platform services (PaaS) and software services (SaaS). I will discuss AI separately here, because AI can be important in both.<\/p>\n\n\n\n

The core services from the previous part are, if you don’t count the operation, hardware rental. Functionally, you still have to arrange everything yourself. That changes in this layer and this is where customers really benefit from cloud. In this layer, you don’t get components but outcomes: a database that manages itself, a messaging platform that is always running, a complete application for HR, finance or collaboration. Here, the lock-in also increases quickly. Virtual machines, containers, and storage can be moved somewhere else with some effort. With PaaS and SaaS services, that depends on choices you make (or have made in the past).<\/p>\n\n\n\n

I ask the same two questions again: what do you need to build it, and what do you need to operate it? On top of this layer, a third question is added: what does it cost to leave?<\/p>\n\n\n\n

From components to outcomes<\/h1>\n\n\n\n

PaaS and SaaS are on the same spectrum and both shift responsibility from the customer to the supplier. With IaaS, you manage the operating system, the middleware, the application and the data yourself. With PaaS, the vendor takes over the operating system and middleware: you get a database, an integration platform, an analytics environment, or an AI service as an API. With SaaS, the supplier also takes over the application. You only provide your users, your configuration and your data.<\/p>\n\n\n\n

Every step on that spectrum delivers efficiency. Security, scalability, and continuity are no longer your problem. Each step also gives up control. You’re exchanging operational burden for dependency, and for most organizations and most applications, that’s an excellent trade-off. That’s what this series is all about: for most applications, high sovereignty requirements are not necessary. But for the applications where they are needed, you have to know what you are giving up.<\/p>\n\n\n\n

Something also happens in this layer with the stacking from the previous parts. A PaaS or SaaS service consists of dozens of core services with a good layer of their own logic above them. All the dependencies from parts 2 to 5 are still included, and the supplier of the service adds its own layer: its own code, its own operation, its own jurisdiction. The sovereignty level of a service is at most as high as the weakest link in that pile. If it is possible to get a SaaS service from a non-European supplier on a European\/sovereign cloud, this service itself is not sovereign. Conversely, a European SaaS application on a non-European hyperscaler is not either, although measures can be taken to guard against data requests.<\/p>\n\n\n\n

Three forms of lock-in<\/h2>\n\n\n\n

Lockin is often treated as one thing, but on this layer it comes in three forms. Each form requires a different answer.<\/p>\n\n\n\n

The first form is the interface. Do you use a service via an open standard, such as a PostgreSQL protocol, a Kafka API, S3 or the Kubernetes API from part 5, or via the supplier’s own API? With an open standard, a second provider or running it yourself is a realistic way out. With your own API, leaving means rewriting. That’s not necessarily a bad thing, because your own services can be technically better. It just has to be a conscious choice.<\/p>\n\n\n\n

The second form is the data. Data has “gravity” because services that need the data often have to be close by to keep latency low. This is even more true for AI than for more traditional applications. As a result, the more data there is somewhere, the more it will revolve around and the more difficult it becomes to move the whole. Data (distribution) design is therefore becoming increasingly important and indispensable in a multi-cloud strategy. Open formats help with this in part. It does not immediately reduce gravity, but data is easier to move because there is a cut between the storage and what uses that data. For example, this is increasingly the norm for analytics platforms. Data is increasingly stored in open file and table formats in object storage, and the analyses that rely on it are interchangeable. Storage and computing power are therefore not only technically but also contractually separated.<\/p>\n\n\n\n

The third form is the most difficult and is most often underestimated: the meaning. I mean everything you’ve put into a shift over the years in addition to the data itself. Configuration, workflows, authorization models, reports, integrations, and most importantly, the way people started doing their jobs. With SaaS, this is the main form of lock-in. A full data export from a SaaS application gives you the data back, but not the processes. Leaving a SaaS vendor is therefore rarely an IT project. It is a change program in the organization.<\/p>\n\n\n\n

For the framework, this mainly affects SOV3 and SOV6. It is less about whether someone can access your data, and more about whether you can continue without this service.<\/p>\n\n\n\n

PaaS: Open Core, Closed Edges<\/h2>\n\n\n\n

With PaaS, the good news is that there is a mature open alternative for almost every category. For databases, messaging, analytics, integration and more and more AI tooling, there are open-source projects that can compete with commercial services. A managed service based on such a project has a built-in way out.<\/p>\n\n\n\n

Largely, because the pattern from part 5 of Kubernetes also applies here. The core is portable, the edges are not. What makes a PaaS service valuable are precisely the edges: the link with identity, key management, backups and point-in-time restore, monitoring, automatic failover, extensions that only exist with that one supplier. The application moves fine, the operating model around it does not. Portability is not a trait you get, but a trait you test.<\/p>\n\n\n\n

In addition, there is a less visible dependency. Behind many open-source projects are commercial parties that do most of the development work, often non-European. A number of them have changed their license in recent years to prevent cloud providers from offering their software as a service. So “open source” does not automatically mean “free to use as a service forever”. For SOV5 and SOV6, it’s not just whether the code is open that counts, but also who controls the project. Projects under a neutral foundation are substantially more robust than projects that depend on one company.<\/p>\n\n\n\n

SaaS: the supplier is the operation<\/h3>\n\n\n\n

With SaaS, the question of sovereignty shifts even further. You no longer manage anything yourself. The vendor writes the code, runs the operation, determines the release calendar, and decides which functionality will come and which will go. In the framework of SaaS, you don’t just look at where the data is, but especially at who does the operation (SOV4) and under what jurisdiction those people work (SOV2).<\/p>\n\n\n\n

Interestingly, Europe is doing relatively well on this layer. Where Europe is mainly a spectator in hardware, there are major European players in business software, such as Amadeus, SAP and TomTom. There is also a vibrant ecosystem of smaller SaaS vendors and open-source alternatives for collaboration and document management, for example. For a large part of the functionality that organizations need, there is a European alternative. This makes this, just like HSMs in part 5, one of the places where Europe plays a role. There is a caveat to this, because those SaaS services can only be called sovereign if they run on their own infrastructure, with their own operation. However, many SaaS services run on one of the hyperscalers, because of the cost efficiency and the focus on their own functionality.<\/p>\n\n\n\n

The question of sovereignty goes directly against that efficiency. SaaS is cheap and good because it’s multi-tenant: one codebase, one operation, thousands or millions of customers. Every improvement and every security update reaches everyone immediately. Offering that service on multiple clouds, or even in a sovereign private cloud, requires at least an expansion of the operations team and often even a separate operations team, possibly with nationality requirements for people who have been screened. That breaks the efficiency and in fact the business model of SaaS. And that’s not the only problem. This is also where the limited security signal discussed in the earlier parts comes into play. In addition, a separate instance is behind with updates, which makes the vulnerability even greater. You get more control, but a less good product at a higher price. Sometimes that is the right exchange, often not.<\/p>\n\n\n\n

With SaaS, it is also difficult to separate what you can control yourself. With PaaS, you can still arrange a lot with architectural choices: open standards, open formats, your own keys. With SaaS, the contract remains for the most part, with its own identity via federation and its own keys where the supplier supports it. And the tension from part 5 is at its sharpest here: a SaaS application that has to do something meaningful with your data, such as searching, analyzing or applying AI to it, must be able to read that data. Full control over keys and full functionality do not go well together.<\/p>\n\n\n\n

AI: where everything comes together<\/h1>\n\n\n\n

AI should be mentioned separately here, because that’s where everything from this series comes together. AI services are available as IaaS (hardware to develop and run models yourself), PaaS (models and inference as API) and SaaS (assistants and agents in applications) at the same time. These services require specific hardware, which was already shown in part 3 to be almost entirely non-European. Due to the amount of energy they use and the heat that is generated, they also need the most modern data center innovations. Innovations that are mainly driven by the hyperscale cloud providers, as discussed in part 2. The associated speed of innovation is what Europe is struggling with. The most powerful models are largely non-European and cannot be run yourself. And the tooling around it is developing at a pace that no other service can achieve.<\/p>\n\n\n\n

At the same time, AI is also a good example of how you can create space with architecture. An open-weight model in your own environment cannot be turned off, cannot be adjusted unnoticed and cannot be withdrawn. For many applications, such a model is more than sufficient. So the trade-off is the same as everywhere else on this layer: the best there is, or what you can control. And you can make that choice differently for each application.<\/p>\n\n\n\n

Build<\/h1>\n\n\n\n

For those who want to offer a hyperscale cloud, the number of services and their richness is a particular challenge. The hyperscalers offer hundreds of PaaS services with an extensive feature set, whereas European cloud providers often limit themselves to the core services from the previous part and a limited number of PaaS services. That set of services is growing, but relatively slowly because each of those services requires manpower to build, certify and operate. Even if the service uses open source, this is not easy, because you can’t just assume that everything is good. So the build is much more than installing it on a few servers.<\/p>\n\n\n\n

A sovereign cloud therefore has to make choices and can therefore only focus on those must-have services. A sovereign cloud with ten well-managed services is better than one with a hundred that only do half of it, but it does have the disadvantage that it is more difficult for a third party to build a SaaS service on it. Most SaaS services do not build their own cloud, but build on top of an existing cloud, because it removes a lot of complexity. Few SaaS services are available on different clouds, as each additional version requires additional expertise and manpower, which comes at the expense of efficiency.<\/p>\n\n\n\n

The good news is that the greenfield advantage from part 5 also applies here. Those who start today can incorporate portability, open formats, and crypto-agility into the design from day one, rather than having to bake them in later.<\/p>\n\n\n\n

Operate<\/h1>\n\n\n\n

The operation again contains the real bill, and at this layer it will be even higher. Each department partly conducts its own operation with its own experts. A team that manages a database service at scale is not the same team that keeps an integration platform or an AI service running. The certification burden can build on the shared basis from parts 4 and 5, but ultimately each service must be certified separately. This means that this process must also be industrialized in order to keep the effort as low as possible.<\/p>\n\n\n\n

All this requires a lot of (specialist) knowledge. The people who can build and operate these types of services at scale are scarce and in demand worldwide. A sovereign provider competes for those people with the largest employers in the tech sector. And because SEAL4 requires the operation to take place entirely within the EU and under EU law, the pond in which to fish is even smaller.<\/p>\n\n\n\n

Of course, customers also have requirements. They expect stability from core services. They expect innovation from PaaS and especially SaaS: new features, better integrations and now new AI applications. There is a business risk in this, which is a vicious circle: a sovereign provider that cannot innovate loses customers while customers are needed for the required scale to invest in the necessary stability and innovation.<\/p>\n\n\n\n

And then there is the security aspect. More services means a larger attack surface and at the same time we see that AI is able to exploit vulnerabilities faster and faster. This manifests itself in pressure on the operation to be able to patch quickly and often (daily if necessary). Another aspect is that the data breaches you read about the most are often caused by software misconfigurations, especially PaaS and SaaS services. Anyone who sees and can fix configuration errors with thousands of customers at the same time has an advantage that a small environment does not have. Scale is therefore of vital importance here.<\/p>\n\n\n\n

Exit: the question that weighs most heavily here<\/h1>\n\n\n\n

In part 5, I called portability the most underestimated instrument of sovereignty. It weighs most heavily on this layer, because this is where the choices fall that determine whether an exit is possible at all. In practical terms, it comes down to a handful of questions you should ask with any PaaS or SaaS service:<\/p>\n\n\n\n