.png){kind=small}
Cloud Test Data Management
Veel organisaties onderzoeken de eindeloze mogelijkheden van cloud computing. Voor bijna elke letter van het alfabet lijkt er een “as a Service” variant beschikbaar te zijn! Van opslag, hardware, databases, netwerken tot software, bijna alles kan worden gekocht van platforms zoals Microsoft Azure en Amazon AWS. Binnen enkele minuten kun je nieuwe snelle en grote virtuele machines laten draaien en nog sneller vernietigen, maar hoe maak je dit betaalbaar? Voordat we daarop ingaan, laten we eerst de terminologie doornemen.
Werken in de cloud is soms wat anders dan on-premise oplossingen. Bij testdatabeheer is de reden voor deze verschillen dat je altijd verbinding kunt maken met on-premise databases, maar met ‘de cloud’ is dat niet altijd het geval.
In het algemeen onderscheiden we twee verschillende soorten ‘cloud’:
- Een database in de cloud
- SAAS, cloud of gehoste applicaties
Databases in de cloud
Als het alleen een database is die in de cloud is geïmplementeerd, kunnen de testgegevens worden beheerd door DATPROF. We ondersteunen momenteel MySQL, SQL, Oracle, Postgress, MariaDB, EDB, DB2 navitely en we ondersteunen AzureSQL en Aurora. Deze databases kunnen worden beheerd door de DATPROF toolset. Het belangrijkste verschil tussen cloud- en lokale databases is dat de verbindingsreeks anders is.
DATPROF Supported cloud databases
SAAS, Cloud of gehoste applicaties
Interessanter wordt het als je denkt aan applicaties in de cloud of een SAAS applicatie. Vanuit het perspectief van testdatabeheer zien we twee verschillende strategieën van gehoste/SAAS-applicaties:
- Sommige applicaties zijn beschikbaar in de cloud en je kunt nog steeds verbinding maken met de database onder de applicatie
of
- De applicatie is beschikbaar in de cloud, maar je kunt geen verbinding maken met de database (bijvoorbeeld Salesforce)
Beide voorbeelden van toepassingen worden door softwareleveranciers als SAAS-toepassingen genoemd. We maken onderscheid tussen deze twee voorbeelden. Want als je verbinding kunt maken met de database, kan DATPROF je testgegevens beheren. In dit geval is er vanuit ons perspectief niet veel verschil tussen een database in de cloud of een applicatie in de cloud.
Het tweede voorbeeld over Cloud- of SAAS-applicaties is uitdagender. De reden is dat onze voorkeursaanpak is om rechtstreeks verbinding te maken met databases om de testgegevens te beheren. Bij deze leveranciers mag dit niet. Maar er zijn enkele alternatieve routes. Wat we kunnen doen is de gegevens extraheren naar een andere database, testgegevensprocessen uitvoeren (subsetting en/of maskering) en de gegevens terug in de database injecteren. Met dit proces is het ook mogelijk om je testgegevens ook in deze omgevingen te beheren.
Cloud data duur?
Het migreren van grote organisaties met on-premise systemen naar de cloud kan best lastig zijn. Zelfs het onderzoeken van de verschillende prijsopties van de verschillende instantietypes is niet eenvoudig. Heb je een D2sV3 of E2sV3 nodig en hoe verhoudt deze zich tot een r5d.large? Alleen al in Azure zijn meer dan 200 verschillende instantieconfiguraties beschikbaar. In het algemeen is de prijs afhankelijk van het aantal CPU-cores, het geheugen en de maximale schijfcapaciteit. Opslagkosten zijn meestal afhankelijk van de grootte, het type (SSD of HDD) en de replicatie-opties die je selecteert.
Wanneer je overstapt naar AWS of Azure, gaan niet alleen je productiegegevens naar de cloud, maar ook je test- en ontwikkelomgevingen. De meeste organisaties die naar de cloud migreren, gebruiken al Agile/DevOps-methodologieën. Deze ‘nieuwe’ manier van werken vraagt om een andere manier van omgaan met testdata. Elk team moet zijn eigen testgegevens hebben en mag niet afhankelijk zijn van andere teams die dezelfde testgegevens gebruiken. De cloud kan zoveel omgevingen beschikbaar maken als je nodig hebt, maar zelfs in de cloud zijn deze kopieën van productie-instances extreem kostbaar. Misschien heb je geen dure rampen- of replicatiefuncties nodig, maar de algehele configuratie moet waarschijnlijk zo goed mogelijk overeenkomen met de productiespecificatie.
De juiste hoeveelheid test data
Gelukkig behoort het werken met testgegevens op ware grootte tot het verleden. Tegenwoordig kunnen we specifieke subsets, zelfs geanonimiseerd, extraheren uit grote complexe productiedatabases voor testen, ontwikkeling en training.
Het echte voordeel van het werken met compacte, kwalitatief goede en veilige testdata is dat je echt het volledige potentieel van de cloud kunt ontsluiten. Door met de juiste hoeveelheid testgegevens te werken, kun je gemakkelijk duizenden euro’s besparen, omdat je ontwikkel- en testinstanties minder CPU-kracht, minder geheugen en minder opslagruimte nodig hebben. Je Dev- en QA-teams worden efficiënter door hun eigen testgegevens te beheren en kunnen meer testen in minder tijd. Dit leidt tot software van betere kwaliteit die sneller kan worden vrijgegeven voor het uiteindelijke voordeel van het bedrijf.
Data subsetting
Het subsetten van testgegevens is het extraheren van een kleinere – referentieel intacte – set met data uit een productiedatabase naar een niet-productieomgeving.
