Waarom ik alles zelf host: over sovereignty, agency en controle

Lange tijd was de cloud gewoon het water waar ik in zwom. Ik zette managed Kubernetes neer, klikte door de console, plakte een Terraform-module die iemand anders had geschreven, en shipte. Werkte prima. De rekening kwam elke maand, de dashboards bleven groen, en onder de motorkap keek ik niet. Waarom zou ik? Ik vertrouwde het zoals je een lift vertrouwt. Knopje, deuren open.

Toen viel er op een middag een managed service om en zat ik daar met niks om te debuggen. Geen host om op in te loggen, geen log die ik mocht lezen, niks eronder wat ik open kon maken. De statuspagina zei “investigating”. Meer had ik die middag niet te doen dan een pagina verversen die iemand anders beheerde.

Inmiddels host ik vrijwel alles zelf. Kubernetes op refurbished mini-PCs, Forgejo op eigen hardware, Vault voor secrets, plus monitoring, logging, de hele mikmak. Mensen vragen waarom, en terecht, want managed cloud is makkelijker en AWS, Azure en Google draaien het op schaal en betrouwbaar. Het antwoord begon op die middag, en het duurde even voor ik het hardop kon zeggen.

De korte versie is agency. De lange versie is deze post.

De middag dat de black box dicht bleef

Dramatisch was die outage niet. Een managed component waar ik van afhing reageerde niet meer, m’n app begon errors te gooien, en ik ging doen wat ik altijd doe als er iets stuk is. De oorzaak zoeken.

Dat lukte niet. Het ding dat faalde zat achter een abstractie waar ik niet bij kon. Ik zag het symptoom en verder niks. Dus opende ik een support-ticket en wachtte, wat een nette manier is om te zeggen dat ik op m’n handen zat terwijl m’n eigen systeem kapot was.

De downtime zelf viel wel mee. Downtime gebeurt. Wat me dwarszat was dat ik geen enkele relatie had met mijn eigen infrastructuur. Het draaien ervan had ik uitbesteed, prima, maar het begrijpen ervan had ik ongemerkt mee uitbesteed. Toen het kapot ging had ik niks om aan te trekken, want ik was er nooit bij in de buurt gelaten.

Dat is de splinter. Een black box waar ik verantwoordelijk voor ben voelt als een splinter onder de huid. Ik moet begrijpen wat ik draai, en een systeem dat ik niet open kan maken is een systeem waar ik alleen op kan wachten.

Een default waar ik nooit naar had gekeken

Met dat ticket nog open moest ik iets toegeven wat ik liever niet toegaf. Ik had mezelf wijsgemaakt dat de cloud een keuze was. Dat was hij niet. Het was een default die ik nooit had bekeken. Elk team waar ik had gewerkt gebruikte hem, dus ik ook. Er zat een trade-off in, en daar had ik geen seconde naar gekeken.

Die trade-off gaat zo. Managed services verbergen complexiteit, en precies daar betaal je ze voor. De moeilijke stukken zijn jouw probleem niet meer. Maar die complexiteit gaat nergens heen. Hij verhuist naar achter een muur waar jij niet langs mag. Op een goede dag heet die muur gemak. Op de middag die ik hier beschrijf was hij de reden dat ik m’n werk niet kon doen.

Voor context over hoe mijn brein werkt, zie Werken met een AuDHD-brein.

Mijn AuDHD-brein maakte de splinter onmogelijk te negeren. Als er iets kapot gaat wil ik de oorzaak, en “het ligt aan AWS” is een schouderophalen met een statuscode. Verborgen complexiteit voelt voor mij niet als rust. Het voelt als jeuk waar ik niet bij kan. De autisme-kant wil mijn omgeving vormen naar hoe ik werk in plaats van andersom, en “computer says no” is waar managed services dat gesprek meestal afkappen. De ADHD-kant leert door te bouwen en te slopen, docs lezen komt daarna, en aan een black box valt niks te slopen.

Dus de vraag die ik had ontweken was best simpel. Had ik ooit vóór managed infrastructuur gekozen, of was ik er gewoon terechtgekomen? Die middag was het eerlijke antwoord het tweede. En dat krijg je niet meer uit je hoofd.

Wat sovereignty volgens mij betekent

