Feature Toggle Dynamics in Large-Scale Systems: Prevalence, Growth, Lifespan, and Benchmarking
Deze studie analyseert de evolutie van feature toggles in grote systemen zoals Kubernetes en GitLab om aan te tonen dat verwijdering vaak achterblijft bij toevoeging, wat leidt tot een groeiende voorraad en permanente toggles, en stelt daarop een nieuw benchmarkkader voor om toggle-beheer te evalueren.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je voor dat je een enorm, levend gebouw bouwt: een stad van software. In deze stad werken duizenden ontwikkelaars om nieuwe winkels, bruggen en parken (functies) te bouwen.
Om te voorkomen dat ze het hele gebouw afbreken als ze iets nieuws testen, gebruiken ze feature toggles (functieschakelaars). Dit zijn als tijdelijke deuren of schermen die je kunt openen of sluiten zonder de muren te slopen. Als je een nieuwe winkel wilt testen, doe je de deur open voor een paar mensen. Werkt het goed? Dan haal je de deur weg en laat je de winkel permanent open. Werkt het niet? Dan doe je de deur dicht en haal je hem weg.
Het probleem? De deuren blijven vaak staan.
Dit is het verhaal van het onderzoek van Xhevahire Tërnava. Ze keek naar twee gigantische steden: Kubernetes (een platform voor het beheren van containers, geschreven in Go) en GitLab (een platform voor softwareontwikkeling, geschreven in Ruby). Ze keek naar wat er de afgelopen jaren is gebeurd met al die schakelaars.
Hier is wat ze ontdekte, vertaald naar alledaagse taal:
1. De "Vergroeiende Tuin" (De Voorraad groeit)
Stel je voor dat je elke maand 10 nieuwe deuren installeert om te testen. Je hoopt dat je er ook 10 weer verwijdert als de test klaar is.
- Wat ze zagen: In beide steden werden er meer deuren geplaatst dan verwijderd.
- In Kubernetes bleef er ongeveer 35% van de deuren achter.
- In GitLab was dat 13%.
- Het gevolg: De stad wordt langzaam volgepropt met oude, nutteloze deuren. Dit noemen ze "technische schuld". Het is alsof je tuin volstaat met oude schuttingen die je nooit weghaalt; ze blokkeren het uitzicht en maken het moeilijk om nieuwe paden aan te leggen.
2. Twee Verschillende Stijlen van Beheer
De twee steden werken heel anders, en dat is niet per se slecht, maar het is wel anders.
- Kubernetes (De "Geduldige Tuinier"):
- Ze bouwen niet heel snel, maar ze zijn voorzichtig.
- Een schakelaar blijft hier gemiddeld 2 jaar (734 dagen) staan voordat hij wordt verwijderd.
- Ze hebben minder schakelaars, maar ze laten ze langere tijd open. Het is alsof ze een nieuwe brug bouwen, die eerst een jaar als proefbrug dient voordat ze hem definitief maken of weer afbreken.
- GitLab (De "Snelle Bouwheer"):
- Ze bouwen razendsnel. Elke maand komen er honderden nieuwe schakelaars bij.
- Een schakelaar blijft hier maar gemiddeld 6 maanden (185 dagen) staan.
- Ze zijn veel sneller in het verwijderen van deuren, maar omdat ze er zoveel nieuwe plaatsen, blijft de totale hoeveelheid deuren toch hoog.
De verrassing: Als je kijkt naar hoe lang een schakelaar blijft staan ten opzichte van de bouwcyclus, zijn ze eigenlijk heel vergelijkbaar! In beide steden blijft een schakelaar ongeveer 6 bouwcycli open. Het verschil zit hem alleen in hoe snel die cycli gaan (Kubernetes bouwt per kwartaal, GitLab per maand).
3. De "Spookdeuren" (De Vergeten Schakelaars)
Het meest zorgwekkende wat ze vonden, zijn de schakelaars die nooit worden verwijderd.
- In Kubernetes waren er 8 schakelaars die langer open stonden dan de langste schakelaar die ooit succesvol was verwijderd.
- In GitLab waren dat er 25.
- De analogie: Dit zijn als deuren die je jaren geleden hebt geplaatst voor een proefproject, maar waar niemand meer aan denkt. Ze staan nu vast in de muur. Niemand weet meer wie ze bediende of waarom ze er zijn. Ze zijn "permanent" geworden door verwaarlozing, niet door ontwerp. Dit maakt het gebouw onveilig en moeilijk te onderhouden.
4. De Nieuwe "Tuinman-Handleiding" (Het Benchmark Framework)
Omdat niemand wist of hun tuin "ziek" of "gezond" was, hebben de onderzoekers een meetlat bedacht. Ze hebben vijf regels opgesteld om te zien of je je schakelaars goed beheert:
- Hoeveel deuren doe je open en dicht per maand? (Te veel chaos? Te weinig activiteit?)
- Groeit je voorraad? (Blijf je meer deuren achterlaten dan je verwijdert?)
- Hoe vaak haal je ze er weer uit? (Ben je een goede opruimer?)
- Hoe vol zit je huis? (Hoeveel deuren heb je per vierkante meter?)
- Hoe lang blijven ze staan? (In verhouding tot hoe snel jullie bouwen).
Ze hebben voor deze regels "groene", "gele" en "rode" zones gemaakt.
- Groen: Alles is gezond.
- Geel: Pas op, je bouwt te veel technische schuld op.
- Rood: Stop! Je hebt een "one-in-one-out" regel nodig (voor elke nieuwe deur, moet je een oude verwijderen).
Waarom is dit belangrijk voor jou?
Zelfs als je geen software bouwt, werkt dit principe overal. Stel je voor dat je in een kantoor werkt waar iedereen nieuwe post-it notes plakt op het bord met ideeën.
- Als je nooit de oude plaktjes verwijdert, wordt het bord onleesbaar.
- Als je te snel plaktjes verwijdert zonder ze te testen, mis je goede ideeën.
- Als je te lang wacht, vergeten mensen waarom ze het plakten.
Dit onderzoek zegt: "Weet hoe lang je dingen bewaart, en zorg dat je niet verdrinkt in je eigen uitvindingen."
De onderzoekers hebben zelfs een online dashboard gemaakt (een soort digitale tuinman) waar teams hun eigen cijfers kunnen invoeren om te zien of ze in de "groene zone" zitten of dat ze hun "spookdeuren" moeten gaan opruimen.
Kortom: Feature toggles zijn handig, maar zonder discipline worden ze een rommelige berg oude deuren die je hele systeem langzaam verstikt. Het is tijd om te gaan opruimen!
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.