{"id":188,"date":"2026-10-29T19:20:30","date_gmt":"2026-10-29T18:20:30","guid":{"rendered":"https:\/\/michiel.vanotegem.nl\/?p=188"},"modified":"2026-11-02T21:06:26","modified_gmt":"2026-11-02T20:06:26","slug":"wat-is-er-nodig-om-een-seal-4-hyperscalecloud-te-bouwen-en-is-het-de-moeite-waard-deel-6-paas-en-saas-en-ai-diensten","status":"publish","type":"post","link":"https:\/\/michiel.vanotegem.nl\/index.php\/wat-is-er-nodig-om-een-seal-4-hyperscalecloud-te-bouwen-en-is-het-de-moeite-waard-deel-6-paas-en-saas-en-ai-diensten\/","title":{"rendered":"Wat is er nodig om een SEAL\u20114\u2011hyperscalecloud te bouwen, en is het de moeite waard? \u2013 Deel 6: PaaS-, en SaaS-, en AI-diensten"},"content":{"rendered":"\n

In deel 1<\/a> zette ik het Cloud Sovereignty Framework neer en de vraag of SEAL\u20114 \u00fcberhaupt nodig is, en voor wie. Daarna klommen we van onder naar boven: de datacenters in deel 2<\/a>, de infrastructuur in deel 3<\/a>, het platform in deel 4<\/a> en de kerndiensten in deel 5<\/a>. In dit deel gaan we weer een laag omhoog, naar alles wat boven de kerndiensten zit: platformdiensten (PaaS) en softwarediensten (SaaS). AI behandel ik hier apart, omdat AI in beide van belang kan zijn.<\/p>\n\n\n\n

De kerndiensten uit het vorige deel zijn, als je de operatie niet meetelt, huur van hardware. Functioneel moet je alles zelf nog regelen. Dat verandert in deze laag en dit is waar klanten echt voordeel halen uit cloud. In deze laag krijg je namelijk geen componenten maar uitkomsten: een database die zichzelf beheert, een berichtenplatform dat altijd draait, een complete applicatie voor HR, financi\u00ebn of samenwerking. Hier wordt de lock-in ook snel groter. Virtuele machines, containers, en opslag kun je met wat moeite nog ergens anders naartoe verhuizen. Met PaaS- en SaaS-diensten hangt dat af van keuzes die je maakt (of in het verleden gemaakt hebt).<\/p>\n\n\n\n

Ik stel weer dezelfde twee vragen: wat heb je nodig om het te bouwen, en wat heb je nodig om het te opereren? Op deze laag komt er een derde vraag bij: wat kost het om weg te gaan?<\/p>\n\n\n\n

Van componenten naar uitkomsten<\/h1>\n\n\n\n

PaaS en SaaS liggen op hetzelfde spectrum en schuiven allebei verantwoordelijkheid van de klant naar de leverancier. Bij IaaS beheer je zelf het besturingssysteem, de middleware, de applicatie en de data. Bij PaaS neemt de leverancier het besturingssysteem en de middleware over: je krijgt een database, een integratieplatform, een analyseomgeving of een AI-dienst als API. Bij SaaS neemt de leverancier ook de applicatie over. Je levert alleen nog je gebruikers, je configuratie en je data aan.<\/p>\n\n\n\n

Elke stap op dat spectrum levert effici\u00ebntie op. Beveiliging, schaalbaarheid, en continu\u00efteit zijn niet meer jouw probleem. Elke stap levert ook controle in. Je wisselt operationele last in voor afhankelijkheid, en voor de meeste organisaties en de meeste toepassingen is dat een uitstekende ruil. Daar gaat deze serie steeds over: voor de meeste toepassingen zijn hoge soevereiniteitseisen niet nodig. Maar voor de toepassingen waar ze wel nodig zijn, moet je weten wat je inlevert.<\/p>\n\n\n\n

Er gebeurt in deze laag ook iets met de stapeling uit de vorige delen. Een PaaS- of SaaS-dienst bestaat uit tientallen kerndiensten met een flinke laag eigen logica erboven. Alle afhankelijkheden uit deel 2 tot en met 5 zitten er nog onder, en de leverancier van de dienst voegt er een eigen laag aan toe: eigen code, eigen operatie, eigen jurisdictie. Het soevereiniteitsniveau van een dienst is hooguit zo hoog als de zwakste schakel in die stapel. Als het al mogelijk is om een SaaS-dienst van een niet-Europese leverancier op een Europese\/soevereine cloud te krijgen, is deze dienst zelf niet soeverein. Andersom is een Europese SaaS-applicatie op een niet-Europese hyperscaler dat ook niet, al zijn er wel maatregelen te treffen om te wapenen tegen dataverzoeken.<\/p>\n\n\n\n

Drie vormen van lock\u2011in<\/h2>\n\n\n\n

Lock\u2011in wordt vaak als \u00e9\u00e9n ding behandeld, maar op deze laag komt hij in drie vormen voor. Elke vorm vraagt om een ander antwoord.<\/p>\n\n\n\n

De eerste vorm is de interface. Gebruik je een dienst via een open standaard, zoals een PostgreSQL-protocol, een Kafka-API, S3 of de Kubernetes-API uit deel 5, of via een eigen API van de leverancier? Bij een open standaard is een tweede aanbieder of zelf draaien een realistische uitweg. Bij een eigen API betekent vertrekken herschrijven. Dat is niet per se slecht, want eigen diensten kunnen technisch beter zijn. Het moet alleen wel een bewuste keuze zijn.<\/p>\n\n\n\n

De tweede vorm is de data. Data heeft \u201czwaartekracht\u201d omdat diensten die de data nodig hebben vaak dichtbij moeten staan om de latency laag te houden. Voor AI geldt dit nog sterker dan voor meer traditionele toepassingen. Hierdoor is het zo dat hoe meer data er ergens staat, hoe meer er omheen gaat draaien en hoe lastiger het wordt om het geheel te verplaatsen. Data (distributie) ontwerp wordt daardoor steeds belangrijker en bij een multi-cloud strategie onmisbaar. Open formaten helpen hier deels bij. De zwaartekracht wordt er niet direct minder door, maar data is makkelijker te verplaatsen omdat er een knip ligt tussen de opslag en dat wat die data gebruikt. Bij bijvoorbeeld analytics platformen is dit steeds meer de norm. Data staat steeds vaker in open bestands- en tabelformaten in objectopslag, en de analyses die erop rekenen zijn verwisselbaar. Opslag en rekenkracht zijn daarmee niet alleen technisch maar ook contractueel van elkaar losgemaakt.<\/p>\n\n\n\n

De derde vorm is de lastigste en wordt het vaakst onderschat: de betekenis. Ik bedoel alles wat je in de loop der jaren in een dienst hebt gestopt naast de data zelf. Configuratie, workflows, autorisatiemodellen, rapportages, integraties, en vooral de manier waarop mensen hun werk zijn gaan doen. Bij SaaS is dit de belangrijkste vorm van lock\u2011in. Een volledige data-export uit een SaaS-applicatie geeft je de gegevens terug, maar niet de processen. Vertrekken bij een SaaS-leverancier is daarom zelden een IT-project. Het is een veranderprogramma in de organisatie.<\/p>\n\n\n\n

Voor het framework raakt dit vooral SOV\u20113 en SOV\u20116. Het gaat dan minder om de vraag of iemand bij je data kan, en meer om de vraag of je zonder deze dienst verder kunt.<\/p>\n\n\n\n

PaaS: open kern, gesloten randen<\/h2>\n\n\n\n

Bij PaaS is het goede nieuws dat er voor bijna elke categorie een volwassen open alternatief bestaat. Voor databases, messaging, analytics, integratie en steeds meer AI-tooling zijn er open-sourceprojecten die zich met commerci\u00eble diensten kunnen meten. Een beheerde dienst die op zo’n project is gebaseerd, heeft een ingebouwde uitweg.<\/p>\n\n\n\n

Grotendeels, want het patroon uit deel 5 bij Kubernetes geldt hier ook. De kern is portabel, de randen niet. Wat een PaaS-dienst waardevol maakt, zijn juist de randen: de koppeling met identiteit, het sleutelbeheer, de back-ups en point-in-time restore, de monitoring, de automatische failover, extensies die alleen bij die ene leverancier bestaan. De applicatie verhuist prima, het operationele model eromheen niet. Portabiliteit is ook hier geen eigenschap die je krijgt, maar een eigenschap die je test.<\/p>\n\n\n\n

Daar komt een minder zichtbare afhankelijkheid bij. Achter veel open-sourceprojecten zitten commerci\u00eble partijen die het meeste ontwikkelwerk doen, vaak niet-Europese. Een aantal van hen heeft de afgelopen jaren de licentie aangepast om te voorkomen dat cloudproviders hun software als dienst aanbieden. “Open source” betekent dus niet automatisch “voor altijd vrij te gebruiken als dienst”. Voor SOV\u20115 en SOV\u20116 telt niet alleen of de code open is, maar ook wie het project bestuurt. Projecten onder een neutrale stichting zijn wezenlijk robuuster dan projecten die van \u00e9\u00e9n bedrijf afhangen.<\/p>\n\n\n\n

SaaS: de leverancier is de operatie<\/h3>\n\n\n\n

Bij SaaS verschuift de soevereiniteitsvraag nog verder. Je beheert niets meer zelf. De leverancier schrijft de code, draait de operatie, bepaalt de releasekalender en beslist welke functionaliteit er komt en welke verdwijnt. In het framework kijk je bij SaaS dus niet alleen naar waar de data staat, maar vooral naar wie de operatie doet (SOV\u20114) en onder welke jurisdictie die mensen werken (SOV\u20112).<\/p>\n\n\n\n

Interessant is dat Europa op deze laag relatief goed meedoet. Waar Europa in hardware vooral toeschouwer is, zijn er in bedrijfssoftware grote Europese spelers, zoals Amadeus, SAP en TomTom. Verder is er een levendig ecosysteem van kleinere SaaS-leveranciers en open-sourcealternatieven voor bijvoorbeeld samenwerking en documentbeheer. Voor een groot deel van de functionaliteit die organisaties nodig hebben, bestaat een Europees alternatief. Daarmee is dit, net als HSM’s in deel 5, een van de plekken waar Europa meespeelt. Daar zit wel een kanttekening aan, want die SaaS-diensten zijn alleen soeverein te noemen als ze draaien op eigen infrastructuur, met eigen operatie. Veel SaaS-diensten draaien echter op een van de hyperscalers, vanwege de kosten efficiency en de focus op de eigen functionaliteit.<\/p>\n\n\n\n

De soevereiniteitsvraag gaat regelrecht tegen die efficiency in. SaaS is goedkoop en goed omdat het multi-tenant is: \u00e9\u00e9n codebase, \u00e9\u00e9n operatie, duizenden of miljoenen klanten. Elke verbetering en elke beveiligingsupdate komt meteen bij iedereen terecht. Die dienst op meerdere clouds aanbieden, of zelfs in een soevereine private cloud vereist op z\u2019n minst een uitbreiding van het operationele team en vaak zelfs een apart operationeel team, eventueel met nationaliteitseisen mensen die gescreend zijn. Dat breekt de efficiency en in feite het bedrijfsmodel van SaaS. En dat is niet het enige probleem. Hier komt ook weer het beperkte security signaal besproken in de eerdere delen om de hoek kijken. Bovendien loopt een aparte instantie achter met updates, wat de kwetsbaarheid nog groter maakt. Je krijgt dan wel meer controle, maar een minder goed product tegen een hogere prijs. Soms is dat de juiste ruil, vaak niet.<\/p>\n\n\n\n

Bij SaaS is ook nauwelijks te scheiden wat je zelf in de hand hebt. Bij PaaS kun je met architectuurkeuzes nog veel regelen: open standaarden, open formaten, eigen sleutels. Bij SaaS blijft daar grotendeels het contract van over, met eigen identiteit via federatie en eigen sleutels waar de leverancier dat ondersteunt. En de spanning uit deel 5 is hier op z’n scherpst: een SaaS-applicatie die iets zinnigs met je data moet doen, zoals zoeken, analyseren of AI erop loslaten, moet die data kunnen lezen. Volledige controle over sleutels en volledige functionaliteit gaan slecht samen.<\/p>\n\n\n\n

AI: waar alles samenkomt<\/h1>\n\n\n\n

AI moet hier apart genoemd worden, omdat daar alles uit deze serie samenkomt. AI-diensten zijn er als IaaS (hardware om zelf modellen op te ontwikkelen en uit te voeren, PaaS (modellen en inference als API) en SaaS (assistenten en agents in applicaties) tegelijk. Deze diensten vereisen specifieke hardware, waarvan uit deel 3 al bleek dat die vrijwel volledig niet-Europees is. Door de hoeveelheid energie die ze gebruiken en warmte die daarbij gegenereerd wordt, hebben ze ook de modernste datacenter innovaties nodig. Innovaties die vooral gedreven worden door de hyperscale cloud providers, zoals behandeld in deel 2. De daarmee gepaarde innovatiesnelheid is waar Europa moeite mee heeft. De krachtigste modellen zijn grotendeels niet-Europees en niet zelf te draaien. En de tooling eromheen ontwikkelt zich in een tempo dat geen enkele andere dienst haalt.<\/p>\n\n\n\n

Tegelijk is AI ook een goed voorbeeld van hoe je met architectuur ruimte kunt maken. Een open-weight model in je eigen omgeving kan niet worden uitgezet, niet ongemerkt worden aangepast en niet worden ingetrokken. Voor veel toepassingen is zo’n model ruim voldoende. De afweging is dus dezelfde als overal op deze laag: het beste wat er is, of wat je in de hand hebt. En die keuze kun je per toepassing anders maken.<\/p>\n\n\n\n

De bouw<\/h1>\n\n\n\n

Voor wie een hyperscale cloud wil bieden is met name het aantal diensten en de rijkheid daarvan een uitdaging. De hyperscalers bieden honderden PaaS-diensten met een uitgebreide feature set, daar waar Europese cloud providers zich veelal beperken tot de kerndiensten uit het vorige deel en een beperkt aantal PaaS-diensten. Die set aan diensten groeit wel, maar relatief langzaam omdat voor elk van die diensten mankracht nodig is om deze te bouwen, te certificeren en te opereren. Zelfs als de dienst gebruik maakt van open source is dit niet eenvoudig, omdat je er niet zomaar vanuit kunt gaan dat alles goed is. De bouw is dus veel meer dan het installeren op een paar servers.<\/p>\n\n\n\n

Een soevereine cloud moet dus keuzes maken en kan zich daardoor alleen richten op die must-have diensten. Een soevereine cloud met tien goed beheerde diensten is beter dan een met honderd die het maar half doen, maar heeft wel het nadeel dat het moeilijker voor een derde partij om daar een SaaS-dienst op te bouwen. De meeste SaaS-diensten bouwen namelijk niet een eigen cloud, maar bouwen bovenop een bestaande cloud, omdat die een heleboel complexiteit wegneemt. Er zijn maar weinig SaaS-diensten die op verschillende clouds beschikbaar zijn, aangezien elke extra versie extra expertise en mankracht vereist, wat ten koste gaat van efficiency.<\/p>\n\n\n\n

Het goede nieuws is wel dat het greenfield-voordeel uit deel 5 hier ook geldt. Wie vandaag begint, kan portabiliteit, open formaten en crypto-agility vanaf dag \u00e9\u00e9n in het ontwerp opnemen, in plaats van ze er later in te moeten bakken.<\/p>\n\n\n\n

De operatie<\/h1>\n\n\n\n

Bij de operatie zit opnieuw de echte rekening, en op deze laag wordt die nog hoger. Elke dienst voert deels een eigen operatie met eigen experts. Een team dat een databasedienst op schaal beheert, is niet hetzelfde team dat een integratieplatform of een AI-dienst draaiende houdt. De certificeringslast kan wel bouwen op de gedeelde basis uit deel 4 en 5, maar uiteindelijk moet elke dienst afzonderlijk gecertificeerd worden. Dit betekent dat ook dit proces ge\u00efndustrialiseerd moet worden om de inspanning zo laag mogelijk te houden.<\/p>\n\n\n\n

Dit alles vereist veel (specialistische) kennis. De mensen die dit soort diensten op schaal kunnen bouwen en bedienen, zijn schaars en wereldwijd gewild. Een soevereine aanbieder concurreert om die mensen met de grootste werkgevers in de techsector. En omdat SEAL\u20114 vereist dat de operatie volledig binnen de EU en onder EU-recht plaatsvindt, is de vijver waarin gevist kan worden nog kleiner.<\/p>\n\n\n\n

Klanten hebben natuurlijk ook eisen. Van kerndiensten verwachten ze stabiliteit. Van PaaS en vooral SaaS verwachten ze vernieuwing: nieuwe functies, betere integraties en nu nieuwe AI-toepassingen. Hier zit een bedrijfsrisico in wat een vicieuze cirkel is:  een soevereine aanbieder die niet kan innoveren verliest klanten terwijl klanten juist nodig zijn voor de vereiste schaal om te investeren in de benodigde stabiliteit en vernieuwing.<\/p>\n\n\n\n

En dan is er nog het security aspect. Meer diensten betekent een groter aanvalsoppervlak en tegelijk zien we dat AI steeds sneller lekken weet te exploiteren. Dit manifesteert zich in druk op de operatie om snel en vaak (zo nodig dagelijks) te kunnen patchen. Een ander aspect is dat de datalekken waar je het meest over leest vaak veroorzaakt worden door verkeerde configuraties van software, en dat gaat dan met name over PaaS- en SaaS-diensten. Wie configuratiefouten bij duizenden klanten tegelijk ziet en kan verhelpen, heeft een voorsprong die een kleine omgeving niet heeft. Schaal is hier dus van levensbelang.<\/p>\n\n\n\n

Exit: de vraag die hier het zwaarst weegt<\/h1>\n\n\n\n

In deel 5 noemde ik portabiliteit het meest onderschatte soevereiniteitsinstrument. Op deze laag weegt het het zwaarst, omdat hier de keuzes vallen die bepalen of een exit \u00fcberhaupt kan. Praktisch komt het neer op een handvol vragen die je bij elke PaaS- of SaaS-dienst zou moeten stellen:<\/p>\n\n\n\n