Service Virtualization

Wat hebben de luchtvaart en de ontwikkeling van bedrijfskritische systemen gemeenschappelijk? Het mag niet misgaan. Trainen in een simulator is een belangrijke manier om het echte vliegen zo veilig mogelijk te maken. Daar kan softwareontwikkeling wat van leren. Testen in een gesimuleerde omgeving versnelt en verbetert de ontwikkeling. Met Service Virtualisatie realiseer je zo’n testsimulator. De zakelijke voordelen zijn immens: de business beschikt sneller over goed geteste applicaties, ook in zeer complexe omgevingen.

Service Virtualisatie in context

Het ontwikkelen en testen van applicaties wordt steeds lastiger. Dat komt door de groeiende complexiteit van de applicatie-architecturen, die zich door de toepassing van cloud vaak tot buiten de bedrijfsmuren uitstrekken. En doordat bedrijven op meer plaatsen aan ontwikkeling doen. In eigen huis, in de regio (near-shoring) of aan de andere kant van de wereld (off-shoring).

Ontwikkel- en testteams zien zich geconfronteerd met tal van knelpunten en beperkingen (‘constraints’). Dat zijn bijvoorbeeld geen, of beperkte toegang tot een mainframe-applicatie, een bedrijfskritisch ERP-systeem of een service van derden. Of het niet beschikbaar hebben van testgegevens. Constraints komen ook voort uit de tegenstrijdige belangen van ontwikkel- en test-teams die toegang nodig hebben tot dezelfde omgevingen. Ze moeten op hun beurt wachten terwijl ze natuurlijk snel verder willen.

Service Virtualisatie elimineert deze beperkingen door de benodigde systemen te simuleren en deze simulaties gedurende de hele softwareontwikkelingslevenscyclus beschikbaar te stellen aan ontwikkelaars, testers en performance testteams.

Wat is Service Virtualisatie?

Service Virtualisatie (of SV) is de methodiek om van onderliggende systeemcomponenten de gedragingen, de datastromen en de prestatiekarakteristieken vast te leggen in Virtual Services. Deze Virtual Services worden door de ontwikkel- en testteams gebruikt om de afhankelijkheden, die het te ontwikkelen of te testen systeem heeft met overige systemen, zonder beperkingen in beschikbaarheid en schaalbaarheid na te bootsen.

In feite is SV de automatisering van het traditionele ‘mocking & stubbing’ van benodigde componenten in softwareontwikkeling. Mocking modelleert de gedragingen van een afzonderlijke systeemcomponent (‘Wat doet het?’) en Stubbing modelleert de uitkomsten (‘Werkt het of werkt het niet’). In complexe, dynamische omgevingen met veel afhankelijkheden is het afzonderlijk en in samenhang testen van de talloze systeemcomponenten een wetenschap op zich. Door de bestaande omgeving na te bootsen en vervolgens te kijken hoe de vernieuwingen ingrijpen op die omgeving, krijg je totaaloverzicht, maar kun je ook op detailniveau vaststellen wat er gebeurt. Dit verbetert het testproces aanzienlijk, het verkleint de risico’s na oplevering en het verkort de doorlooptijd van systeemontwikkeling.

SV is met name een uitkomst in complexe omgevingen met niet, of maar beperkt beschikbare componenten, services en data. Denk daarbij aan bedrijfskritische omgevingen; je kunt in de productieomgeving niet even een deelproces testen. SV maakt een einde aan de beperkingen en wachttijden waar ontwikkel- en testteams vaak tegenaan lopen als ze toegang moeten hebben tot componenten, systemen, databases, mainframes, interfaces, enzovoort.

SV resulteert in een Virtual Service (VS), een door het systeem geautomatiseerd voortgebracht softwareobject dat de instructies bevat voor een realistische ‘conversatie’ tussen twee systemen. De applicatie die wordt getest, communiceert met een virtuele versie van de externe applicatie in plaats van met een echte versie. Deze virtuele versie wordt een Virtual Service genoemd.

Wat is SV niet?

SV is een ander concept dan de virtualisatie van hardware en operating systemen, waarin de echte applicaties op een nagebootst platform draaien. In het SV-concept worden de applicaties zelf nagebootst, of eigenlijk de communicatie tussen de applicaties.

Hoe werkt een VS?

Een VS simuleert de echte applicatie op basis van input- en output-berichten. Voor elk bericht dat de VS ontvangt, wordt op basis van een aantal logische stappen en regels een bijbehorend realistisch antwoord samengesteld of opgezocht in een set van klaarstaande antwoorden. Deze antwoorden kunnen in een productieomgeving of testomgeving zijn vastgelegd door gebruik te maken van de opnamefaciliteit (‘listener’) van de virtual-service omgeving of zijn ingebracht door de tester die verantwoordelijk is voor de VS. Ook is het mogelijk om gebruik te maken van logfiles voor het creëren van realistische antwoorden.

