Wat previewomgevingen echt kosten
De kosten van previewomgevingen groeien mee met het aantal open pull requests, niet met de teamgrootte. Ontdek waar de uitgaven verborgen zitten, welke onderdelen je kunt delen en hoe je previews automatisch laat verlopen, zodat vijf open PR's niet vijf volledige stacks betekenen.
Previewomgevingen zijn een van de meest rendabele voorzieningen die een team kan inschakelen. Een reviewer klikt op een link en gebruikt de wijziging, in plaats van een diff te lezen en zich voor te stellen hoe die eruitziet. Designproblemen komen vóór de merge aan het licht. QA is geen aparte fase meer.
Ze zijn ook de kostenpost die je rekening het stilletjes snelst kan verdrievoudigen. De oorzaak is eenvoudige rekenkunde die niemand maakt op het moment dat de feature wordt ingeschakeld.
De rekenkunde
De kosten van een previewomgeving schalen mee met het aantal open pull requests, niet met het aantal mensen in het team of het aantal merges.
Een team van vier met een gezonde reviewcultuur heeft op elk moment misschien vijf tot acht open PR's. Als elke PR een volledige kopie van je stack uitrolt, draai je naast productie nog eens vijf tot acht productiekopieën. Een stack die $30 per maand kost, kost nu $180–$270. Dat stond in niemands schatting, omdat die schatting over één omgeving ging.
Erger nog: het aantal open PR's is vaak het hoogst op momenten waarop je je het minst onverwachte problemen kunt veroorloven: vlak voor een release, tijdens een refactor of wanneer iemand op vakantie is en diens branch drie weken open blijft staan.
Waar het geld echt naartoe gaat
Niet elk onderdeel van een preview kost evenveel. Weten welke onderdelen duur zijn, is wat de kosten beheersbaar maakt.
Application containers — gemiddeld, en de moeite waard. Dit is het onderdeel dat je daadwerkelijk wilt. Het schaalt bovendien goed terug, omdat een preview niet zoveel geheugen nodig heeft als productie.
Databases — het dure onderdeel. Een dedicated database per preview is de grootste kostenpost en meestal ook het minst noodzakelijk. Voor de meeste reviews is geen geïsoleerde database nodig; ze hebben een database met representatieve data nodig.
Build minutes — onzichtbaar en cumulatief. Elke push naar een open PR start een nieuwe build. Een branch met veertig commits verspreid over twee weken wordt veertig keer gebouwd. Dit zijn echte kosten die nooit zichtbaar worden als een draaiende resource en daardoor volledig buiten de mentale controle vallen.
Egress — klein per preview, groot in totaal. Preview-URL's worden ontdekt en gecrawld. Een crawler die je assets uit acht previewomgevingen ophaalt, doet acht keer zoveel werk als op productie, en voor dat alles betaal je.
Vier manieren om de kosten te verlagen zonder de waarde te verliezen
Deel de database
Voor de meeste wijzigingen kunnen previews één database met representatieve data delen. Gebruik geïsoleerde databases alleen voor PR's die dat echt nodig hebben — migrations, schemawijzigingen en alles wat destructief is.
De regel die in de praktijk werkt: alleen een geïsoleerde database wanneer de PR het schema wijzigt. Al het andere wordt gedeeld.
Schaal de preview terug
Een preview die door één reviewer wordt gebruikt, heeft niet de resources van productie nodig. De helft van het geheugen en een fractie van de CPU is meestal onzichtbaar voor de reviewer en levert wel een aanzienlijke kostenbesparing op.
dockup resources my-project/my-api --memory 512 --cpu 0.5
Laat ze verlopen
De wijziging met de grootste impact. Een preview hoort niet langer te bestaan dan de bijbehorende pull request.
Automatisch afbreken na een merge of close is een basisvereiste. Wat teams vaak over het hoofd zien, is de verlaten PR — de branch die iemand heeft geopend, waarna die persoon aan iets anders is toegewezen en de PR nooit heeft gesloten. Die omgevingen blijven maanden draaien.
Een maximale levensduur is daarom een goede laatste beveiliging: elke preview die bijvoorbeeld ouder is dan veertien dagen, wordt verwijderd, ongeacht de status van de PR. Als iemand de preview opnieuw nodig heeft, is dat met één command geregeld.
Houd ze uit zoekmachines
Preview-URL's worden geïndexeerd. Dat is om twee redenen slecht — dubbele content die concurreert met je productiesite en crawlerverkeer waarvoor je betaalt op omgevingen die niemand gebruikt.
dockup noindex my-project/my-api --on
Op Dockup zijn PR-previews per service ingesteld en kunnen ze expliciet worden in- of uitgeschakeld, in plaats van dat je een globale instelling erft:
dockup pr-preview my-project/my-api --on
dockup preview list my-project/my-api --json
dockup preview delete 128 my-project/my-api
De lijst opvragen is het onderdeel dat teams overslaan en later betreuren. Omgevingen die je niet kunt inventariseren, zijn omgevingen waarvoor je betaalt zonder te weten dat ze bestaan.
De controle die je één keer per maand moet uitvoeren
Drie vragen, vijf minuten:
- Hoeveel previews draaien er? Vergelijk dat aantal met het aantal PR's dat daadwerkelijk openstaat.
- Hoe oud is de oudste? Alles wat ouder is dan twee weken, is vrijwel zeker verlaten.
- Welke previews hebben een eigen database? Alles wat geen schemawijziging is, heeft er waarschijnlijk geen nodig.
De meeste teams vinden minstens één omgeving van een PR die maanden geleden is gemerged, nog steeds draait en nog steeds kosten veroorzaakt.
De waarde benutten zonder verrassingen
Dit is geen argument tegen previewomgevingen. Het is een argument om ze te behandelen als infrastructuur met een lifecycle, en niet als een checkbox.
Teams die dit goed aanpakken, doen drie dingen: previews worden teruggeschaald, previews verlopen automatisch en previews delen wat veilig gedeeld kan worden. Daarmee blijft de volledige footprint van previews meestal onder de kosten van één productieservice — een prijs waarbij het overduidelijk de moeite waard is.
Teams die voor verrassingen komen te staan, zijn de teams die de feature één keer correct hebben ingeschakeld en daarna nooit meer naar de lijst hebben gekeken.
Veelgestelde vragen
Kosten previewomgevingen evenveel als productie? Per omgeving kunnen ze dat doen als ze identiek worden uitgerold. Wanneer een preview wordt teruggeschaald en een database deelt, kost die doorgaans maar een fractie van productie.
Moet elke preview een eigen database hebben? Alleen wanneer de wijziging het schema raakt. Eén gedeelde database met seeddata dekt de meeste reviews en verwijdert de grootste kostenpost.
Wat gebeurt er met een preview wanneer de PR wordt gesloten? Die hoort automatisch te worden vernietigd. Als dat niet gebeurt, stapelen omgevingen van PR's die niemand zich meer herinnert zich vanzelf op.
Hebben previewomgevingen een negatieve invloed op SEO?
Dat kan, als ze worden geïndexeerd — dubbele content die concurreert met je productiepagina's. Markeer ze als noindex; daarmee voorkom je ook dat crawlers verkeer genereren waarvoor je betaalt.