Hele grote digitale infrastructuren fascineren mij. Dat is de grens van het kunnen, dat is voorbij de ‘leading edge of technology', dat is de ‘bleeding edge of technology’. Dat is waar onze traditionele wijsheid, kennis en aanpak wel eens ophoudt nuttig te zijn. De mooiste voorbeelden daarvan vind je op internet. Waar anders?
Een traditionele wijsheid is de scheiding tussen ontwikkel-, test-, acceptatie- en productieomgevingen, de zogenaamde OTAP-straat. Allemaal verschillende clubjes. Allemaal in 'splendid isolation' met grote muren er tussen en liefst tot op het netwerk of zelfs kabelniveau gescheiden. Het kost wat, maar dan heb je ook wat. Alleen, op internet werkt dat niet zo. Er is geen apart internet voor acceptatietesten.
En wat dacht je van Hyves, Flickr en dat soort social media sites! Die bedrijven hebben duizenden, of wel tienduizenden servers staan. Die gaan echt niet een exacte kopie van die omgeving maken om een acceptatietestje te doen. Dat kunnen ze niet betalen. Dat doet me trouwens denken aan een andere traditionele wijsheid: niet te vaak nieuwe versies uitbrengen, anders wordt het te duur. Maar daar trekken die social media sites zich niets van aan. Die brengen gewoon een paar keer per dag nieuwe versies uit. En acceptatietesten doen ze gewoon op productiehardware. En blijkbaar lukt het ze.
En hierachter zitten de echte wijsheden. Als die grote websites geen OTAP-straat nodig hebben, waarom hebben we die dan wel voor veel kleinere en eenvoudiger toepassingen? Kijk, OTAP is eigenlijk een manier om risico's te beheersen. Op de ‘bleeding edge' heb je ook risico's, misschien wel meer. Alleen worden ze daar anders aangepakt. Een nieuwe versie rol je daar uit op een klein deel van de servers, en wordt dus maar door een klein deel van de gebruikers gezien. Zitten er functionele of performance problemen in, dan zie je die voor de hele boel omvalt. Je zet gewoon de knop terug en stuurt geen gebruikers meer naar die servers. Zo doe je wel degelijk aan risicobeheersing, maar wel op een ander level.
Wat is nou de conclusie van dit artikel ?
Dat OTAP straten niet nodig zijn, want je moet gewoon slim testen in productie ? En dat Hyves en Flickr voorbeelden zijn van hoe het moet ?
Ik kon ook geen conclusie vinden.
Verschillende omgevingen gebruiken verschillende testmethodieken, was het enige wat ik eruit begreep.
Maar dat is ook logisch. Een Hyves is niet hetzelfde als een “goalkeeper” bijvoorbeeld.
Een klein deel van de gebruikers naar servers sture met de bijgewerkte applicatie sturen en dat wachten op de klachten: ik zie dat bij online bankieren en het EPD nog niet zo zitten. Geschokt vertrouwen bij de patient en/of klant. Je kunt zoiets alleen doen in omgevingen waar ofwel de klant ofwel het bedrijf dat erg weinig geeft om de opgelagen data. En als je weinig geeft om de integriteit van je data is er geen toegevoegde waarde voor een OTAP straat.
Tussen regels door lees ik wel iets van een mening/conclusie : Bij load balanced services kun je een deel van de productie gebruiken als test. Een deel van de load wordt zegmaar de Test straat.
Tja, ligt nogal voor de hand he, als je je dure productie-omgeving op kunt delen/scheiden en toch ietwat wilt testen, zonder beschikking te hebben over aparte test omgeving.
Mij valt het contrast op tussen deze manier van testen en de voortdurende berichten over hacks en privacy problemen bij de grote social media sites.
Dat + de combinatie van vooral gekke koppen trekken ipv goeie artikelen schrijven, vind ik opmerkelijk.
Het punt van vaak releasen, en de geen strikt gescheiden O, T, A, P is wel een sterk punt. Belangrijk punt om je af te vragen, hoe komt het dat organisaties als Flickr, WordPress, Amazon, etc. vaak kunnen releasen en toch een succesvolle organisatie hebben? Het lijkt me onzin te stellen dat voor deze organisaties de betrouwbaarheid van hun it er niet toe doet. Sterker nog, volgens mij is die een stuk beter dan bij veel banken en klassieke bureaucratische organisaties die wel het klassieke model aanhouden van OTAP.
Vraag is niet waarom veel releasen. Vraag is: waarom wordt er zo weinig released? Is het installeren van een nieuwe release zo moeizaam dat het dan maar uitgesteld wordt?
Tis simpel Gerbrand.
Er wordt weinig released, omdat er grondig getest moet worden en men waarschijnlijk nauwkeurig afweegt in hoeverre de change noodzakelijk is.
Voor leuke plaatjes delen gebruikt men Flickr, voor blogjes over wat je vandaag gedaan hebt, WordPress. 80.000 euro online overmaken doet men bij Banksites.
12 jaar geleden deden we dit soort dingen ook bij HetNet. Veel klanten en gebruikers kozen liever voor snelheid dan voor degelijkheid. Vergaand en daardoor langdurig testen kostte te veel tijd. Bij vervelende problemen kon je de SQL-server tabellen en de mappen met de oude programmatuur alsnog snel terugzetten bij de servers met een verkeerde update.
OTAP is een bewezen methodiek die in verschillende gradaties kan worden toegepast. Het klassieke beeld van de OTAP-“straat” kan inmiddels op de schop: OTAP is een fasering die idealiter per fase een eigen omgeving heeft (virtueel of fysiek). Of dat ideaal beeld moet worden vastgehouden is feitelijk aan de stakeholders. Zonder OTAP kan men tenslotte ook zaken in productie krijgen, maar sta er dan niet vreemd van te kijken als er eens een keer iets niet ging zoals beoogd was. Als je ontwikkelproces zo soepel in elkaar steekt dat je heel snel nieuwe releases in productie kan brengen, dan lijkt OTAP overbodig. Een “foutje” kan dan misschien snel hersteld worden, maar niet vanzelfsprekend. Zo is het risico op een beveiligingsincident op slechts 1 van 100 servers veelal voldoende om toch maar een volledige OTAP te doorlopen, versus de verkorte versie. Aan de andere kant: Dit gaat misschien op voor financiële instellingen, maar wellicht niet voor Hyves of Flickr.
Anderzijds is OTAP een goed hulpmiddel om het release-management proces nader in kaart te brengen en waar mogelijk te stroomlijnen. Maar OTAP dood verklaren? De straat misschien, maar de fasering niet.
Anoniem heeft gelijk. OTAP is een bewezen methodiek die in verschillende gradaties kan worden toegepast.
Bij een financiële website of software suite die via een CD/DVD wordt verspreid, is een volledige OTAP-straat met bijbehorende procedures een must.
Bij de meeste amusement en nieuws websites loop je minder en andere risico’s. Dan kan of moet je op een andere wijze met release management omgaan.