Een voorbeeld: een software-ontwikkelteam bouwt aan een applicatie die alleen kan functioneren met behulp van een cloud SaaS-service van een derde partij. De cloud SaaS-service is niet (altijd) beschikbaar voor de ontwikkelaars.

De ontwikkelaars en testerengineers gebruiken SV voor het:

Afvangen van het verkeer tussen de twee systemen. Een listener wordt ingezet die het (berichten-) verkeer tussen de systemen opvangt en vastlegt.

Modelleren. De opgevangen data worden op basis van geavanceerde algoritmes gecorreleerd en gevirtualiseerd tot een voor ontwikkeling en testen bruikbare en realistische ‘conversatie’ van requests en responses tussen de beide systemen.

Simuleren. Het ontwikkelteam kan de VS nu gebruiken als plaatsvervanger voor het cloud SaaS-systeem en kan tijdens ontwikkeling aanpassingen testen zonder dat het cloud-SaaS systeem beschikbaar is. De VS reageert op requests met exact de juiste response, net als in het echt, maar dan veel beter voorspelbaar en met veel lagere omstelkosten.

De voordelen van SV

Tijdwinst bij het ontwikkelen en testen (bijna 100% beschikbaarheid van testafhankelijkheden)
Parallelle, in plaats van seriële ontwikkeling
Vroegtijdige opsporing van fouten
Betere kwaliteit van de opgeleverde software
Bedrijfszekerheid; productieomgevingen blijven onaangeroerd in de ontwikkelings- en testfase
Lagere kosten tijdens ontwikkeling en testen
Meer flexibiliteit
Ondersteuning Agile Development-technieken zoals Continuous Delivery & Deployment
Verhogen van de test coverage
Negatief testen mogelijk (het testen van ongewenst gedrag is met echte systemen zeer complex tot onmogelijk)
Versnellen van een ketentest
Minder testomgevingen nodig
Versimpeling van testdatamanagement bij afhankelijkheden in testdata bij verschillende systemen
Mogelijkheid te testen tegen verschillende versies van een interface, inclusief de nog niet beschikbare versie

Traditioneel testen is niet langer houdbaar

Moderne applicaties zijn modulair en gedistribueerd en hebben hierdoor vele integratiepunten (en daarmee afhankelijkheden) met andere applicaties. Het opzetten en onderhouden van een complete testomgeving in zo’n complexe omgeving is zeer ingewikkeld, kostbaar en tijdrovend. Niet alleen moeten alle omliggende systemen en componenten fysiek aanwezig zijn om te kunnen testen, ze moeten ook nog eens juist zijn geconfigureerd, van de correcte testdata zijn voorzien en beschikbaar zijn voor de test op het moment dat deze wordt uitgevoerd. Het aantal omliggende systemen varieert van een paar tot soms wel honderden in meer complexe situaties. Dit betekent dat het opzetten, bijwerken en na een test weer terugbrengen in de originele toestand van een testomgeving een steeds grotere investering en een steeds langere doorlooptijd vraagt. Dit moet en kan anders, met SV.

ROI – in cijfers

Uit onderzoek van voke Research blijkt dat SV vergeleken met traditionele testing tot aanzienlijke ROI leidt. Deze ROI is snel en gemakkelijk te realiseren.

Verkorting van de tijd om defecten te reproduceren – Maximaal 50% tijdwinst
Vermindering van het aantal productiefouten – Maximaal 41% minder productiefouten
Vermindering van het totaal aantal fouten – Meer dan 41% minder fouten in totaal
Verbetering van de testdekking – 100% meer dekking
Verbetering van de uitvoering van tests -100% meer tests
Verkorting van de testcyclus – 50% verkorting van de testcyclustijd
Verkorting van de tijd om software op te leveren – meer dan 40% verkorting van de opleveringstijd

Versnellers

Veel bedrijven zijn zich bewust van de voordelen van SV maar hebben moeite om de eerste stappen te zetten. Waarmee kan de implementatie worden versneld?

Vereis dat assets zijn gevirtualiseerd als de source code door de ontwikkelaars wordt opgeleverd
Virtualiseer componenten van derde-partijen
Virtualiseer elk deel van de softwareleveringsketen dat betaalde toegang vergt
Virtualiseer assets die deel uitmaken van de core-technologie van het bedrijf
Virtualiseer herbruikbare assets
Vereis het gebruik van SV van alle deelnemers in de softwareleveringsketen

Elk van deze stappen ruimt een belemmering op en vergroot de bedrijfsbrede adoptie.

Vertragers

Er zijn ook factoren die de adoptie van SV in de weg staan of zelfs onmogelijk maken. Uit het onderzoek van voke blijkt dat 70% van de SV-implementaties beperkt blijft tot projecten of afdelingen. Gezien het feit dat SV een doorbraaktechnologie is – cruciaal voor het opruimen van ‘constraints’ op het gebied van kosten, kwaliteit en planning, en daardoor in staat meetbare en bewezen ROI op te leveren – zou SV bedrijfsbreed moeten worden geadopteerd en daadwerkelijk gebruikt.

