Kunnen we zelf een cloud maken

Kunnen we zelf een cloud maken?

Inhoud

• Kunnen we zelf een cloud maken?
  • Inhoud
  • Tl;DR
  • Wat bedoelen we met Cloud?
    • Hyperscalers
    • Cloud Native
    • Software As A Service (SaaS)
    • Veiligheid
      • Geen garanties
  • Open Source
  • Isolatie en Identity and Access Management
  • Moet je alles bieden
  • Hoe doet Big Tech het?
    • De schaduwzijde
  • Het vijvertje
  • Andere ontwikkelingen
    • Afhankelijkheid leveranciers
    • Hacks en datalekken: verantwoordelijkeden
    • Grote ICT projecten van de overheid
  • Een staatsbedrijf?
  • Hoe dan, hoe gaan we nu zelf een cloud kunnen bouwen?
    • Een Rijksdienst voor ICT en Digitale Infrastuctuur
    • Leer van Big Tech, maar kopieer niet
  • Wakosdadan? ‘de cost gaet voor de baet uyt’
  • Kunnen we het?

Tl;DR

• Cloud in deze context: Hyperscalers
• Hyperscalers zijn voor het overgrote gedeelte zelf op Open Source gebaseerd
• Hyperscalers plakken het wel goed aan elkaar
• Hyperscalers kopen niet, ze zorgen zelf voor kennis en ondersteuning
• We hebben niet meteen de schaalgrootte nodig
• 80/20 kunnen we met 20% functionaliteit 80% van de vraag voldoen?
• Het is veel minder een technisch probleem dan dat het een organisatorisch probleem is
• Er is genoeg technisch talent als we niet allemaal in dezelfde vijver vissen.

Kunnen we zelf een cloud maken? Er zijn een aantal mythes over gigantische hoeveelheden geld die nodig zijn, over talent wat we niet voldoende hebben, over een achterstand die niet meer in te halen is. Een op alle punten gelijkwaardige cloud neerzetten is inderdaad een zeer grote uitdaging. Maar dat betekent niet dat we niet wat kunnen bouwen wat de belangrijkste diensten kan verzorgen en er voor kan zorgen dat we baas blijven over eigen data. De cloud is vooral gebaseerd op open source, dat betekent dat de componenten om het te bouwen er zijn. Maar we moeten het wel heel anders aanpakken dan we gewend zijn. We zijn teveel gewend IT te kopen. Net als de hyperscalers zullen we veel meer moeten gaan bouwen in plaats van kopen. Voor de componenten waar we op bouwen zullen we in staat moeten zijn om zelf onze broek op te houden. Dat betekent dat we zelf dermate goed deze technologie in de vingers moeten hebben dat we geen support hoeven in te kopen en in staat zijn om, indien nodig, de software te ‘forken’ en verder te onderhouden en ontwikkelen. Om dat economisch haalbaar te maken is een schaal nodig die geen enkele instantie in NL in zijn eentje aankan. Ook is er wel voldoende technisch talent in Nederland, maar niet als elke organisatie hetzelfde gaat doen. Er is wel een heel ander wijze van organiseren nodig. Er moet gebouwd worden in plaats van ingekocht. We kunnen voor wat dat betreft veel leren van Big Tech. Daar wordt een hele andere bedrijfscultuur gehanteerd. Het is een andere manier van werken, van managen, van belonen en van faciliteren van de bouwers. De invloed in het reilen en zeilen van de organisatie wordt veel meer bepaald door mensen die vol thuis zijn de techniek. Er is best ruimte voor het bedrijfsleven om bij te dragen. Maar niet zodanig dat het ‘hun’ cloud wordt, tenzij ze zelf alle initiatief naar zich toe trekken inclusief de bijbehorende risico’s. Een vergelijk met de fysieke infrastructuur valt te maken. Intussen is de digitale infrastructuur te belangrijk geworden. De fysieke infrastructuur in Nederland ligt bij Rijkswaterstaat. Zeker nu alles nog zo aan verandering en vorming onderhevig is hoort intussen de digitale infrastructuur ook bij de overheid. Rijkswaterstaat gaat over de bruggen, wegen en dijken. Aannemers mogen die wel bouwen, maar worden geen eigenaar en Rijkswaterstaat bepaalt.

Kunnen we zelf een cloud bouwen? Ja, als we niet alles willen, zeker niet op dag een. Als we een ander soort organisatie opzetten, veranderen van inkoop geörienteerde organisaties naar bouw organisaties. Maar ook als de overheid eigenaarschap neemt over de digitale infrastructuur.

Wat bedoelen we met Cloud?

