Hoe afhankelijk is jouw organisatie eigenlijk van één Cloudprovider?

Cloud heeft organisaties veel gebracht. Opslagcapaciteit kan snel meegroeien, infrastructuur hoeft niet volledig zelf beheerd te worden en data kan vanaf verschillende locaties beschikbaar worden gemaakt. Voor veel organisaties is Cloud daarom een vanzelfsprekend onderdeel van de storagearchitectuur geworden.

Maar juist doordat Cloud zo vanzelfsprekend is geworden, ontstaat een nieuwe vraag: hoe makkelijk kun je eigenlijk nog veranderen?

Want een storageomgeving die vandaag prima functioneert, kan over drie of vijf jaar ineens minder goed passen. Prijzen veranderen, hoeveelheden data groeien, regelgeving wordt aangescherpt en eisen rondom cyberweerbaarheid nemen toe. Dan wil je de vrijheid hebben om opnieuw keuzes te maken.

En precies daar kan afhankelijkheid van één Cloudprovider een probleem worden.

Vendor lock-in ontstaat meestal langzaam

Vrijwel geen organisatie kiest bewust voor vendor lock-in. Het ontstaat gaandeweg.

Je begint met een bepaalde hoeveelheid data bij een Cloudprovider. De omgeving groeit, er komen back-ups bij en applicaties en workflows worden rondom hetzelfde platform ingericht. Na verloop van tijd staat er zoveel data en zijn er zoveel processen mee verbonden dat overstappen technisch misschien nog wel mogelijk is, maar praktisch steeds ingewikkelder wordt.

Data moet worden verplaatst. Dat kost tijd en kan kosten met zich meebrengen. Configuraties moeten worden aangepast en processen opnieuw getest. Hoe groter de omgeving, hoe hoger de drempel om daadwerkelijk te bewegen.

De Cloudomgeving werkt nog steeds. Maar de keuzevrijheid waarmee je ooit begon, is een stuk kleiner geworden.

Dat is vendor lock-in in de praktijk.

De vraag is niet of je tevreden bent met je huidige provider

Dat klinkt misschien vreemd. Natuurlijk is het belangrijk dat een Cloudprovider vandaag goed presteert.

Maar vanuit een langetermijnstrategie is een andere vraag minstens zo relevant: Wat gebeurt er als we over een paar jaar ergens anders naartoe willen?

Misschien stijgen de kosten. Misschien wil je bepaalde data vanwege compliance dichter bij huis opslaan. Misschien ontstaat er een nieuwe technologie die beter bij je organisatie past. Of je wilt een gedeelte van je data juist weer on-premise onderbrengen.

Een goede storagearchitectuur moet niet alleen vandaag functioneren, maar ook ruimte laten voor zulke veranderingen.

Datamobiliteit wordt daarmee steeds belangrijker. Je wilt kunnen bepalen waar data staat en die keuze later kunnen aanpassen zonder de volledige storageomgeving opnieuw te hoeven ontwerpen.

Afhankelijkheid speelt ook een rol bij ransomware

Er is nog een reden om kritisch naar afhankelijkheid te kijken.

Ransomware richt zich niet alleen op productieomgevingen. Ook back-ups en aangesloten storage kunnen doelwit zijn. Wanneer productie, back-up en recovery sterk afhankelijk zijn van dezelfde omgeving, kan één incident daardoor een veel grotere impact krijgen.

Een back-up hebben is daarom niet automatisch hetzelfde als goed kunnen herstellen.

De belangrijkere vragen zijn: hoe is die back-up beschermd? Kan opgeslagen data achteraf worden gewijzigd of verwijderd? Hoe gescheiden zijn verschillende opslaglagen? En is er nog een bruikbaar herstelpunt wanneer een deel van de infrastructuur wordt geraakt?

Daar komen begrippen als immutable storage, snapshots, zero-trust en gescheiden storageomgevingen in beeld.

Niet als losse features die je moet afvinken, maar als onderdelen van een bredere recoverystrategie.

Van single Cloud naar Hybrid Multicloud

Een manier om afhankelijkheid te verminderen is data niet volledig rondom één storageprovider te organiseren.

Bij een Hybrid Multicloud architectuur kunnen verschillende storageomgevingen naast elkaar worden gebruikt. Denk aan publieke Cloud, private Cloud, on-premise storage en object storage.

