We kennen allemaal de term “Otap-omgeving”. En het belang van een correct ingerichte Otap-omgeving is niemand vreemd. Maar hoe goed is deze ingericht, en zijn deze omgevingen wel goed genoeg om alle scenario’s af te dekken.
Het belang van een goede Otap-omgeving (Ontwikkeling test acceptatie en productie), en dan voornamelijk het acceptatie en productie gedeelde moet niet worden onderschat. Vaak wordt er, vanuit kostenbesparing, voor gekozen om de acceptatie omgeving niet helemaal in te richten zoals de productie-omgeving. Maar is deze kostenbesparing wel reëel, en zijn er niet meer kosten mee gepaard indien de release in productie niet blijkt te werken?
Ontwikkel
Dit is de omgeving van de ontwikkelaar. Hier heeft de ontwikkelaar vrijwel de volledige controle over onder andere de context waaronder de applicatie draait, de inrichting van services en de rechten van de service processen. Zo kan hij kiezen om wel of geen ssl (secure sockets layer) te gebruiken, of het service account met administrator rechten te laten draaien zodat het in ieder geval werkt en het debuggen bespoedigt. Het doel van de ontwikkelomgeving is om de gewenste functionaliteit te implementeren en te testen voordat het beschikbaar wordt gesteld voor intern testen.
Vaak draaien de eindproducten op een server platform en wordt ontwikkeld op een desktop platform. Ook is hierbij de omgeving vaak niet helemaal identiek aan die van andere ontwikkelaars. De ideale ontwikkel omgeving is een afgeschermde, speciaal voor de doel-applicatie ingerichte, virtuele machine. Wel draaien alle componenten op één machine in plaats van op gescheiden servers en heeft de ontwikkelaar niet de beschikking over twee ontwikkelomgevingen om loadbalancing en sessie state te testen. Het streven is uiteraard wel om deze omgeving zo veel mogelijk gelijk te hebben aan de daadwerkelijke omgeving, voornamelijk om omgevingsfactoren vroegtijdig te ondervinden.
Test
De test-omgeving is de volgende fase van de applicatie. Hier wordt de applicatie, veelal vanuit een automatisch ingerichte build, geïnstalleerd en getest op een 'productie like'-omgeving. Hier beschikt de ontwikkelaar niet meer over zijn vertrouwde ontwikkelomgeving waar hij naar behoefte kan debuggen en uitproberen. Hier zullen de ontwikkelaar en tester, afhankelijk van de gekozen diagnose oplossing binnen de applicatie (logging, applicatie berichtgeving en fout afhandeling), de applicatie moeten kunnen analyseren indien er iets fout gaat.
In de testomgeving wordt vaak nog gebruik gemaakt van zogenaamde 'stub services' die de backend applicaties vervangen. Ook heeft de ontwikkelaar hier nog de beschikking over een beperkte reeks diagnose "tools" om de probleem analyse uit te voeren. Denk hierbij aan Fiddler, om tijdelijk berichten af te vangen en te bekijken, of Debugview om debug en trace informatie te monitoren. Hierbij komt meteen nog een voordeel van de testomgeving om de hoek kijken, namelijk dat hier een debug build kan worden geplaatst, of een dll kan worden overschreven met een debug versie voor verdere diagnose. Het is dus een beperkte omgeving die zo veel mogelijk gelijk is aan de productie-omgeving, maar met de mogelijkheid om tijdelijk instellingen te wijzigen ten behoeve van de probleem analyse.
Acceptatie en productie
Ik noem acceptatie en productie expliciet samen, omdat ze eigenlijk hetzelfde (zouden moeten) zijn. Wel zijn het fysiek twee verschillende omgevingen. Binnen deze twee omgevingen komen de daadwerkelijke infrastructuur- en platformfactoren aan bod. We werken niet meer met één server maar hanteren de N+1 architectuur en hebben voor de verschillende componenten in onze architectuur toegewijde servers tot onze beschikking. Alle services draaien onder de beveiligde protocol configuratie en rechten van service accounts zijn beperkt tot de minimale benodigde rechten. Ook hebben we binnen deze omgevingen te maken met (reverse) proxy's voor het beheren van toegang tot het netwerk en routers of firewalls voor het beheren en toelaten van het netwerkverkeer.
De acceptatie-omgeving dient hier dan ook als een staging omgeving waar we de installatie en functionaliteit van de applicatie kunnen valideren zoals dit tijdens de productie zal zijn. Daarnaast vindt de daadwerkelijk integratietest plaats met de acceptatie versie van de verschillende backend applicaties. Hierbij is het dan ook van belang dat de versie van de backend applicatie gelijk is aan die in productie. Een klein verschil in bijvoorbeeld een service interface van de backend server kan er voor zorgen dat de uiteindelijke uitrol in productie niet succesvol is en teruggedraaid moet worden.
Een andere belangrijk verschil met de testomgeving is dat er geen mogelijkheid meer is tot installeren van diagnose tools. Alleen software die al aanwezig is kan gebruikt worden om te analyseren wat er mis is. Dit heeft voornamelijk tot gevolg dat probleemanalyses een stuk lastiger zijn en vaak meer tijd in beslag nemen dan gewenst. Ook is er geen mogelijkheid meer tot het veranderen van proxy, router en firewall configuraties, vaak omdat de omgeving in een data center staat waar dit gecontroleerd wordt en als daadwerkelijke change moet worden aangevraagd.
Voor de productie- omgeving geldt eigenlijk hetzelfde als voor de acceptatie-omgeving echter is hier geen ruimte voor fouten en is de downtime beperkt.
Belang van acceptatie en productie
Waarom is het belangrijk dat de acceptatie- en productie-omgeving identiek zijn? Omdat er binnen de productie-omgeving geen risico's genomen mogen worden en er dus geen ruimte is voor "experimenten". Ik noem het experimenten omdat ook nieuwe technologieën of architectuur keuzen getest moeten worden voordat ze geïmplementeerd mogen worden.
Een aantal onderwerpen die met name betrekking hebben op een N+1 architectuur, en niet in een productieomgeving getest kunnen worden zijn:
• Failover mogelijkheden van een product;
• Loadbalancing oplossing;
• Valideren van statelessness;
• Het implementeren van sessiebeheer;
Besparen op je acceptatie omgeving
Beheerpartijen hebben verschillende gradaties in hun onderhouds contracten. Vaak hebben deze betrekking op de beschikbaarheid van beheerders, de manier waarop failover wordt ingericht, hoe snel een server weer online kan zijn en hoe er wordt omgegaan met backup en recovery. Dit zijn onderdelen die zeer belangrijk zijn voor de keuze van de architectuur waarop de applicaties moet worden uitgerold. Daarnaast zijn dit ook technologieën die voor de beheerpartij bewezen technologieën zijn en hoeven niet als zodanig getest te worden voor iedere oplossing.
Deze 'hoge eisen hebben minder betrekking op de acceptatie-omgeving. Zo hoeft een backup niet direct teruggezet te worden maar kunnen de werkzaamheden vaak de volgende dag worden voortgezet. Ook hoeft bij een server crash de server niet volledig automatisch te worden hersteld maar voldoet een handmatige actie. Tevens kan voor de meeste testen worden voldaan met twee servers per component en hoeft de server ook niet over de resources (processoren/memory) te beschikken die een productie server nodig heeft om de performance te halen. Dit laatste is natuurlijk wel van belang als er een performance test moet worden uitgevoerd maar met de huidige vm-technologieën kan dit redelijk snel 'on-demand' gerealiseerd worden.
Het belang van een goede Otap-omgeving moet niet worden onderschat, en hierbij zijn de vier boven genoemde omgevingen essentieel. De kosten van de omgeving, en in het bijzonder een gelijke acceptatie-omgeving, wegen niet op tegen de kosten die gemaakt worden indien een release op de productie omgeving mislukt. Hierbij kunnen de kosten van de acceptatie-omgeving worden beperkt door goed naar de onderhouds- en beheerderskost en te kijken.
Duidelijk stuk en volgens mij ook wel een redelijk bekend verhaal. Wat ik wel mis is wie welke omgeving beheert. Dit geeft namelijk vaak aan of de juiste personen met de juiste belangen er de juiste prio (lees: investering) aan koppelt. Plus dat er nog wat andere voordeeltjes aan te koppelen zijn. Kortom, breidt het verhaal uit met de beheertaken, koppel er de testsoorten aan (b.v. non-functionals) en het is naar mijn idee compleet.
Op zich helder verhaal van uit de IcT gezien. Het zou interessant zijn om ditzelfde te vertalen naar: de ontwikkeling, testen, accepteren en in productie nemen van communicatietoepassingen en communicatie-infrastructuren.
Dan wordt het verschil tussen IT en CT ineens duidelijk……
Geweldig artikel Martijn. Het OTAP verhaal maakt uiteindelijk onderdeel uit van de gehele IT cyclus die bijzonder duidelijk maakt dat IT een prachtig en voorspelbaar medium is. Richt je dit deel niet goed in, en geloof me, ik heb dit vele malen meegemaakt, dan krijg je daar verder in de keten last van. Dat is gewoon te voorspellen.
Nu zie je steeds vaker, vooral met zoiets als een recessie, dat men denkt dat de IT, dus ook de keten, kan worden gebruikt als sluitstuk van de begroting. Men denkt triviale onderdelen gewoon achterwege te laten omdat ….
En meteen merk je dan ook wat er gebeurd, omdat de resultaten van dergelijke stappen niet alleen voorspelbaar zijn, maar zich ook meteen manifesteren. Nu is basis van IT uiteindelijk besparen. Doch, en dat continue mijn betoog, als je ondoordacht met de schakels binnen de ketens van IT denkt om te kunnen gaan, is je besparing louter cosmetisch en de schade vele malen hoger dan het bedrag dat je dacht te besparen.
En dat is wat je de voorbije maanden steeds vaker in de publiciteit ziet komen.
Als we de schade bijvoorbeeld van de brand van Vodafone in Rotterdam becijferen kan dit wel eens tussen de vijftien en twintig miljoen blijken. De redundancy die dat had kunnen voorkomen? Ik schat een zes tot zeven miljoen. Gewoon maar een simpel voorbeeld als je denkt de IT, en dus juist iets triviaals als OTAP, als sluitstuk in je begroting te kunnen zien en te laten vervallen.
@NumoQuest
“Nu is de basis van IT uiteindelijk besparen….”
In veel BC’s wordt er alleen van kwantitatieve zaken in het financieel vergelijk uitgegaan en op basis daarvan dat omgezet naar besparingen. Wat m.i in een BC vaak in ontbreekt is dat kwalitatieve zaken niet vertaald worden naar kwantitatieve zaken/elementen om dat vervolgens weer naar concrete besparingen om te zetten. Zie jij dat ook zo of bedoelde je alleen de harde, directe IT besparingen?