Om de discussie goed te beginnen is het eerst tijd om te definieren wat we bedoelen met cloud. Dat kan, zoals zoveel in de IT, van alles betekenen. De makkelijkste en intussen sleetse grap is dat cloud enkel iemand anders zijn computer is. Om het simpel te houden leggen we hier kort uit wat we in deze context bedoelen

Hyperscalers

Als de discussie gaat over dat er te veel van onze data in de cloud staat bij partijen die niet onder Europees recht vallen hebben we het met name over de Hyperscalers als Microsoft Azure (inclusief MS 365), Amazon Webservices (AWS) en Google Cloud Platform (GCP). Dit zijn zeer grote cloud aanbieders die een publieke cloud aanbieden met belangrijke kenmerken:

• Wereldwijde schaal: ze hebben niet alleen veel datacentres, maar deze bevinden zich verspreid over de hele wereld.
• Veel verschillende soorten diensten die je ‘as a service’ kan afnemen. Je kan ze via self-service aanmaken
• Alles is volledig geautomatiseerd
• Ze bieden vooral ook high level diensten
  • (Lambda) functions
  • Database as service
  • Serverless computing
  • Kubernetes clusters
  • etc.
• Ze bieden ook volledige SaaS diensten (software as a service)

Het self-service aspect is heel belangrijk. De cloud ‘heeft geen telefoonnummer’. Het business model is dat en team dat een dienst bouwt en onderhoudt net zo makkelijk 5 klanten aan kan als een paar miljoen. Je kan wel virtuele servers bij ze afnemen, net als bij veel europese bedrijven. Maar belangrijker zijn de diensten die hoger in de stack zitten als database as service, serverless computing etc. Deze zijn heel belangrijk voor modern ontwikkelen volgens het ‘Cloud Native principe’.

Cloud Native

Een belangrijke term is de term Cloud Native. Dit is een manier om software te maken en te hosten die gebruik maakt van zogenaamde Cloud Native componenten.

• Cloud Native kan ook in eigen data centers (On-Prem). Daar hoort eigenlijk wel een eigen on-prem prive cloud bij
• Voor werken volgens DevOps principes is dit heel belangrijk. Werken volgens DevOps principes betekent dat het team dat een dienst bouwt ook verantwoordelijk is voor dat het draait in productie. Maar het is niet de bedoeling dat ze zelf servers moeten bouwen en bijhouden etc. Daarom zijn de ‘high level’ diensten heel belangrijk. Ze moeten deze, geautomatiseerd en via self-service kunnen afnemen
• Er is een onafhankelijk instituut dat als autoriteit geldt of iets Cloud Native is: The Cloud Native Computing Foundation

Voor deze discussie is dit heel belangrijk. Er zijn genoeg partijen in Europa, die vaak aangeven ook een cloud dienst te leveren, waar je weliswaar prima (virtuele) servers etc. kan huren (Iinfrastructure As A Service, IaaS), maar die niet de Cloud Native componenten as a service leveren. Als we praten over een europese cloud in deze context gaat het over een (semi) publieke cloud die een flink gedeelte van deze Cloud Native diensten levert en niet alleen IaaS.

Software As A Service (SaaS)

Een heel belangrijk deel van de diensten waardoor bedrijven en overheden aankloppen bij de publiek cloud leveranciers (Hyperscalers) zijn een aantal diensten die vaak worden aangeduid als Software As A Service (SaaS). Meest bekende voorbeelden zijn Email diensten, Office en samenwerk diensten en zelfs complete beheerde desktops. Met name Microsoft heeft diensten die door zeer veel organisaties worden gebruikt:

• Email diensten: Exchange
• MS Office en Teams in MS 365
• Azure virtual Desktops

Ook Google levert veel van dit soort diensten.

Dit zijn belangrijke diensten. Deze diensten verzorgen voor organisaties noodzakelijke diensten. Doordat ze als dienst zijn af te nemen besparen organisaties veel beheer werk.

Veiligheid

Een niet te vergeten aspect is veiligheid. Ook hier is schaal een voordeel voor de Hyperscalers. Om de systemen veilig te houden zijn een aantal aspecten van belang.

• Software telkens updaten: Uiteraard moet software continue bijgehouden worden, wat meestal wordt aangeduid met ‘patchen´. In plaats van patchen wordt steeds vaker de methode toegepast van volledig vervangen door de nieuwere versie. Maar laten we voor het gemak het houden op patchen. Dat alleen al stelt organisaties voor een uitdaging. Het kost veel tijd en verreist veel werk om goed bij te houden waar wat draait en het bij te houden.
• Monitoring en detectie: Veiligheid gaat niet alleen om afscherming en firewalls. Heel belangrijk is het goed in de gaten houden van al het verkeer, detecteren van issues en razendsnel reageren.
• Talent: veiligheid (security) experts zijn er niet veel. En hier telt ook nog eens dat de kwaliteit van de experts heel belangrijk is. Een aanvaller hoeft maar een keer succesvol te zijn en een gaatje te vinden. De verdedigers mogen geen fouten maken om geen gaatjes te laten zitten. Voor 95% veilig zijn heeft geen zin als in de 5% waar je niet aan toe kwam of waar je fouten hebt gemaakt de gaten zitten waar de aanvallers doorheen komen.