Dat betekent overigens niet dat iedere organisatie zijn data over zoveel mogelijk Clouds moet verspreiden. Dat zou het beheer juist onnodig ingewikkeld kunnen maken.

De gedachte erachter is veel eenvoudiger: zorg dat één provider niet automatisch je volledige storagearchitectuur bepaalt.

Daarmee ontstaat ruimte om verschillende storageomgevingen een eigen rol te geven en die keuzes later weer aan te passen.

Hoe Vawlt dit anders aanpakt

Vawlt is een voorbeeld van zo’n andere benadering.

Het is geen nieuwe Cloudprovider waar alle data opnieuw naartoe moet worden verhuisd. Vawlt vormt een softwarelaag waarmee verschillende storageomgevingen kunnen worden gecombineerd.

Daarbij wordt data client-side versleuteld en vervolgens gefragmenteerd. Die encrypted fragments kunnen over verschillende onafhankelijke storage targets worden verdeeld, waaronder publieke Clouds, private Cloud en on-premise storage.

Een belangrijk verschil is dat dit geen volledige kopieën van dezelfde dataset zijn. De afzonderlijke fragmenten zijn zonder de overige delen en de encryptiesleutel niet voldoende om de oorspronkelijke data te reconstrueren.

De encryptiesleutels blijven bovendien binnen de omgeving van de organisatie. Vawlt en de gebruikte Cloudproviders hebben daar geen toegang toe.

Dat maakt de onderliggende storageproviders feitelijk onderdelen van de architectuur, in plaats van dat één provider de architectuur bepaalt.

En je bestaande storage dan?

Die hoeft niet automatisch vervangen te worden.

Dat is juist een interessant aspect van deze aanpak. Bestaande on-premise storage kan onderdeel blijven van de architectuur en worden gecombineerd met publieke of private Cloud.

Voor organisaties die in de loop der jaren flink hebben geïnvesteerd in storage is dat relevant. Een nieuwe strategie hoeft namelijk niet te betekenen dat alles wat er staat ineens de deur uit moet.

Soms is het veel logischer om een extra laag toe te voegen waarmee bestaande en nieuwe storage slimmer met elkaar kunnen samenwerken.

Ook recovery wordt daarmee anders

Vawlt combineert de gedistribueerde architectuur met functionaliteiten zoals real-time snapshots en immutability.

Bij wijzigingen aan bestanden kunnen snapshots worden gemaakt waarmee naar een eerder moment kan worden teruggekeerd. Immutability kan voorkomen dat beschermde data binnen een ingestelde periode wordt gewijzigd of verwijderd, ook wanneer iemand over uitgebreide beheerrechten beschikt.

Dat betekent niet dat ransomware onmogelijk wordt. Geen enkele storagearchitectuur kan dat beloven.

Het betekent wel dat je nadenkt over de vraag die na een incident uiteindelijk het belangrijkst wordt: kunnen we onze data nog herstellen?

Hoeveel bewegingsvrijheid heb je vandaag?

Misschien is dat een interessante test voor je huidige storageomgeving.

Stel dat je morgen besluit een andere Cloudprovider te willen gebruiken. Hoe ingewikkeld is dat?

Kun je bepalen in welke regio gevoelige data wordt opgeslagen? Kun je een gedeelte van je storage weer lokaal onderbrengen? Wat kost het om grote hoeveelheden data terug te halen? En wat gebeurt er met je recoverymogelijkheden wanneer één omgeving niet beschikbaar is?

Als het antwoord op die vragen niet direct duidelijk is, is het misschien tijd om niet alleen naar je opslagcapaciteit te kijken, maar naar de architectuur erachter.

Want uiteindelijk gaat een toekomstbestendige storageomgeving niet alleen over waar je data vandaag staat.

Het gaat er ook om hoeveel vrijheid je morgen nog hebt.

Meer weten over Vawlt Hybrid Multicloud Storage?

Tapes.nl helpt organisaties al meer dan 35 jaar met storage, back-up en archivering. Daarbij kijken we niet naar één technologie als oplossing voor alles, maar naar de combinatie die past bij de data, workflow, beveiliging en toekomstplannen van een organisatie.

Met Vawlt voegen we daar een nieuwe mogelijkheid aan toe voor organisaties die Cloud willen blijven gebruiken, maar tegelijkertijd meer controle willen over waar hun data staat en hoe afhankelijk zij zijn van individuele storageproviders.