Onderstaand veel voorkomende vertragers in de adoptie van SV.

De belangrijkste stakeholders zien de meerwaarde van SV niet
Weerstand tegen verder kijken dan stubbing & mocking
Onvoldoende budget, vooral als er budgettaire silo’s bestaan
Beperkte trainingsmogelijkheden
Gebrek aan leiderschap om door middel van nieuwe technologie de samenwerking en productiviteit te verhogen en om de softwarelevenscyclus te transformeren
Gebrek aan voorlichting over wat SV is, waarom het belangrijk is en hoe het kan bijdragen aan software die meerwaarde biedt aan de business

Stubs & Mocks versus Service Virtualization

Een van de meest voorkomende drempels voor SV is de verwarring over stubbing & mocking versus SV. Veel ontwikkelaars verzetten zich tegen SV omdat ze denken dat de simulatie al wordt gerealiseerd met stubbing & mocking. Stubbing & mocking levert echter een schoolvoorbeeld van de stelling dat de oplossingen van vandaag de problemen van morgen vormen. SV is een ontworpen technologie, terwijl stubbing & mocking maar lapmiddelen zijn. SV daarentegen gaat uit van de feitelijke gedragingen van een systeem en vangt die in een model en niet in code. Ontwikkelaars zouden niet in de gelegenheid mogen zijn om het gebruik van SV af te wijzen omdat ze al stubs of mocks hebben gebouwd.

Stubbing & mocking is ontstaan in parallelle ontwikkelomgevingen, waaarin meerdere teams aan dezelfde code met dezelfde componenten moeten werken. De teams moeten toegang hebben tot componenten die door de andere zijn gemaakt. De situatie dat teams afhankelijk zijn van het gereedkomen van het werk van het andere wordt ‘deadlock’ genoemd. Ontwikkelaars hebben het concept van stubbing & mocking bedacht als een methode om de onderliggende bron parallel toegankelijk te maken door middel van modelering. SV daarentegen gaat wel uit van de feitelijke gedragingen van een systeem.

Kwaliteit is een probleem in stubbing & mocking omdat de stubs & mocks zelden een accurate weerspiegeling zijn van de uiteindelijke gedragingen van de onderliggende bron. Deze impact op de kwaliteit heeft een sneeuwbaleffect. Het begint met onmerkbare en onnodige defecten. Die leiden tot falende functionaliteit van een alleen tegen hoge kosten te herstellen applicatie. Het werken met stubs & mocks maakt dat de testomgeving niet-toegankelijke componenten veronachtzaamt, zoals legacy-systemen. Cruciale componenten worden buiten de test gehouden. Ze duiken pas op in de uiteindelijke end-to-end test voorafgaande aan het live gaan van het systeem. In het slechtste geval worden deze componenten zelfs helemaal niet getest voor het in productie nemen van het systeem, met alle gevolgen van dien.

SV heeft als voordeel dat het mogelijk is gedragingen van afzonderlijke componenten virtueel en incrementeel te testen voordat de volledige beschikbaarheid van alle componenten nodig is.

SV genereert gevirtualiseerde componenten die:

Realistisch gedrag vertonen
Gedeeld kunnen worden door meerdere teams in de software supply chain
Aanpassingen mogelijk maken teneinde verschillende condities en gedragingen te kunnen nabootsen
Samengesteld en ‘statefulness’ gedrag weergeven.

Anders dan stubbing & mocking laat SV ‘stateful’ componenten toe. Dit betekent dat de gevirtualiseerde component in staat is om interacties op te slaan en deze te gebruiken tijdens de test. Onbelemmerde toegang tot stateful componenten is essentieel voor de complexe software van vandaag. SV ruimt de problemen uit de weg die stubbing & mocking met zich meebrengen, zoals het ongewild introduceren van defecten, het onvermogen om gedurende de software-ontwikkelingscyclus integratietesten uit te voeren

Opmars

Organisaties in alle soorten en maten kunnen profiteren van SV. Analisten voorzien dat SV centraal zal komen te staan in de moderne softwareontwikkeling. De samenwerking tussen ontwikkeling,

quality assurance (QA) en Operations bij het tot stand komen van nieuwe of betere applicaties zal sterk verbeteren. Daardoor komt sneller software met meerwaarde voor de business tot stand.

SV is duidelijk aan een opmars bezig, maar moet het moet in de adoptie nog kritische massa bereiken. Dat zal niet lang op zich laten wachten. De technologie is beschikbaar in de vorm van producten van veelal vooraanstaande leveranciers.

Resultaten

Geen noodzaak meer om nieuwe fysieke testomgevingen te creëren
Hogere testdekking dankzij de betere beschikbaarheid van de testomgevingen
Eerdere ontdekking van fouten bij de toepassing ontwerpen en bouwen, waardoor deze gemakkelijker en goedkoper te corrigeren zijn