De schaal van de publieke cloud aanbieders is hierbij een groot voordeel. Ze kunnen de kosten van het aantrekken van de beste en genoeg mensen verdelen over de grote hoeveelheid van afnemers. Juist als het om veiligheid gaat houden we systemen niet met de hand in de gaten. Het team zorgt vooral voor de juiste inrichting van de systemen. Of je nu voor een server de regels in de monitoring opstelt of voor misschien wel miljoenen maakt voor het opstellen van de regels niet veel uit. De publieke cloud providers hebben de schaal om genoeg mensen aan te trekken en kunnen ook genoeg bieden om de beste mensen aan te trekken. Vandaar dat vaak geroepen wordt, met reden, dat je niet op kan tegen het niveau aan veiligheid dat de grote jongens kunnen bieden.

Geen garanties

Toch zie je nog vaak dat er hacks of datalekken voorkwamen bij organisaties die hun applicaties in de publieke cloud draaien. Hoe je de diensten gebruikt is namenlijk van onverminderd belang. Een bekend voorbeeld is het opslaan van data in bijvoorbeeld S3 buckets zonder in te stellen dat deze bucket niet open staat voor de hele wereld. S3 buckets kunnen heel veilig gebruikt worden, maar je moet het wel goed instellen. De cloud leveranciers leveren de mogelijkheden om heel veilig te werken, maar je moet het wel inzetten en op de juiste manier.

Open Source

Opvallend genoeg zijn de meeste diensten die de cloud leveranciers bieden gebaseerd op open source. Als de diensten die ze aanbieden niet op open source zijn gebaseerd zijn ze meestal zelf de eigenaar. Bijvoorbeeld MS365, dat is niet op open source gebaseerd, maar Microsoft, die deze dienst aanbiedt en koppelt aan haar eigen Cloud dienst Azure, is eigenaar van dit product.

Toch is het merendeel gebaseerd op open source. Als je een database as a service dienst als Aurora (van Amazon/AWS) dan is onder de motorkap dat gebaseerd op MySQl en PostgreSQL. Daarnaast is het zelfs vrij normaal voor de hyperscalers om nieuwe technologie te ontwikkelen en al dan niet meteen open source te maken. Intussen belangrijke technologie als Kubernetes en de programeertaal Go zijn bijvoorbeeld door Google gemaakt.

Je zou dus zeggen dat, omdat het meeste is gebaseerd op open source we ze niet echt nodig hebben en het nog prima zelf kunnen doen. Daar zit een kern van waarheid in. Je kan nog steeds een paar servers kopen, daar Talos op zetten wat er voor zorgt dat Kubernetes goed draait en dan wat je nodig hebt aan software als databases, webservers etc. daarop installeren. Dan doe je het niet eens ouderwets. Door het te baseren op Kubernetes doe je dit niet eens op een ouderwetse manier. Maar dan moet je dat wel:

• allemaal zelf opzetten
• er verstand van hebben zodat als er iets stuk gaat je het zelf kan oplossen
• continue bijhouden
• de veiligheid garanderen door alle maatregelen die je moet treffen
• voor backups zorgen
• monitoring inrichten
• je bed uit worden gebeld omdat een webserver er mee stopt
• etc.

De meerwaarde die de cloud dan levert is dat dit allemaal voor je wordt gedaan. Vaak wordt als voordeel van de cloud aangegeven dat je makkelijk kan op- en afschalen. Dat is maar zelden echt belangrijk. Het belangrijkste is dat heel veel voor je wordt gedaan, dat je veel minder kennis in huis hoeft te hebben en je kan concentreren op wat jouw applicatie of website specifiek maakt. Als je bijvoorbeeld PostgreSQL gebruikt als database en daarvoor aurora gebruikt hoef je geen verstand te hebben van hoe het werkt, je hoeft niet voor backups te zorgen en mocht het al een keer stuk gaan dan is AWS degene die het moet repareren. Daarnaast heeft het ook nog eens veel betere performance dan wat je zelf logischer wijze kan doen.

Waar het om gaat is dat de componenten die nodig zijn om diensten te leveren om een alternatief te bieden voor de hyperscalers er wel zijn. Wat ze echter ook nog doen is:

• Ze ‘lijmen het aan elkaar’ tot een volledig product.
• Ze zorgen dat ze zelf zoveel kennis in huis hebben over de software dat ze zelf geen ondersteuning nodig hebben. Dat gaat zover dat ze in ieder geval in staat zijn zelf wijzigingen aan te brengen in de broncode maar evengoed dragen ze nog wel eens bij aan de ontwikkeling van de software.
• Ze verzorgen volledig het beheer (geautomatiseerd). Zij zorgen voor backups, georedundantie als je dat wil, tuning van performance, veiligheid, updates, veiligheid etc.

Om een alternatief te bieden moet dat minimaal geleverd worden. Je zal dus zorg moeten dragen dat je voor alle diensten die je aanbiedt, ofwel alle (open source) componenten, teams opbouwt met engineers die zo goed thuis zijn in de broncode dat ze zelf problemen kunnen oplossen en nieuwe features kunnen toevoegen. Daarnaast moeten ze automatisering maken zodat het volledig via self-service afgenomen kan worden, updates plaats kunnen vinden zonder downtime, op meerdere locaties kan draaien (geo-redudant), backups geregeld (die via self service ook nog eens instelbaar zijn en gebruikt kunnen worden), technische en security monitoring zijn ingericht etc.

En dan moet dat ook nog alles een geheel worden. Het zijn niet allemaal losse diensten, binnen de cloud dienst moet alles wat je aanbiedt op een eenduidige manier aangeboden worden. Als je een GUI gebruikt moet je alles vanuit die GUI op een consistente manier kunnen gebruiken. Het moet niet zo zijn dat je telkens op een andere site terecht komt waar alles weer op een andere manier werkt.

Dit wijkt zeer sterk af van hoe IT-ers, beheerders, normaal werken. Natuurlijk automatiseren ook zij, zorgen voor backups en monitoring etc. Maar updates worden verschaft door een leverancier in installeerbare pakketjes met indien nodig instructies erbij. Als het goed mis gaat worden tickets aangemaakt bij leveranciers die een oplossing leveren. Kern van het verhaal: we zijn gewend software te kopen. Zelfs als het gaat om open source software, nemen we vaak betaalde licenties of support af. Dat is terecht als je alleen aan je eigen organisatie levert. Dan is het niet haalbaar en niet economisch om zoveel kennis zelf in huis te halen. Je zou nog steeds je diensten kunnen aanbieden op basis van licenties en support die je bij leveranciers afneemt. Dat levert alleen serieuze risico’s op door de afhankelijkheid die je daarmee creëert en is als je aanbiedt op significante schaal ook financieel ongunstig. Samengevat moet je veel kennis in huis halen en daarvoor heb voldoende schaal nodig om het rendabel te maken. Dat hoeft niet persé net zo’n grote schaal te zijn als voor hyperscalers, maar wel groter dan wat een enkele grote organisatie nu zelf heeft.

Er valt nog veel meer te zeggen over dit onderwerp zoals hoe je, zeker als overheid, je opstelt in de community. Voor deze discussie houden we het hier even bij.

Isolatie en Identity and Access Management

In IT is isolatie een begrip dat steeds belangrijker wordt, maar voor een cloud aanbieder een vereiste. Waar het op neer komt is dat als je als klant iets afneemt bij de cloud, je er volledig van moet kunnen uit gaan dat andere klanten niet bij deze applicatie en data kunnen. Sterker nog, je hebt garanties nodig dat zelfs de medewerkers van de cloud leverancier er in ieder geval niet zomaar bij kunnen. Er zijn zelfs mechanisme zoals versleuteling (encryptie) van de data met sleutels die in beheer zijn bij de klant zelf waardoor het zelfs voor de cloud aanbieder zeer moeilijk wordt om de data van de klant te kunnen lezen. Belangrijk is echter dat isolatie volledig ingebouwd moet worden. Als voorbeeld, je moet niet alleen database as a service bieden, maar deze database moet ook nog zodanig geisoleerd zijn dat alleen bereikbaar is in segment van de klant.

Daarnaast is ook moderne authenticatie van belang. Het is al een tijd gebruikelijk dat je niet voor elke applicatie aparte inloggevens nodig hebt. Waar dat vaak werd ingevuld door gebruik te maken van ‘de windows user´, ofwel AD, wordt nu bij voorkeur van nieuwere methodes gebruik gemaakt. Het is niet alleen voor de gebruiker fijn dat deze met dezelfde gegevens toegang krijgt, het is ook voor de veiligheid van belang. Het is veel beter te regelen dat er geen accounts per ongeluk actief blijven als iemand vertrekt, ook zijn extra maatregelen te treffen zoals in beheer dat iemand tijdelijk een rol aanneemt met meer rechten in plaats van het permanent toekennen van deze rechten. Rapportage over toegang die er is wordt sterk verbeterd. De mens levert nu eenmaal het grootste risico. Moderne toegangsmethodes bevatten meer beveiliging naast de intussen al als standaard bekende multifactor maatregelen. Dit is een groot onderwerp wat valt onder de noemer Identity and Access Management (IAM).