Digital sovereignty betekent echte controle over je eigen infrastructuur, data en processen. Het tegenovergestelde is afhankelijkheid, en die herken je aan de vorm. Je data staat bij een provider die de voorwaarden kan wijzigen wanneer het hem uitkomt. Je infrastructuur draait op een platform dat je niet begrijpt. Vendor lock-in maakt vertrekken zo duur dat je het nooit doet. De prijzen gaan omhoog en je hebt nergens om heen te lopen.

Ik wil hier voorzichtig zijn, want dit slaat snel door in paranoia, en dat bedoel ik niet. Sovereignty is keuzes hebben. De vrijheid om te vertrekken als iets niet meer voor je werkt, en genoeg begrip van het systeem dat vertrekken überhaupt kan. Een afhankelijkheid van iets dat je niet kunt inspecteren of bijsturen is een kwetsbaarheid. Ik zet hem in hetzelfde rijtje als een ongepatchte service, en ik behandel hem ook zo.

Dus ik koos. Ik liet de default niet langer voor me beslissen. De dingen waar ik van afhang draai ik op hardware van mezelf, met software die ik kan lezen, zodat ik de volgende keer dat er iets omvalt ergens kan beginnen.

De gesloten container in de ruimte

Er is een scenario waar ik steeds op terugkom, en ik heb het apart uitgewerkt als het ruimtecontainer-gedachtenexperiment. Je wordt wakker in een afgesloten container die door de ruimte drijft. Alles wat je nodig hebt om in leven te blijven zit bij je binnen, en er gaat niks in of uit. Wat doe je?

Je gaat de systemen leren. Hoe de zuurstof wordt geschrobd en hergebruikt, hoe het water wordt gefilterd, waar de stroom vandaan komt. Je wilt elk onderdeel kennen, want in die container kan een black box je de kop kosten.

Mijn homelab is geen overlevingscapsule, en dat verbeeld ik me ook niet. Maar het instinct neem je mee. Ik wil de systemen waar ik van afhang begrijpen, diep genoeg dat ik ze zou kunnen repareren als het moest. Island mode, een paar kopjes verderop, is hetzelfde idee met een aan-uitknop.

Hoe die keuze er in de praktijk uitziet

Mijn huidige stack draait op refurbished mini-PCs. Commodity hardware, geen dure servers:

Alles is GitOps-managed. Configuratie leeft in Git, ArgoCD synct het naar de clusters, en het geheel is declaratief, reproduceerbaar en auditeerbaar. Wil ik weten waarom iets is zoals het is, dan ligt het antwoord een git log verderop.

Island mode

Eén ontwerpregel druk ik harder door dan de rest, en dat is island mode. Mijn clusters moeten blijven werken zonder internet. In de praktijk betekent dat lokale mirrors van de container-registry, geen harde afhankelijkheden van externe APIs, elk secret lokaal in Vault, en documentatie die op het cluster staat in plaats van op de website van iemand anders.

Ik verwacht niet dat het internet verdwijnt. De constraint staat er om wat hij met het ontwerp doet. Een systeem dat afgesneden blijft draaien is een systeem dat je tot op de bodem kent, want je hebt elke afhankelijkheid moeten opsporen en weghalen die je niet kon verantwoorden. Offline-capabel en goed begrepen bleken dezelfde eis.

De rekening voor dit alles

Opnieuw bouwen op eigen hardware had een prijskaartje, en dat weglaten zou hier een reclame van maken. Dus hier is de factuur.

Tijd, om te beginnen. Je bent je eigen ops-team. Cluster-upgrades, security-patches, incident-response, dat is nu jouw avond. Het kost echte uren, vooral in het begin. Ik betaal het af met automatisering. K3s-upgrades lopen vanzelf, GitOps houdt alles gelijk, en Kyverno-policies blokkeren de misconfiguraties die ik anders maak als ik moe ben.

Dan kennis. Je moet weten wat je doet. Kubernetes, networking en security hebben elk een steile curve, en met self-hosting krijg je ze allemaal tegelijk. Dit is het deel van de rekening dat ik graag betaal. De kennis die ik koop door mijn eigen stack te draaien maakt me beter in mijn dagelijkse werk, want een abstractie snap ik een stuk beter als ik heb gezien wat eronder zit.

Geld vooraf. Hardware kost wat. Refurbished mini-PCs zijn goedkoop, maar goedkoop is niet gratis, en het is een drempel als je vanaf nul begint. De lopende kosten vallen wel mijn kant op. Mijn hele homelab trekt in een maand minder stroom dan het huren van één managed Kubernetes-cluster kost.

