Publiceer de interface

Vier engineers. Negen clusters. Een roadmap met elf punten, waarvan er in een kwartaal geen enkele was opgeschoven.

Dat was de situatie toen me gevraagd werd te kijken waarom een platformteam traag aanvoelde. Niemand in dat team was traag. Ze waren goed. Ze waren ook het grootste deel van elke week vragen aan het beantwoorden.

De week die niemand gepland had

Ik vroeg ze vijf werkdagen te turven. Geen urenregistratie, gewoon een streepje elke keer dat iemand buiten het team iets vroeg. De telling kwam terug op 61.

Uitgesplitst naar soort zag dat er zo uit:

• 19 verzoeken om toegang tot iets
• 14 vragen in de vorm "hoe krijg ik een ingress voor X"
• 11 verzoeken om een resource limit te verhogen
• 8 keer "is dit de juiste manier om Y te doen"
• 6 incidenten of vermoedelijke incidenten
• 3 die echt platformwerk waren

Drie. Van de eenenzestig. En de elf roadmappunten bleven staan waar ze stonden, want de roadmap is wat je doet met de tijd die overblijft, en die was er niet.

Het stuk dat verkeerd gediagnosticeerd wordt

De gebruikelijke lezing van die telling is "we hebben meer mensen nodig" of "we hebben een selfserviceportaal nodig". Allebei die lezingen slaan een stap over.

Kijk nog eens naar de twee grootste bakken. Toegangsverzoeken en ingress-vragen zijn niet moeilijk. Ze zijn niet eens interessant. Ze worden gesteld omdat niemand het antwoord kan opzoeken. Het antwoord zit in het hoofd van de platform engineer die het de vorige keer beantwoordde, en het verschilt een beetje afhankelijk van wie dat was.

Een platformteam in die toestand heeft een API. Alleen is die ongedocumenteerd, heeft hij geen versies, en wordt hij geïmplementeerd in een chatkanaal door wie er wakker is.

De vraag

Dus: wat scheidt een platformteam van een platform?

De technologie niet. Alle negen clusters waren vakkundig gebouwd. Flux stond erop, Prometheus haalde zijn metrics op, de network policies waren echt. Met de machinerie was niets mis.

Wat ontbrak was een uitspraak over wat die machinerie belooft.

Schrijf de beloftes op

Dit is de oefening die ik inmiddels drie keer heb gedaan, en hij kost een middag.

Zet op een rij wat een team van het platform nodig heeft om een dienst te kunnen draaien. Niet wat het platform kán. Wat een dienst werkelijk nodig heeft, in de volgorde waarin hij het nodig heeft. Bij de meeste organisaties is die lijst kort en ziet hij er ongeveer zo uit:

1. Een plek om te draaien (namespace, quota, wie mag deployen)
2. Een weg naar binnen (ingress, TLS, DNS)
3. Een manier om een secret te bewaren
4. Een manier om te zien wat het doet (logs, metrics, een dashboard)
5. Een manier om een deploy terug te draaien
6. Een manier om hulp te krijgen als het stukgaat

Zes punten. Schrijf nu bij elk punt drie dingen op: hoe een team het krijgt, hoe lang dat duurt, en met wie je praat als het niet werkt.

Dat document is de interface. Er hoeft geen portaal bij. De eerste versie die we schreven was één Markdown-bestand in de platform-repo, 340 regels, met kubectl-commando's en een link naar het pull request-sjabloon voor namespace-aanvragen.

Het effect was meteen zichtbaar en voor iedereen een beetje ontnuchterend: de telling zakte de week erna van 61 naar 23. Niet omdat er iets geautomatiseerd was. Omdat de antwoorden een plek hadden gekregen.

Wat het document je laat toegeven

Opschrijven is ongemakkelijk, en dat is het nuttige eraan.

Je vindt beloftes die je niet waarmaakt. In dit geval was punt 5 het pijnlijke. "Hoe draait een team een deploy terug" bleek drie verschillende antwoorden te hebben, afhankelijk van welk cluster en welk leverpad, en één van die antwoorden was "vraag het aan een platform engineer". Dat konden we niet met droge ogen opschrijven, dus hebben we het opgelost. Die oplossing kostte twee dagen werk die een jaar lang onzichtbaar waren gebleven omdat niemand de belofte ooit hardop had moeten formuleren.

Je vindt ook beloftes waar niemand om gevraagd heeft. Er zat een compleet service mesh-verhaal in dat in precies nul van de zes punten voorkwam. Het is blijven staan, want het deed echt werk voor mTLS, maar het verhuisde uit de interface naar de implementatie, waar het thuishoort.

Er versies op zetten

De tweede versie van het document zette boven elke paragraaf een regel: de datum waarop de belofte voor het laatst is nagelopen, en door wie.

Dat klinkt bureaucratisch. Dat is het niet. Een belofte die in acht maanden niemand getest heeft is een gerucht. Er een datum op zetten maakt van "we ondersteunen blue-green" een bewering waar iemand voor moet gaan staan, en ervoor gaan staan betekent even gaan kijken.

Wat ik de versie van mezelf van toen zou vertellen

Je hebt geen platformteam nodig om een platform te hebben. Je hebt een opgeschreven interface nodig, en iets wat hem nakomt. Genoeg organisaties hebben het tweede zonder het eerste, en ervaren dat als een personeelsprobleem.

En het lastigere: schrijf je de zes beloftes op en blijkt Kubernetes niet te zijn wat ze goedkoop houdt, dan heb je iets geleerd dat meer waard is dan de middag die het kostte. Twee clusters daar draaiden samen vier workloads. Die staan nu op twee VM's met systemd-units en een Caddy-config, en niemand mist de operator.

De telling die ertoe doet is niet hoeveel clusters je draait. Het is hoeveel vragen je platform beantwoordt zonder jou.