Inmiddels zijn we allemaal it’er. Jij ook. Immers, we vertegenwoordigen allemaal een organisatie die zo snel mogelijk en tegen zo hoog mogelijke kwaliteit it in productie wil zetten. Door snel businesswaarde toe te voegen, maken we onze organisaties flexibel, adaptief en competitief.
Je hebt zoals vele anderen ervaren dat bij het realiseren van die businesswaarde coderen en testen parallel lopen. Het een kan niet meer zonder het ander. Deze activiteiten werden vroeger nog als zelfstandige, afgebakende taken uitgevoerd door ‘ontwikkelaars’ en ’testers’. Inmiddels zijn het taken van een team geworden en veelal samen uitgevoerd. We zijn allemaal dev-engineer geworden, toch?
Nu het niet meer uitmaakt wíe de verantwoordelijkheid heeft voor een activiteit in een team (áls het maar gebeurt) is het ook tijd om je te realiseren dat het ook niet hoeft uit te maken wáár de activiteit wordt uitgevoerd (áls het maar gebeurt). We hebben het nu niet over distributed agile teams of thuiswerken, we breken hier een lans voor het doorbreken van een paradigma: stop met denken in otap (ontwikkeling, test, acceptatie en productie)-omgevingen. Waarom?
Waste
Je wilt met it zo snel mogelijk businesswaarde toevoegen. En dan ook nog tegen hoge kwaliteit. Die snelheid kun je alleen bereiken als je herkent waar in het proces ‘waste’ ontstaat en deze elimineert. Werken in otap-omgevingen betekent dat je in jouw voortbrengingsproces op weg naar productie enkele stappen herhaalt: code deploy naar een nieuwe omgeving, controleren van de juiste versies, testdata klaarzetten, connectiviteit juist zetten, test scripts starten, logging interpreteren en/of andere al dan niet handmatige acties. Bij elke omgeving opnieuw. Je creëert waste. Je vertraagt de boel!
De huidige technologie biedt ons een alternatief waarin het niet meer nodig is om otap-omgevingen neer te zetten, in te richten, te koppelen aan activiteiten en te beheren. Door dit alternatief slim in te zetten, win je flink aan snelheid en krijg je zelfs eerder feedback op kwaliteit.
Create, deploy, destroy
Je kunt gaan werken met containers. Containers zijn tijdelijke omgevingen waarmee je in staat bent om delen van applicaties te verplaatsen door allerlei fases zonder die software steeds weer opnieuw te installeren. In plaats van dat de verschillende procesfases een nieuwe omgeving vereisen, laat je de container met de software door de fases heengaan. Je bent hierdoor in staat om continu businesswaarde naar productie te brengen.
En daarmee is het mogelijk om ontwikkelde code in snelle feedback iteraties te valideren op alle aspecten die nodig zijn om de businesswaarde te garanderen; zonder dat deze code over verschillende omgevingen gedistribueerd hoeft te worden! Je kunt bijvoorbeeld een container met de aangepaste software opspinnen, daar de api-test op uitvoeren en als deze succesvol is uitgevoerd, de container te koppelen aan een klein stukje van de keten (waarbij je de oude deactiveert en verwijdert).
Verschil met otap
Wat is het verschil dan met een otap-omgeving? Het verschil zit hem erin dat je eigenlijk nog maar twee omgevingen hebt: een productieomgeving en een niet-productieomgeving. In de productieomgeving heb je de software draaien waarvan de kwaliteit is bewezen en waarmee je businesswaarde genereert. In de niet-productieomgeving heb je een hele set aan containers, cloud-oplossingen of andere opties die ‘onsamenhangend’ geplaatst zijn. De gehele ‘ota’ is hiermee dynamisch geworden. Op elk moment kan er een koppeling worden omgehangen waarmee een stukje van de nieuwe software ineens meedraait in een productieketen. Deze aanpak heeft tot doel zo snel mogelijk de kwaliteit te bewijzen. Daarmee wordt extra businesswaarde zo snel mogelijk gerealiseerd. Door af te stappen van vaste omgevingen en te gaan naar dynamische ketens zorg je ervoor dat specifieke activiteiten op de juiste momenten uitgevoerd kunnen worden.
Voorbeeld
Stel dat het gewenst is om een uitspraak te hebben over de kwaliteit van een deel van de beveiliging van een gewijzigde applicatie. In otap-omgevingen zie je vaak dat het gewijzigde stuk software eerst de o-, de t- en a-omgeving moet hebben doorlopen voordat de beveiliging wordt getest. Er vinden vier deploys plaats. Dat is waste.
Als je werkt met containers dan zet je de nieuwe code eenmalig neer. De configuratie bepaalt of deze code in een bepaalde keten hoort (of losstaand is). Je kunt de securitytest laten uitvoeren en als de software voldoet dan kan dit stuk software direct in de productieketen meedraaien. Eenmalig klaarzetten in plaats van viermaal.
Stop dus met het verplicht doorzetten van nieuwe software door een gehele otap-straat als daar geen reden toe is. Hiervoor krijg je veel automatisering, kwaliteit en vooral veel meer tijd terug. Deze tijd kan je dan besteden aan het creëren van nieuwe businesswaarde. Het maakt je sneller en wendbaarder. O ja, en als jij het niet doet, jouw concurrent doet het al.
Jelle Schutte, cto, en Joost Jongman, technical solution architect, bij Valori
Het concept OTAP verdwijnt niet, de implementatie is gewoon anders geworden. Waar voorheen OTA ‘niet productie’ was is het nu een container (of cluster van containers) die voor een bepaald doel wordt ingericht.
Vroeger had je alleen containers op serieuze mainframes, en nu wel. In de tussenliggende tijd is het gat met ouderwets ijzer opgevuld.
Er wordt niet met OTAP gekapt, we kappen vrolijk verder met OOOOOTTTTTAAAA P (heel veel ontwikkel, test en acceptatie container clusters).
Jelle & Joost,
De kwaliteit van een systeem wordt veelal bepaald door het voldoen aan de gebalanceerde eisen en verwachtingen van alle betrokken belanghebbenden. En ervaring leert dat het testen van de organisatorische beveiling nog wat anders is dan de technische beveiliging, privacy-by-design is een verwachting waar vaak niet aan voldaan wordt als de slager zijn eigen vlees gaat keuren.
Het verschil tussen de business waarde van een API en de organisatorisch governance van een systeem blijft een punt van discussie in de gebalanceerde eisen en verwachtingen van alle betrokken belanghebbenden. Testen in de productie met een onsamenhangendheid aan API’s klinkt voor mij als een stomme ontwerpfout.
“Inmiddels zijn we allemaal it’er” en “We zijn allemaal dev-engineer geworden”, “Nu het niet meer uitmaakt wíe de verantwoordelijkheid heeft voor een activiteit in een team”.
Ketentests, integratietests, nonfunctionele tests, systeemtests, gebruikersacceptatietests hoeven blijkbaar ook niet meer.
Was ict maar net zo simpel als Jelle en Joost
Man man man, wat een stelletje avonturiers.
Ict bestaat echt uit meer dan wat diaree bij elkaar laten scrummen door scholieren !
Zoals Dino al terecht opmerkt moet je niet enkel er voor zorgen dat je een opdracht uitvoert,
maar je moet er ook voor zorgen dat systemen aan jouw spul hangen ook nog blijven werken.
We kennen allemaal wel de voorbeelden van grote organisaties die een OOPSje hadden en waar het simpel terugdraaien van de zojuist uitgerolde flater toch nog niet zo evident bleek.
Het gaat hier dan ook waarschijnlijk om wat lichtgewicht app-jes met wat lichte persistency (misschien een tabelletje of 10 cloud opslag) die geen enkele integratie hebben met andere software. Anders zou ik het gebrek aan een testomgeving niet kunnen verklaren.
Hallo ‘Een oudlid’,
Als de boodschap over is gekomen als dat testen alleen in productie plaatsvind dan is er ergens in het overbrengen en het ontvangen van de boodschap iets niet goed gegaan. Het is niet de bedoeling dat er (alleen) in productie getest wordt (de discussie van wel of niet testen in productie nog even daargelaten). Het testen vindt wel degelijk in de niet-productie omgeving plaats, alleen zijn de omgevingen daar niet statisch maar dynamisch. Dus een koppeling van een set van containers geeft aan of iets wel of niet mogelijk is om te valideren. Het niet ‘eindeloos’ hoeven deployen van containers / software zorgt ervoor dat je waste eliminieert, het koppelen van bepaalde systemen zal nog altijd plaatsvinden door het aanpassen van configuratie. De samenhang (dependencies) zal in die zin dus ook altijd blijven om te kunnen valideren of aspecten goed / naar behoren werken.
Hallo Dino,
Als de boodschap bij jou geland is dat de ketentests, integratietests, non-functionals etc. niet noodzakelijk zijn, dan is de boodschap niet bij jou beland zoals deze wel bedoeld was. Nergens schijven we dat er geen test meer nodig zijn. (Ja, ik ben er voorstander van om dit niet zo statisch te koppelen aan de termen E2E, ST, FAT, GAT etc.). We zijn juist een groot voorstander van goed testen. Het verschil zit hem erin dat je de juiste test op het juiste moment uitvoert en juist dat is niet simpel, maar zonder de juiste kennis & ervaring juist al extreem complex (en met de juiste ervaring en kennis ook complex genoeg).
Hallo Pascal,
Als je als organisatie een ‘OOPSje’ hebt, dan hoop ik dat je als organisatie ervan leert. Het blijft mensen werk en waar gewerkt wordt, vallen helaas weleens spaanders. Het inrichten van een OTAP met alle soorten tests zoals in gestructureerde processen kan ook nog steeds leiden tot een OOPS. Uiteindelijk wil je er voor zorgen dat je zo weinig mogelijk OOPS moment realiseert. Als je ze dan toch wilt realiseren, dan maar in de niet productieomgeving omdat je dan nog geen impact hebt gefaciliteerd bij de gebruikers. Een OOPS vinden in de niet productie omgeving zorgt ervoor dat je het voorkomt dat deze daar wel komt. Door de juiste test(s) op het juiste moment te doen zorg je ervoor dat je de OOPS vindt en oplost voor het bij de gebruiker aanbeland. Het hebben van een OTAP straat bepaald dat niet (dus vaker dezelfde code deployen), het uitvoeren van de juiste tests wel.
Hallo KJ,
Nog niet elke software is even geschikt om snel te wisselen van configuratie, helemaal eens. Hoe kleiner de applicaties hoe makkelijker dat vaak blijkt (met genoeg uitzonderingen op de regel natuurlijk). Wat maakt een testomgeving speciaal ten opzichte van een acceptatie omgeving? Wat is het verschil? Uiteindelijk heb je het over software (code) die in de testomgeving precies dezelfde code heeft als in acceptatie omgeving, toch? (Als het andere code is, waarom zou je de niet gebruikte code testen?). Het verschil zit hem in connectiviteit, configuratie en data (ik ga niet beweren dat er organisaties zijn die code in een test omgeving testen en dan andere code als ‘getest’ doorzetten naar een acceptatie omgeving..)
Als je code toch hetzelfde is, waarom moet je deze dan opnieuw deployen? Ik kan toch ook precies diezelfde code hergebruiken alleen als ik zeker weet dat het functionele deel helemaal goed is, de dataset veranderen (koppeling met een andere database) zodat ik kan kijken of deze onder ‘load’ nog steeds goed functioneert (non functional & functional).
Dat ik een omgeving maak waar ik zelf de letter O, T of A aan koppel maakt de code niet anders of speciaal; de configuratie en daarmee de mogelijke interactiviteit met aangrenzende systemen of andere datasets zorgt wel voor een verandering, daar heb ik geen belettering van omgevingen voor nodig.
Hallo Joost,
Ik zou de volgende keer voor elk antwoord één reactie doen, je verhoogt daarmee de teller van ‘Meest besproken’ welke meer attentiewaarde geeft aan je opinie. Vergeet ook niet de eerste reactie van CPT want ik slinger alleen maar de discussie aan. En hierin heb ik nog geen antwoord op mijn vraag over het testen van de organisatorische beveiliging. Ik stelde dit punt ter discussie omdat mijn ervaring leert dat een RBAC-model nog weleens wringt met containers.
Hallo CPT,
ik denk dat er wel degelijk gekapt wordt met OTAP. Er komt een NIET P en een P voor terug. De container zit in een bepaalde status waarmee bepaalde tests om risico’s af te dekken kunnen worden uitgevoerd. Pas wanneer al deze activiteiten succesvol zijn doorlopen wordt een container opnieuw gedeployed en dit maal in P. Een container zit dus niet in een ontwikkel omgeving om daarna naar een test omgeving te gaan, de container is en blijft waar hij is. De eventuele koppelingen bepalen de connectiviteit met andere systemen en uit te voeren activiteiten. Daaruit komt dus naar voren dat er maar 1 omgeving is waarin alle systemen aan elkaar gekoppeld zijn zodat uiteindelijk alle activiteiten om de risico’s af te dekken, functionaliteiten bewezen etc. zijn uitgevoerd voor de software naar productie gaat. De 2 omgevingen blijven dus, de containers (met daarin de software) hebben een eigen levensfase welke dus bepalend is).
Hallo Een Oudlid,
Allereerst bedankt voor je tip, zoals je ziet heb ik hem ter harte genomen.
Ik denk dat jouw vraag groter is dan alleen het ‘security’ vlak. Het gaat inderdaad niet alleen om technische security maar ook organisatorisch. Daarbij komt dan wellicht ook nog dat dit ook nog eens, door bijv. ontwerp- of code fouten, onder load weer anders gaat functioneren.
Een simpel antwoord is zeggen dat: “Alles testen is onmogelijk”. Daarmee ben je er niet als je iemand wilt overtuigen dat dit (containers en afstappen van OTAP) een goede approach is in de volgende stap van het voorkomen van waste. De weg is alleen niet altijd even makkelijk.
Om dit concept goed neer te zetten komt er veel meer bij kijken. Een container neerzetten met de code zoals je naar productie gaat is in die zin niet anders dan hoe code op een omgeving wordt gedeployed zoals je nu gewend bent naar een Ontwikkel of een Test omgeving. Het verschil zit hem erin dat je het nu 1 keer doet en dat je langzaam de opties toe gaat voegen (in de juiste volgorde) om alle facetten te valideren / bewijzen (van welke school je dan ook bent..). Sommige aspecten zijn daarin makkelijker dan de anderen, maar dat verschilt niet van een OTAP.
Wat betreft RBAC en containers zie ik hier geen verschil in, ik ben dan ook geïnteresseerd in de situaties waarin dit wringt. De controle of de systemen met elkaar mogen communiceren blijft, de controle of de persoon de gevraagde actie mag uitvoeren blijft hetzelfde etc. Het enige verschil is dat de code nu in een container (met bepaalde settings) draait in plaats van op een fysieke machine (nog even virtuele machines weggelaten). Code op een container t.o.v. code op een fysieke machine blijft hetzelfde, de lagen met security zijn op andere vlakken; Dat wat ingeregeld moet worden om (in dit geval) toegang te beperken/toestaan, wordt natuurlijk nog wel ingeregeld (en gevalideerd).
Joost,
Een RBAC model is veelal middels een directory services zoals Microsoft AD gekoppeld aan services welke vaak als onderdeel van een ecosysteem afhankelijkheden met elkaar hebben. CRUD autorisaties op data zijn niet altijd goed ingeregeld in de orchestratie van microservices met als gevolg dat er nog weleens een back-up teruggezet moeten worden in de governance vraagstukken.