Pionative ads

"Wij doen Kubernetes." Zeg dat op een feestje en je bent je gesprekspartner binnen tien seconden kwijt. Snap ik. Het is ook moeilijk uitspreken ;) Maar het is eigenlijk heel simpel: Bedrijven bouwen software. Die software moet ergens draaien. Dat doen ze in de cloud. En daar begint het gedoe. Want dat "ergens draaien" moet stabiel zijn, schaalbaar zijn, en altijd bereikbaar zijn. Drie dingen die makkelijk klinken totdat je het zelf moet regelen. Ik doe dit inmiddels al twaalf jaar en zie nog steeds developers die om drie uur 's nachts wakker liggen omdat iets ineens niet draait. Developers willen bouwen. Niet uitzoeken waarom de boel eruit ligt. Dus dat is wat wij doen. Wij zorgen dat die laag eronder gewoon werkt. En vooral blijft werken!

Het grootste deel van kosten van software zit in het beheer. Bij IT Infrastructuur is dit precies hetzelfde. De implementatie is enorm belangrijk. Zeker om de beheerkosten laag te houden. Maar het beheer wordt vaak onderschat. Beheer is ook het minst leuke werk. Engineers willen innoveren. Geen saai beheer uitvoeren. Bij Pionative hebben we dit weer leuk gemaakt. Door alles te automatiseren. Ook het beheer. Heb je een cluster geïmplementeerd, en loop je hier tegenaan? Stuur me een berichtje!

Hoeveel mensen heb je nodig om Kubernetes-cluster(s) goed te beheren? ING: 15 man. Gemiddeld MKB-bedrijf: denkt 0,5 FTE. De waarheid? Die ligt in het midden. In de enterprise-wereld heb je platformteams van vijftien+ man. Puur verantwoordelijk voor het implementeren en beheren van het platform. Misschien bouwen ze nog een stukje developer self-service, maar meestal is dat dan ook weer een ander team... Kijk je naar het MKB, dan zie je dezelfde ambities. Enterprise-grade Kubernetes, alle tooling, alle integraties. Het moet alleen wat effectiever, er hoeft minder overlegd te worden. Dus die ene handige engineer komt een eind (stukje verloren vrije tijd daargelaten). En toch zal dat gaan piepen en kraken. Opbouwen is leuk, want nieuw. Beheren al een stuk minder. Gebeurt dus ook lang niet altijd. Troubleshooten terwijl je ergens anders mee bezig bent? Helemaal kut. Daar komt bij: niemand doet hetzelfde werk voor altijd. Of het nou een promotie is, een nieuwe baan of full-time vaderschap: die handige engineer vertrekt. En dan? Bijna vijf jaar geleden zeiden wij: dit kan anders. Enterprise-kwaliteit, MKB-schaal. Eén platformteam voor meerdere bedrijven tegelijk. Dezelfde stack, dezelfde kwaliteit, zonder dat jij daar zelf een heel team voor optuigt. Dat werkt stiekem best wel goed. Continuïteit gegarandeerd.

Wie van jullie weet überhaupt wat een sandbox is? Een paar weken geleden zat ik bij een EKS-webinar over het binnen sandboxes draaien van je AI agents. In hun geval uiteraard: op EKS. Wat ik er interessant aan vond, waren de verschillende sandbox-opties die voorbij kwamen. De gedachte die ik niet kon loslaten: volgens mij gebruikt bijna niemand bewust een sandbox. Iedereen bouwt AI-apps, soms een nieuwe per week. Het gesprek 'ik geef Claude daar wel/geen toegang toe' wordt nog wel gevoerd. Maar dan hebben we het vaak over connectoren, externe databronnen. Maar hoe weet je dat dat ding niet op hol slaat? Dingen op je laptop doet die je niet wilt? Dingen lees of opvraagt die niet de bedoeling zijn? Zelf probeert externe systemen te bereiken? Want de eerste 50 keer kijk je de commando's waar hij toestemming voor vraagt nog na, maar de meeste mensen die ik betrap op Claude-gebruik hebben 'm gewoon lekker op 'Auto' staan... Dus de vraag wordt dan: binnen welke kaders bouw jij een AI-app? Ten eerste: heeft je agent skills of instructies die beschrijven wat wél en niet mag? Of improviseert hij maar? Ten tweede; en die is dus harder: is die agent gesandboxed? Geen toegang tot de buitenwereld, geen databases, geen toegang tot de host, tenzij je dat bewust toestaat. Hoe regel jij dat?

Kubernetes is de enige goede keus in EU-clouds. Change my mind. Als je met wat voor reden dan ook een Europese Cloud provider moet gebruiken kun je maar beter cloud-agnostisch zijn. En daarvoor is Kubernetes gewoon de beste keus. Vijf jaar geleden twijfelden we daar nog aan. Tegenwoordig is dit een no-brainer. Oneens? Laat het weten in de comments. 👇

Eén is geen. Tenminst, als we het hebben over Kubernetes engineers Hoe goed deze engineer ook is. En ik zie het bij bijna elk softwarebedrijf tussen de 5 en 20 developers. Er wordt één iemand vrijgemaakt om de infra te beheren. Maar wat gebeurt er als die persoon morgen vertrekt? Je bus factor is 1. Dus je hebt minimaal twee mensen nodig. Liefst drie. Puur vanwege continuïteit. Dat vraagt specialistische kennis. Kennis die de meeste softwarebedrijven simpelweg niet in huis hebben. En eerlijk gezegd ook niet zouden moeten willen hebben. Want Kubernetes beheren is niet je core business. Bouwen aan je product wel. Bij Pionative beheren wij de infrastructuur voor teams die willen focussen. En dat met een hoge bus-factor. De rekensom is dan opeens een stuk eenvoudiger.