Het kabinet kiest voor een zo soeverein mogelijk ingerichte cloudomgeving die onder centrale regie wordt opgezet. Waar mogelijk wordt deze overheidsclouddienst ondergebracht in de eigen datacenters van het Rijk. Uiterlijk eind dit jaar kunnen de eerste applicaties op de soevereine cloud worden gehost.
Staatssecretaris Eric van der Burg (Koninkrijksrelaties en Slagvaardige Overheid) meldt dat in een brief aan de Tweede Kamer. Het gebruik van Amerikaanse cloudaanbieders zoals Microsoft Azure wordt daarmee op minder vanzelfsprekend.
Op advies van Gartner heeft Nederland gekozen voor het meest vergaande scenario: een volledig nieuwe, centraal aangestuurde overheidscloud die los van de bestaande systemen wordt opgebouwd. Volgens Gartner is dit tevens de meest kansrijke route. Alternatieve scenario’s kennen een langere doorlooptijd en dragen minder bij aan de opbouw van kennis en expertise binnen de overheid.
De keuze voor maximale soevereiniteit betekent dat de overheid zowel praktisch als juridisch beschikt over de hardware, de fysieke toegang en de locatie. Dit sluit samenwerking met de markt niet uit. Inbreng van expertise vanuit de markt is noodzakelijk; de manier waarop dat gebeurt, wordt de komende maanden uitgewerkt. Technologie en exploitatie komen volledig onder EU-controle te staan. Ze zijn uitsluitend onderworpen aan EU-wetgeving en kennen geen kritieke afhankelijkheden van niet-EU-landen. Nederland kiest daarmee voor de hoogste categorie soevereiniteit (Seal4) uit het EU Cloud Sovereignty Framework.
Eerste ontwerp
Samen met experts uit de overheid wordt een eerste ontwerp van een soevereine clouddienst opgesteld. De focus ligt op een containerplatform dat voldoet aan de Haven-standaard. Het ontwerp wordt gebaseerd op open source (open en vrij beschikbare broncode), waardoor de afhankelijkheid van leveranciers afneemt.
Vervolgens wordt het ontwerp gerealiseerd in een proof of concept. Hiervoor wordt gebruikgemaakt van bestaande innovatievoorzieningen, waaronder Digilab. De soevereine clouddienst wordt daarna verder ontwikkeld; het ontwerp zal binnenkort openbaar worden gemaakt. Ook andere partijen, zoals onderwijs- en kennisinstellingen, kunnen bijdragen aan de doorontwikkeling en er zelf gebruik van maken.
Voor de opschaling naar grootschalige productieomgevingen wordt een sourcingtraject gestart. Daarbij worden naast overheidsorganisaties ook marktpartijen betrokken. Parallel aan de technische opschaling wordt een voorstel uitgewerkt voor een leverings- en serviceorganisatie, met bijzondere aandacht voor overheidsbrede dienstverlening. Daarbij wordt bekeken of deze organisatie een publiek, privaat of hybride karakter krijgt.
Financieel valt er nog veel te regelen. Van der Burg merkt op dat een overheidsbrede soevereine clouddienst alleen succesvol kan zijn als voldoende overheidsorganisaties er gebruik van maken. Bovendien zullen zij hun bestaande infrastructuurbudgetten moeten inzetten voor de bekostiging van deze clouddienst. Volgens de staatssecretaris wordt de transitie aanzienlijk complexer en duurt zij langer als de eenmalige opstartkosten niet vooraf worden gefinancierd. De financiering van de soevereine overheidscloud wordt in de volgende fase verder uitgewerkt.
Goed initiatief. Nu alle cloud contracten met Microsoft en Amazon opzeggen en alle software overzetten.
Te beginnen met e-mail en andere communicatie platformen binnen de overheid!!!
Tevens dit nieuwe cloud platform hernoemen naar RCC (Rijks Computer Centrum of Rijks Cloud Centrum) en Logius, SSS en al die andere IT toko’s opheffen en daar onderbrengen.
Als de overheid zelf SaaS-achtige diensten gaat leveren, wordt “uitwisselbaarheid van hostingproviders” een nog smaller argument dan het al was. In de gemeentelijke praktijk zit de afhankelijkheid zelden primair bij de hostingprovider. Daar bemoeit de ontwikkelaar zich mee. Voor zover het alleen om deployment gaat, kan een ontwikkelaar doorgaans probleemloos naar verschillende omgevingen uitrollen. De echte afhankelijkheid zit bij de applicatie. Zelf het aan/uit-knopje beheren, is verre van handig. Dan kun je beter dingen toch op virtualisatie-niveau gaan regelen. Daar komen ook al die aan Kubernetes toegerekende voordelen trouwens vandaan. NIet van Kubernetes.
Azure en AWS zijn bovendien allang geen “webapplicatie-hosters” meer. Containers voor webapplicaties zijn bij hyperscalers slechts één (probleemloze) categorie binnen een veel breder dienstenpakket. Waarom beginnen bij containerisatie?
In een aanbesteding heb je uiteindelijk meer aan aantoonbare exit, overdraagbare data, documentatie en beheerbaarheid dan aan een verklaring dat de onderliggende containeromgeving aan Haven voldoet. Het is zoiets als zeggen dat de pc minimaal 2 cores moet hebben, 4 GByte RAM en 500GB opslag.
Overigens is de capaciteit van tegenwoordige hyper conversed clusters werkelijk beestachtig (mits je weet wat er terecht en onterecht draait). Voor een paar ton kun je alle webapplicaties van Gemeenten al voor half Europa draaien. Dat stel echt helemaal niets meer voor.
Die “aantoonbare exit” en “overdraagbare data” zijn papieren waarborgen waar men gezien de enorme lock-in vrijwel nooit gebruikt van maakt (of als de ramp zich al voltrokken heeft).
Dit zijn termen die stromannen van de grote hyperscalers graag gebruiken maar feitelijk zeggen die “laat alles gewoon bij het oude” (lees: blijf lekker afhankelijk van ons, lever ons woekerwinsten op en leef gewoon met het feit dat we elk moment je data kunnen opeisen of de stekker eruit kunnen trekken).
“Die “aantoonbare exit” en “overdraagbare data” zijn papieren waarborgen waar men gezien de enorme lock-in vrijwel nooit gebruikt van maakt (of als de ramp zich al voltrokken heeft).”
Ja toch? 😁
Dus dat ben je geheel met me eens.
Al helemaal als je met die Haven-compliancy dan nog kunt waarborgen dat je een container kunt overnemen terwijl je de sowieso al kon.
Ik heb van converged conversed gemaakt. Maar het kan ook de spellchecker geweest zijn. Ik schreef het concept in een mailtje. 😄
De meeste web browsers hebben ook spelling checkers tegenwoordig.