Het volstaat dus niet om een verzameling van diensten te hebben zonder dat je kan garanderen dat je als klant in eigen stukje van de cloud zit en moderne IAM mogelijkheden zijn ingebakken.

Moet je alles bieden

Als je het portfolio bekijkt van de hyperscalers is goed te zien dat ze niet stil hebben gezeten. De ‘As a Service’ catalogus is uitgebreid, je kan virtueel complete datacentres bouwen met alle netwerkdiensten, AI toepassingen, serverless diensten etc. En dat is ook nog eens allemaal eenvoudig af te nemen en in je eigen automatisering op te nemen. Maar ben je pas een alternatief als je een gelijkwaardig portfolio hebt en het hele zogenaamde CNCF landscape kan aanbieden?

De meeste bedrijven hebben zeker niet alles nodig. En degenen die wat minder gebruikte componenten gebruiken kunnen daarvoor vaak of een alternatief gebruiken of dit component dan toch zelf hosten (op dezelfde cloud). Weliswaar niet as a service, maar toch nog relatief eenvoudig. Het is van belang om de belangrijkste componenten die organisaties naar de cloud trekken te definieren. Daarnaast geldt vooral dat de basis op orde moet zijn. De laag die alles aan consistent elkaar verbindt, isoleert, IAM en veiligheid goed organiseert moet er zijn en met een beperkt, maar cruciaal portfolio is er redelijk snel een alternatief te bieden.

Zonder hier uitgebreid onderzoek naar te hebben gedaan lijken de volgende componenten al snel belangrijk:

• Container hosting, minimaal Kubernetes, maar ook CloudFoundry
• Database as a Service: minimaal PostgreSQL, MySQL/MariaDB, Elasticsearch, MongoDB
• Messaging zoals RabbitMQ
• Een MS Office en teams alternatief als Nextcloud
• Virtual servers met meegeleverde OS-en in meerdere Linux distributies
• Virtuele werkplekken
• Email en agenda diensten die kunnen concurreren met MS Exchange (b.v. Open Xchange)
• Versiebeheer en CI/CD tooling (b.v. Gitlab)

Deze componenten nemen in het kielzog al automatisch weer extra diensten mee. Zo zal je voor Kubernetes een eigen image registry moeten kunnen afnemen. En ongetwijfeld roept deze lijst commentaar op van andere componenten die absoluut ook belangrijk zijn, zowel terecht als onterecht. Maar met een relatief kleine lijst is er al een alternatief waarmee gestart kan worden om dat waarvan we vinden dat het echt op souvereine cloud hoort te draaien er op kan draaien. In het begin zal het zeker een achteruitgang betekenen voor de moderne cloud native ontwikkelaars dat de snoepwinkel een stuk leger is en ze meer zelf moeten doen. Een rendabel alternatief geeft ruimte om snel het portfolio uit te breiden en daarbij goed te kijken naar de vraag.

Hoe doet Big Tech het?

Werken voor Big Tech is aantrekkelijk. Als er een vacature is krijgen ze veel respons. Ze nemen alleen de echte top aan. Het komt zelfs voor dat ze lang blijven zoeken, ondanks veel reacties, omdat ze dan toch nog niet de juiste kandidaat hebben gevonden. Het is dan ook min of meer een eretitel als je ooit voor Big Tech hebt gewerkt. Veel oudwerknemers van bijvoorbeeld Google duiden zichzelf aan als Xoogle.

Bekend zijn de verhalen over de werkomgeving bij Big Tech. Uiteraard is het salaris hoog om de mensen aan te trekken, maar ook voordelen zoals gratis en uitstekend eten, hele goede koffie en andere faciliteiten als fitness zalen, creatieve ruimtes, ruimtes waar gegamed kan worden of ping pong. Niets lijkt te gek te zijn en dit soort locaties worden dan ook vaak aangeduid als een campus omdat het niet zomaar kantoorgebouwen zijn maar waar de hele omgeving meetelt en vaak van het bedrijf is. Het zijn vaak ruime terreinen met meerdere gebouwen en faciliteiten. Het contrast met veel organisaties kan bijna niet groter. Daar worde teams in een saaie kantooromgeving geplaatst, ergens waar nog ruimte was. Er is een koffieapparaat en je mag onder geen voorwaarde je eigen koffiemachine op je werk zetten. Ook werkaanvragen als een goede monitor, een whiteboard kunnen lang op zich laten wachten als ze al worden goedgekeurd. We vinden het heel normaal om monteurs, magazijnmedewerkers, bouwvakkers speciale voorzieningen te geven zoals schoenen met stalen neuzen, veiligheidsvesten en helmen. Maar IT-personeel moet het doen met standaard kantoorvoorzieningen.