En geen SLA . Als het kapot gaat is er geen ticket om in te dienen en geen “dit is een AWS-probleem” om je achter te verschuilen. Ik ben het. Dat was de bedoeling, dus klagen mag ik niet. Ik wacht niet meer op een statuspagina. Ik open een shell en ga kijken, en van dat kijken komt het begrip.

Wanneer ik toch managed cloud zou pakken

Ik koos voor mijn situatie, en ik zou een hypocriet zijn als ik deed alsof dat de enige juiste keuze is. Managed cloud verdient z’n plek in genoeg gevallen.

Een startup die dit kwartaal moet shippen hoort aan het product te werken en op managed services te leunen tot schaal of kosten pijn gaan doen. Een team waar niemand Kubernetes kent maakt een verstandige keuze met EKS, GKE of AKS, zolang ze de kennis blijven opbouwen zodat de keuze open blijft. Sommige compliance-regimes zijn makkelijker te halen met gecertificeerde managed services. En heb je tien keer de capaciteit nodig voor één Black Friday, dan is cloud-elasticiteit echt geld waard.

Wat al die gevallen gemeen hebben is wat ik jaren miste. Kies bewust. Kijk naar de trade-off, benoem wat je weggeeft en wat je terugkrijgt, en kies dan managed omdat het past. Kiezen omdat iedereen om je heen het deed, zo kwam ik bij die statuspagina terecht.

Waar dat me heeft gebracht

Van dag tot dag lijkt het nog behoorlijk op vroeger. Kubernetes, ’s avonds YAML, af en toe een outage om achteraan te gaan. De dashboards wijzen nu naar kasten in mijn eigen rack, en dat is het grootste zichtbare verschil.

Het verschil dat ik voel is dat ik erbij kan. Ik behandel m’n infrastructuur niet meer als een abonnement waarvan ik hoop dat het blijft werken. Het is een systeem waar ik verantwoordelijk voor ben en waar ik in kan. Gaat er nu iets stuk, dan is er altijd een plek om te beginnen, en daar leer ik wat van.

Begrijpen wint bij mij van vertrouwen. Snap ik hoe iets werkt, dan kan ik het repareren, tunen en aanpassen. Vertrouw ik het alleen, dan gok ik op de competentie en goodwill van iemand anders, en die middag verloor ik die gok. Opties winnen van gemak. Managed services zijn heerlijk tot je weg wilt, en de kosten van weggaan rekenen ze de hele tijd al, alleen staan ze nergens op de factuur. En ik leer liever dan dat ik consumeer. Een probleem dat ik zelf oplos kan ik volgend jaar nog een keer oplossen. De problemen die ik uitbesteedde kon ik niet eens één keer oplossen.

Wil je hier zelf iets van voelen, begin dan klein. Eén Raspberry Pi of een oude laptop, Docker Compose, nog geen Kubernetes. Containers, networking en storage zijn genoeg. Voeg één service per keer toe en laat elke service je iets leren. Schrijf op waarom je koos wat je koos, want dat weet je straks niet meer. Reken erop dat er dingen kapot gaan, want in een homelab is de blast radius klein en de les net zo groot als op het werk. En praat met andere mensen die hetzelfde doen. Iemand op een homelab-forum is al tegen precies jouw muur aangelopen en heeft opgeschreven hoe die eroverheen kwam.

Dit is geen voorschrift. Niet iedereen hoeft alles zelf te hosten, en een hoop mensen blijven terecht met open ogen op managed cloud. Het enige wat ik van je zou vragen is wat die middag van mij vroeg. Laat de default niet voor je beslissen. Weet wat je weggeeft als je een systeem aan iemand anders overdraagt, en weet wat je terugkrijgt.

De splinter is er nooit helemaal uitgekomen. Ik wil hem er ook niet meer uit hebben. Gaat er nu iets stuk, dan open ik een shell.

Gerelateerde posts:

• Het ruimtecontainer gedachtenexperiment - Systeemdenken en gesloten systemen
• Werken met een AuDHD-brein - Hoe mijn brein mijn tech keuzes beïnvloedt
• ArgoCD voor beginners - Declaratieve infrastructuur
• Internal Developer Platform bouwen - De bredere context

• Philosophy
• Privacy