Wat wij kunnen leren van SpaceX als het gaat om DevOps
Op dit moment vindt er een ware revolutie plaats in de ruimtevaarttechnologie. SpaceX, het bedrijf van Elon Musk, neemt nu 80 procent van de totale massa die naar de ruimte gebracht wordt voor zijn rekening. En dat getal zal in hoog tempo oplopen naar 90 procent. Veel mensen zijn kritisch op Elon Musk. Voor deze blog moeten we voorbij zijn ego kijken en vooral kijken hoe de engineers op de werkvloer zich inzetten. Want dat SpaceX zo succesvol is, komt in mijn ogen door hun aanpak. Binnen DevOps kunnen wij veel van ze leren. In deze blog wil ik stil staan bij het verschil tussen NASA en SpaceX (die beiden een nieuwe raket ontwikkelen) en wat zo uniek is aan SpaceX.
De Space Launch System (SLS) raket van NASA
NASA ontwikkelt op dit moment de Space Launch System (SLS) raket. Deze raket brengt hopelijk de mens binnen enkele jaren opnieuw naar de maan.
Artemis is de opvolger van het Apollo programma uit de jaren 60 en 70. De SLS raket is een doorontwikkeling van de Space Shuttle die in 2011 voor het laatst vloog en gebruikt gereviseerde en geoptimaliseerde componenten van deze Space Shuttle. NASA krijgt zijn budget vanuit de staatskas van de Verenigde Staten, echter wel onder strenge voorwaarden. 
Zo moet het geld uitgegeven worden
aan zogenaamde onderaannemers die actief zijn in bepaalde staten voor baangarantie, waarbij er een grote lobby is tussen de senatoren.
Deze raket is voor eenmalig gebruik want na de lancering verbranden de onderdelen in de dampkring of storten ze neer in de oceaan. Het maken en lanceren van 4 raketten kost zo’n 41 miljard dollar. Omdat het gaat om publiek geld mag er geen enkele fout gemaakt worden, want dit levert negatieve publiciteit en reputatieschade op. De aanpak is waterval, waarbij het geheel wordt ontworpen, gebouwd, geïnspecteerd, getest, getest en nogmaals wordt getest. En vanwege de onderaannemers wordt er veel tijd gespendeerd om de ontwerpen op elkaar aan te sluiten. Dit alles voelt als veilig en dat is noodzakelijk omdat er op korte termijn ook mensen plaatsnemen in de Orion capsule van de SLS raket om naar de maan te vliegen. NASA kiest hier voor 100% zekerheid, ‘failure is not an option’. Vanaf de eerste lancering moet het direct goed gaan.
De Starship raket van SpaceX
SpaceX ontwikkelt op dit moment Starship. Starship is de grootste, zwaarste en meest krachtige raket ooit gemaakt. Er is een groot verschil met NASA’s SLS raket en dat is, dat Starship volledig en snel herbruikbaar gaat worden. Een raket die inzetbaar is als een vliegtuig. Lancering, landing, tanken en weer opnieuw lanceren. Dit zorgt voor een significante reductie van kosten als het gaat om massa naar de ruimte brengen.
Op het moment van schrijven staat de 2e testraket klaar voor lancering. Dit zal gegarandeerd gepaard gaan met een grote ontploffing, of hoe SpaceX het noemt een ‘Rapid Unscheduled Disassembly’. Onze media zullen dit negatief oppakken en juist benoemen dat de raket ontploft is, maar voor SpaceX is het geen falen. Voor SpaceX betekent dit data verzamelen en leren, heel veel en vooral snel leren. 
Hun feedbackloop is kort en elk component wat vanuit hun fabriek komt is een doorontwikkeling van de vorige versie. Daarmee gaan ze soms kort door de bocht. Daar waar NASA’s slogan is ‘failure is not an option’, doet SpaceX een ‘Just send it’. Leren doe je namelijk in de praktijk. Praktijk is meer waard dan theorie. Stabiliteit en betrouwbaarheid verkrijg je door iets vaak te doen en daarmee alle fouten eruit te halen. Dit is vergelijkbaar met DevOps: bij het deployen en releasen van software. Doe je iets vaak, dan verbeter je automatisch het proces en de technologie. Zodoende word je er beter en sneller in.
SpaceX heeft ervaring opgedaan met deze aanpak bij het laten landen van hun Falcon 9 raket. Daar waar de wereld zei dat het waanzin is om een raket bij terugkomst te laten landen op aarde en deze vervolgens opnieuw te lanceren, heeft SpaceX laten zien dat het kan. De laatste versie van deze raket is 225 keer succesvol geland (van de 236 pogingen). Deze raket is de meest betrouwbare raket ooit gemaakt en zelfs het landen kent een hogere betrouwbaarheid dan alle andere raketten qua lanceringen. Een impressie van de eerste landingspogingen is samengevat in een hilarisch YouTube filmpje ‘How not to land an orbital class rocket booster’
SpaceX’s Innovatie Algoritme
SpaceX hanteert een innovatie algoritme dat bestaat uit een vijftal principes. Elke engineer binnen SpaceX werkt volgens deze vijf principes. Deze principes kunnen ook toegepast worden binnen de DevOps wereld. De principes zijn:
- Make the requirements less dumb
- Delete the part of process step
- Optimize
- Accelerate
- Automate
Make the requirements less dumb
Je moet ervan uitgaan dat de requirements die je verteld worden altijd fout zijn. Het is meer de vraag hoe fout ze zijn. Je moet de vraag in twijfel trekken, omdat er continue geleerd wordt en nieuwe inzichten ontstaan. Primair is het de zoektocht om de juiste vraag te stellen.
Daar waar mensen samenwerken aan een complex geheel ontstaan beperkingen die we elkaar opleggen rondom de requirements. In het Engels zeggen we ook wel mooi ‘constraints’. Jij moet je als engineer aan de constraints houden, als je een gedeelte realiseert binnen een complex geheel. Anders sluit het niet aan op een component die iemand anders heeft gerealiseerd. Veel organisaties denken dat dit efficiënt en effectief is. Het geeft je als engineer minder vrijheid in de realisatie van een bepaald component zowel in het proces als het daadwerkelijke resultaat. Dit resulteert in iets wat we ‘local optimalization’ noemen. Je bouwt immers het beste wat je kan maar wel binnen deze constraints. Dit wil echter niet zeggen dat het geheel optimaal werkt.
Het zomaar aannemen dat een constraint daadwerkelijk een constraint is, is binnen SpaceX uit den boze. Een constraint dient altijd uitgedaagd te kunnen worden, want constraints zorgen juist voor een toename van complexiteit van het geheel. De ervaring leert dat bij constraints vaak niemand echt meer weet waarom de constraint er überhaupt is of is opgelegd door een persoon die inmiddels al is vertrokken. Je wilt als organisatie streven naar ‘Global optimalization’ en je wilt dat mensen voorbij afdelingen en personen kijken om zo gezamenlijk de beste oplossing te realiseren.
Tijdens softwareontwikkeling moeten engineers altijd de requirements kunnen uitdagen. In de praktijk zie je dit vaak met product owners. Er wordt iets bedacht maar een product owner is ook maar een mens van vlees en bloed en heeft zijn of haar biases/overtuigingen. Al in 2009 bewees Microsoft met deze paper dat 2/3 van alle software die ontwikkeld wordt, geen of negatieve waarde heeft. Impact mapping, Feature Mapping en Behaviour Driven Development kan binnen softwareontwikkeling meehelpen om de juiste vragen te stellen, om de vraag in twijfel te trekken en de juiste requirements naar boven te halen. Data, telemetrie en observability kunnen hier verder in ondersteunen om snel te leren van de praktijk.
Delete the part of process step
Als het onderdeel of de proces stap er überhaupt niet is, scheelt dit tijd, geld en met name complexiteit.
SpaceX wil Starship volledig hergebruiken en de raket moet daarom kunnen landen. Het maken van een landingsgestel is complex en levert extra gewicht. Dus SpaceX heeft het landingsgestel compleet verwijderd van de raket. De raket wordt uit de lucht gegrepen door twee grote grijparmen. Denk je in, een flatgebouw van 70 meter hoog en 9 meter in diameter wordt uit de lucht gegrepen. De complexiteit is verplaatst naar de lanceer & landingstoren en zodoende kan de raket meer vracht meenemen omdat het landingsgestel niet meer nodig is.
In ontwikkelteams die nog niet conform CI/CD werken kom ik vaak hetzelfde verschijnsel tegen in de vorm van bijvoorbeeld een releasedraaiboek. Ooit, waarschijnlijk jaren geleden, is het team tegen een fout aangelopen en heeft volkomen terecht een maatregel genomen zodat deze fout in de toekomst voorkomen wordt. Ondertussen voeren we al twee jaar deze procedure of test uit, maar het is nooit meer voorgekomen. We moeten ons dan af gaan vragen: Kunnen we deze stap niet in zijn geheel verwijderen? Het antwoord is vaak ja.
Optimize
De optimize stap is eigenlijk de stappen ‘make the requirements less dumb’ en ‘Delete the part of process step’ een aantal keer herhalen. Hoe vaak? Dat kan niet gezegd worden. Het is belangrijk om te begrijpen dat onze IT-wereld een complex geheel is. Niemand overziet het geheel en complexe systemen zijn altijd in staat van bijna-falen. Hoe simpeler het geheel, hoe minder onderdelen gebruikt worden, hoe hoger de betrouwbaarheid. Dit levert een conflict op bij veel engineers want vaak wordt er gedacht des te meer tooling, des te beter. Om het erger te maken; complexiteit verkoopt beter, zei Edsger Dijkstra ooit.
Engineers maken vaak de fout om iets te optimaliseren of te automatiseren wat eigenlijk helemaal niet hoort te bestaan. Als voorbeeld wil ik hier Kubernetes aansnijden. Kubernetes is een geweldig product met veel mooie mogelijkheden, maar kan al snel complex worden. Als je voor een applicatie geen schaalbaarheid of beschikbaarheidsproblemen hebt waarom zou je het geheel complexer maken? Kubernetes is uitermate geschikt om juist deze kwaliteitsaspecten te verbeteren. Is schaalbaarheid en beschikbaarheid geen probleem voor je applicatie, zet het dan niet in en hou het simpel. Wij engineers hebben een holistische kijk nodig op het geheel om dit te kunnen overzien. Goede engineers zijn goed in systeem denken.
Accelerate
Nadat je een aantal keer geïtereerd hebt door het geheel en je hebt geoptimaliseerd, ga dan sneller. Door sneller te gaan haal je fouten uit het proces of product. Je ontdekt zwakheden of ontdekt welke elementen aandacht nodig hebben. Door te versnellen doe je nieuwe ontdekkingen.
Dit sluit aan bij de gezegde ‘if it hurts, do it more often’. Je kan altijd sneller maar pas wel op, ga niet te snel waardoor er onacceptabele risico’s kunnen ontstaan. Zeker als er reputatieschade, financiële schade of zelfs schade kan ontstaan met betrekking tot leven en dood.
Zelf heb ik meegemaakt dat mijn team onder druk stond om voor een bepaalde datum een aantal functionaliteiten op te leveren. Om sneller te kunnen leveren hebben we besloten om minder tijd te spenderen aan het testen. We accepteerden het risico dat onze klanten tegen fouten aan zouden kunnen lopen. Het resultaat? Het viel reuze mee, ja er waren wat klachten, ja we zagen in de logging dat er vreemde situaties waren, maar uiteindelijk losten we die snel op. We zijn er zo achter gekomen dat we structureel te veel testen en dat onze testdekking naar beneden kon, zodat we sneller konden leveren. Het heeft geleid tot herziening in de maatregelen die wij namen als team als het gaat om risico mitigaties.
Automate
Pas als je de eerste vier stappen hebt uitgevoerd ga je automatiseren. Automatiseren helpt je om nog sneller te gaan en om te standaardiseren. Je gaat het proces verder stroomlijnen. Je automatiseert pas als laatst, omdat je dan pas het geheel efficiënt en effectief kan automatiseren.
De relatie met DevOps Way of Working en de valkuil van ‘Automate everything’
Ik kom vaak in aanraking met teams die het ‘automate everything’ principe hebben. Niet handig denk ik dan want direct met automatiseren beginnen kan leiden tot een vergroting van de inefficiëntie. Bill Gates zei dit al jaren geleden:
“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”
In onze DevOps wereld mogen wij engineers vaker stilstaan bij de principes van SpaceX en minder snel inspringen op de automation en tooling hype. Dat we dit doen is logisch, want de meeste vacatures vragen niet om optimalisatie. Ze vragen om juist om tooling en dus automation kennis.
Een goede engineer heeft in mijn ogen een holistische kijk op het geheel, stelt kritische vragen en bekijkt altijd of complexiteit gereduceerd kan worden om zo een betrouwbaarder en goedkoper geheel te realiseren. Laten we meer kijken naar hoe SpaceX raketten ontwikkelt. Als zij het kunnen met raketten, dan moeten wij dat toch ook kunnen met onze software?
In welke raket wil jij plaatsnemen voor een trip rond de maan? Een raket die op papier en op de grond door en door getest is en maar een handvol keer heeft gevlogen of in een raket die in het begin vaak ontploft is en waar alle zwakheden zijn uitgehaald door een snel leerproces?
Joost Voskuil, DevOps Consultant