Als je top talent aantrekt volstaat het niet met een concurrerend salaris. Ze hebben de juiste voorzieningen nodig om goed te werken. Bij Big Tech is dat voor elkaar. Ze creëren bewust omgevingen waar je wil werken. Waar je goed kan werken omdat je als dat nodig is even kan terugtrekken, of juist met je collega’s in een kamer met alle faciliteiten rond een whiteboard staan of een ommetje maken in een leuke omgeving.

Een ander aspect, wat al terugkomt in de hoogte van het salaris wat ze bieden, is dat je om te groeien in zo’n bedrijf geen manager hoeft te worden. Het zou normaal moeten worden dat de toptechneuten in een bedrijf meer verdienen dan hun eigen managers. Dat is nu juist helemaal niet normaal. Er zijn genoeg voorbeelden van goede techneuten die ‘doorgroeien’ naar management omdat ze tegen de plafonds aanlopen van wat bedrijven als salaris bieden. Het is soms nagenoeg absurd om te moeten vaststellen dat we een manager van een team eenvoudiger kunnen vervangen dan de senior techneuten, maar dat we niet bereid zijn die techneuten beter te compenseren vanuit het achterhaalde idee dat managers altijd meer moeten verdienen.

De schaduwzijde

Er zit wel een schaduwzijde aan die mooie beelden van de werkomgeving bij Big Tech. Het verloop van personeel schijnt erg hoog te zijn. Aan de ene kant komt dat doordat als je op je CV hebt staan dat je voor een van deze bedrijven hebt gewerkt je heel goed in de arbeidsmarkt ligt en dus niet alleen genoeg aanbod hebt, maar ook wat kan vragen. Een ander aspect is dat al die voordelen van de werkomgeving bij Big Tech vooral ook bedoeld zijn om je door te laten werken. Als je op je werk beter kan ontbijten, lunchen en avondeten dan wat je zelf kan verzorgen wordt het aantrekkelijk lange dagen te maken. De werkdruk en verwachtingen die aan je gesteld worden zijn niet mals.

Het vijvertje

“We zijn te klein, er is te weinig talent in Nederland en die zijn al vertrokken”. Er is een soort van mythe dat je een soort godenzonen nodig hebt om dit soort clouds te bouwen. Dat beeld zal wel mede gevoed zijn door juist die hoge salarissen en verwennerij voor de techneuten op de campus. Toch lijkt dat overdreven. Ook in Nederland is het talent echt wel aanwezig. Om dat goed in te zetten moeten wel een paar dingen goed regelen

• leer van Big Tech over hoe je een omgeving opzet waarin ze optimaal kunnen werken. Het is geen wedstrijdje wie de beste voorwaarden kan scheppen, maar wel moeten we af van het wegstoppen in saai hoekje
• wees rigoreus en trek alleen echt talent aan. Ook hier kunnen we een les leren van Big Tech: geen compromis over wie je aanneemt, het is niet goed voor de prestaties. Er zal altijd verschil zijn in ervaring, kennis en ook talent. Er mag zeker wel talent bij met nog weinig ervaring, maar het niveau moet wel ongeveer gelijk zijn.
• de ‘vijver’ is echter ook weer niet heel groot. Het lijkt beter om er voor te zorgen dat er niet teveel intiatieven zijn

Het lijkt daarmee logisch om een nieuwe organisatie op te richten die uiteindelijk iets maakt die in staat is om meerdere organisaties te bedienen in plaats van dat organisaties zoiets voor zich zelf gaan doen, daarover later meer.

Andere ontwikkelingen

Er zijn nog een paar ontwikkelingen die bedrijven hebben wakker geschud.

Afhankelijkheid leveranciers

De bedrijven zijn steeds afhankelijker geworden van bepaalde leveranciers. Er zit zeker een logische redenering achter om in je bedrijf te standardiseren op een bepaalde techniek of software. Maar je afhankelijkheid wordt groter en wel zodanig dat je niet zo maar van leverancier kan veranderen. Door onder andere overnames zien we leveranciers de prijzen sterk verhogen, leveringscondities wijzigen en soms zelf besluiten bepaalde markten niet meer te bedienen. Gevolg is dat als je het ‘nog zelf doet’ en niet alles in de publieke cloud hebt draaien je alsnog een grote afhankelijkheid hebt van een of meer leveranciers. Gevolg is dat allerlei organisaties op zoek zijn naar alternatieven en ook daar behoefte ontstaat om minder een organisatie te zijn die IT inkoopt en meer een organisatie die in staat is zelf de belangrijkste IT componenten voldoende zelf te beheersen.

