Veel organisaties beginnen met cloudgebruik zonder duidelijk plan: een team zet een account aan, een ander team volgt, en voordat iemand het in de gaten heeft draaien er tientallen projecten zonder gezamenlijke structuur. Dat werkt in het begin prima, maar wie later structuur wil aanbrengen, ontdekt al snel dat losse projecten lastig samen te voegen zijn. Een doordachte cloudbasis, met heldere afspraken over inrichting, toegang en beheer, voorkomt dat een organisatie achteraf moet opruimen wat in de haast is opgebouwd.
Met een cloudbasis, vaak een landing zone genoemd, wordt de onderliggende structuur bedoeld waarop alle overige clouddiensten worden gebouwd. Denk aan netwerkinrichting, toegangsbeheer, budgetbewaking en beveiligingsbeleid, allemaal vooraf vastgelegd in plaats van per project opnieuw uitgevonden. Een organisatie die dit overslaat, loopt het risico dat elk team zijn eigen regels hanteert. Het ene project gebruikt strikte toegangsrechten, het andere nauwelijks, en niemand heeft meer overzicht over wie waar bij kan.
Zonder gedeelde basis ontstaan al snel losse omgevingen die niet op elkaar aansluiten. Kosten lopen uiteen omdat niemand centraal bijhoudt welke resources nog nodig zijn, en verouderde testomgevingen blijven soms maanden actief zonder dat iemand het opmerkt. Ook beveiliging wordt lastiger: een netwerkconfiguratie die in het ene project logisch leek, blijkt in het andere project een zwakke plek te zijn. Bedrijven die dit achteraf oplossen door alsnog een architectuur te bouwen rond wat al bestaat, merken dat migreren en herstructureren aanzienlijk meer tijd kost dan wanneer die keuzes vooraf waren gemaakt. Leveranciers die zich toeleggen op cloud foundation services helpen organisaties juist om die basis vooraf goed neer te zetten, met landing zones die zijn opgebouwd volgens vaste best practices in plaats van losse aannames per project. Ook een audit van een bestaande omgeving valt hieronder, zodat risico's zichtbaar worden voordat ze tot een incident leiden.
Een cloudbasis draait niet alleen om techniek, maar ook om afspraken: wie mag nieuwe resources aanmaken, welk budget hoort bij welk team, en hoe wordt gecontroleerd of beleid wordt nageleefd. Dat heet doorgaans governance, en het is precies het onderdeel dat bij snelle groei als eerste wordt overgeslagen. Infrastructure-as-code, waarbij de inrichting van de cloudomgeving als broncode wordt vastgelegd en via een pipeline wordt uitgerold, maakt dit soort afspraken herhaalbaar en controleerbaar. Wijzigingen zijn dan te herleiden, te herzien en desnoods terug te draaien, in plaats van dat iemand handmatig instellingen aanpast die later niemand meer kan verklaren.
Niet elke organisatie begint bij nul. Veel bedrijven hebben al een cloudomgeving die in de loop van jaren organisch is gegroeid, met wisselende eigenaren en weinig documentatie. Voor die situaties bestaat een tussenweg: een beoordeling van de bestaande inrichting op risico's en misconfiguraties, gevolgd door een gerichte aanpak om de boel op orde te krijgen zonder alles opnieuw te hoeven bouwen. Dat is vaak realistischer dan in één keer volledig migreren, en het geeft een organisatie de kans om prioriteiten te stellen: eerst de grootste risico's wegnemen, daarna de rest structureren.
Crystalloids richt zich sinds 2006 vanuit Rotterdam op data, AI en cloudinfrastructuur en werkt als Google Cloud Premier Partner met organisaties die hun cloudomgeving willen structureren of migreren. De aanpak daar laat zien dat een cloudbasis niet iets is wat je er later bij verzint, maar het uitgangspunt waarmee je begint, of het nu gaat om een compleet nieuwe omgeving of om orde scheppen in een bestaande. Wie hiermee te laat begint, betaalt die achterstand later terug in extra uren en extra risico, in plaats van in een eenmalige investering vooraf.