Hacks en datalekken: verantwoordelijkeden

Daarnaast worden we steeds vaker opgeschrikt door hacks en datalekken. De wetten worden strenger en mensen en bedrijven worden steeds strenger verantwoordelijk gehouden. Er moet worden voldaan aan iso standaarden, overheidsonderdelen moeten voldoen aan de Baseline Informatiebeveiliging Overheid (BIO). Alleen is dat complex. In plaats van aan alle punten te voldoen geldt ook het mechanisme ‘comply or explain’. Als je niet of niet goed kan voldoen aan de vereisten, kan je ook bewust niet voldoen met een verklaring (explain). Dat heeft al tot de gevleugelde uitspraak geleid “heb jij je explain al”.

We kunnen besmuikt lachen op dat er geen moeite meer wordt gedaan om te voldoen en de ontsnapping van een explain te gebruiken. De werkelijkheid is dat het best complex is en vaak niet haalbaar om te voldoen. Als we echter er voor zorgen dat naast eisen die we stellen ook de middelen om te voldoen goed beschikbaar te maken wordt dat anders. Geef naast een eis meteen een goede oplossing mee en het wordt makkelijker om te voldoen dan om ‘je explain’ te halen. Uiteindelijk zitten er ook weer eisen aan de explain en wil men liever rapporteren dat er wordt voldaan dan waarom er niet kan worden voldaan.

Grote ICT projecten van de overheid

De overheid heeft helaas te kampen met geen goede reputatie als het gaat om ICT projecten. De roep om een minister van ICT die veel te horen is en niet nieuw komt niet alleen voort uit de vraag naar een souvereine cloud. Er is behoefte aan betere controle op ICT in de overheid.

Een staatsbedrijf?

Dan het grote dilemma: wie zou een Europese of Nederlandse cloud kunnen maken. Hier zie je al snel politieke kleur terug komen in discussie. Er bestaat soms nog een rotsvast geloof in dat het bedrijfsleven veel efficienter werkt dan de overheid iets laten doen. Toch is ervaring om grote ICT projecten door bedrijven laten uitvoeren niet goed. Dat ligt aan beide partijen. Grote ICT projecten zijn zeer complex met nog veel onzekerheden. Om die goed aan te besteden is onrealistisch complex. Een ander probleem is dat de grote IT-bedrijven meer ingericht zijn op het leveren van uren dan producten. Voor zover zij diensten leveren als hosting leveren ook zij die op basis van software die ingekocht wordt.

Door de overheid zelf laten doen klinkt al snel als een staatsbedrijf. Dat klinkt nog erger dan de bouw van een cloud aanbesteden aan de markt. Toch is dat, zeker in het verleden, niet altijd verkeerd gegaan. Veel diensten die belangrijk zijn in ieder geval ontstaan vanuit de overheid. Nuts bedrijven als elektriciteit en water zijn heel lang een overheidsaangelegenheid geweest. En de fysieke infrastructuur als dijken, wegen en bruggen laten we nog steeds niet zo maar over aan de markt. We laten het ook niet over aan een ministerie, daarvoor hebben we Rijkswaterstaat. Hoewel rijkswaterstaat veel werkzaamheden aanbesteed, zijn ze zelf nog eigenaar en verantwoordelijk voor de infrastructuur. Ze besteden wel veel uit, maar hebben wel de kennis in huis om precies te weten wat ze vragen. Er is een ingenieurs cultuur. Ministeries maken beleid, wetten en verdelen geld maar ze bouwen geen wegen en dijken. De fysieke infrastructuur beschouwen we als belangrijk genoeg om een instituut als rijkswaterstaat voor te hebben. We kunnen ons niet veroorloven dat dijken verwaarloosd worden.

“Ministeries maken beleid, wetten en verdelen geld maar ze bouwen geen wegen en dijken.”

In 2012 schreef Richard A. Clarke in zijn boek Cyber War dat er teveel gekeken wordt naar hoe goed je als land bent op het gebied van aanvals en verdedigings vermogen als het gaat om ‘cyber’ veiligheid. Men vergeet het aspect: hoe afhankelijk ben je van de digitale infrastructuur. Simpel voorbeeld, de V.S. is zeer capabel. Daarbij vergeleken stelt een land als Afghanistan niet veel voor. Maar tegelijkertijd is dat land ook niet zo sterk afhankelijk van digitalisering dus raak je ze niet echt. Omgekeerd is de V.S. wel afhankelijk. Voor Nederland geldt dat even goed. We zijn een dicht bevolkt land dat voor de welvaart een grote afhankelijkheid heeft van de dienstensector. En juist daar is digitalisering van groot belang. De digitale infrastructuur is daarmee ook van groot belang geworden voor Nederland en zouden we net zo serieus moeten nemen. Dit pleit er voor om analoog aan Rijkswaterstaat een Rijksdienst voor ICT en Digitale infrastructuur op te richten. Niet alleen voor de ICT van de overheid moet we de afhankelijkheid verminderen, ook de bedrijven die voor de welvaart zo belangrijk zijn zouden moeten kunnen kiezen voor een betrouwbare infrastructuur, betrouwbaar voor zowel veiligheid als dat ze kunnen vertrouwen dat de diensten geleverd blijven worden en de voorwaarden niet zomaar drastisch veranderen als een leverancier dat besluit.

Mede gezien hoezeer schaal een rol speelt zou idealiter een alternatief voor de Hyperscalers een Europees intitiatief moeten zijn. In je eentje ga je sneller, samen kom je verder. Gezien de urgentie lijkt dat snelheid maatgevend moet zijn wat pleit om in ieder geval nationaal te starten gericht op integratie met Europese initiatieven als dat zover is..

Hoe dan, hoe gaan we nu zelf een cloud kunnen bouwen?

Er wordt al lang over gepraat over een souvereine cloud in wat voor vorm dan ook. En veel partijen zijn voor. Maar concreet gebeurd er nog niets. Hoe kunnen we alles op een rij zettende nu concrete stappen zetten.

Een Rijksdienst voor ICT en Digitale Infrastuctuur

Een minister van ICT toevoegen kan geen kwaad. Alleen bouwen ministeries geen clouds, net zo min als ze dijken bouwen en wegen. Daarom is als we het vanuit de overheid nu willen oppakken de start om¨

• een rijksdienst voor ICT en Digitale infrastructuur op te richten
• die verantwoordelijk te maken om een rijkscloud te maken die uiteindelijk ook beschikbaar komt voor niet overheidsorganisaties
• die verantwoordelijk wordt voor de ICT van overheidsinstellingen.
• waar ook het management voor tweederde bestaat uit mensen met aantoonbare technische achtergrond

Leer van Big Tech, maar kopieer niet

Een cloud bouwen gaat dus heel anders en is niet meer een kwestie van IT inkopen. We kunnen veel van Big Tech leren en hoeven veel niet opnieuw uit te vinden. Tegelijk moeten we niet exact hetzelfde doen. Er is genoeg op aan te maken. Wat wel zou moeten is:

• een campus opzetten voor de organisatie die gaat bouwen
• trek top talent aan zonder compromis
• waardeer het technisch werk, een manager hoeft niet meer te verdienen
• schep de omstandigheden dat deze mensen goed kunnen werken
• ‘think big, start small’
• bouw een goede basis
• lever eerst het hoogst noodzakelijke
• zorg dat de kennis van de componenten wordt opgebouwd dat zonder externe ondersteuning we dit kunnen draaien

Wakosdadan? ‘de cost gaet voor de baet uyt’

Terecht wordt dan al snel de vraag gesteld naar wat dat allemaal niet moet kosten. Om te beginnen zijn we nu al veel geld kwijt en verspillen we vooral veel geld door moeizame trajecten. Ook gaat er nu veel geld naar al die diensten en software die we nu inkopen. Toch moeten we niet vergeten dat er eerst substantieel geld moet worden uitgegeven voordat het gaat opleveren. En met een verleden van veel mislukte grote projecten is het niet zo simpel. Er zijn alleen wel wat mogelijkheden om de risico’s te beperken. In de bouw is er bij hoogbouw is het mogelijk om, terwijl de hogere verdiepingen nog lang niet klaar zijn, de eerste verdiepingen alvast te vehuren. Hoe eerder er inkomsten zijn hoe haalbaarder het wordt. Dat is hier ook te doen. Start met een beperkte basis. Ga pas als de basis draait uitbreiden en/of op schema ligt uitbreiden met teams voor meer diensten. Start in bestaande (overheids) datacenters.

Kunnen we het?

We moeten het kunnen. En als we ons goed realiseren dat we het heel anders moeten benaderen, leren of afkijken bij Big Tech en onder ogen zien dat lang niet iedereen die nu een succesvolle carriere heeft in de IT voldoet kan het ook. De techniek is niet eenvoudig maar niet de grootste uitdaging. De uitdaging is de organisatie .