Het thema ‘lock-in’ is erg populair. ‘Lock-out’ zou dat ook moeten zijn!

Het heden verblindt ons. We kijken niet voldoende naar de lange termijn. We stellen ons niet de volgende vraag: “Wat als er over 90 dagen een andere kans of realiteit zich voordoet?” Dat is het onderwerp van lock-out.

“Wij zijn verantwoordelijk voor onze gegevens! Wat gebeurt er als we over drie maanden een bepaalde functionaliteit nodig hebben en we daarvan ‘uitgesloten’ zijn? We zijn bang voor lock-in door een leverancier, maar vergeten lock-out, waarvoor we zelf volledig verantwoordelijk zijn”, aldus Michael Cade, Global Field CTO, Veeam Software. Concreet gezegd: we verzuimen om onszelf opties open te houden!”

Vergrendeling van accounts in versterkte repositories, opslagproblemen zoals storingen in de nalevingsmodus van objectvergrendeling die specifieke herstelprocedures vereisen… Dat is lock-out. En nog veel meer.

Vergrendelingsbeleid

“Lock-out van gegevens kan verwijzen naar een plotselinge blokkering van de toegang tot gegevens of de configuratie van een systeem, vaak veroorzaakt door verkeerd geconfigureerde accountvergrendelingsbeleidsregels of systeemproblemen, maar ook naar de functie van onveranderlijkheid van gegevens, die verhindert dat gegevens gedurende een bepaalde periode worden gewijzigd of verwijderd“, legt Michael Cade uit. Accountvergrendelingsbeleid blokkeert ongeoorloofde toegangspogingen na een bepaald aantal mislukte pogingen, terwijl de onveranderlijkheidsfunctie – bijvoorbeeld met S3 Object Lock – gegevens beschermt tegen ransomware-aanvallen.

Paradoxaal genoeg denken we meer aan lock-in dan aan lock-out. Bij Veeam, dat alles heeft ingezet op de flexibiliteit van het draagbare gegevensformaat, is lock-in geen issue. “Als u om welke reden dan ook besluit om geen klant van Veeam meer te zijn, profiteert u van een groot voordeel: een uitweg! De klant hoeft geen onderhoudskosten te betalen om zijn workloads te herstellen en langere back-ups te maken.”

Onze gegevens begrijpen

Dit leidt tot meer flexibiliteit. En een beter kostenbeheer. Voor Michael Cade gaat het erom verder te kijken. “We hebben de muren van de datacenters doorbroken”, illustreert hij. “Dat betekent dat we niet meer op dezelfde plek hoeven te zijn, maar dat onze gegevens over meerdere platforms zijn verspreid. Dat betekent dat we onze gegevens moeten ‘begrijpen’, moeten weten welk deel van die gegevens het meest cruciaal is. We hebben ze nog steeds nodig, maar ze zijn waarschijnlijk niet zo belangrijk als we denken, vooral als er zich een probleem voordoet. Toch is het essentieel om te weten waar onze meest cruciale gegevens zich bevinden, om ze perfect te kunnen lokaliseren.”

Het antwoord begint bij het creëren van de gegevens zelf. Met andere woorden, het beheer van de levenscyclus van gegevens. Het begrijpen van uw gegevens is in veel opzichten essentieel: hoe u ze kunt beschermen, hoe u ze kunt verplaatsen, waar ze beschikbaar zijn en nog veel meer.

Identificeer redundante gegevens

“Uiteindelijk hangt alles samen. En alles begint met de applicatie zelf. Je moet altijd beginnen met de applicatie, of die nu op Kubernetes, op een virtuele machine of op een fysieke server draait; hij moet er zijn, of je hem nu zelf hebt ontwikkeld of gekocht. Vervolgens moet je het ergens uitvoeren: dat is het beheer van de levenscyclus van de infrastructuur. Deze kan handmatig worden gebouwd. Of misschien gebruiken we IaC (Infrastructure-as-Code) of andere automatiseringstools. Vervolgens gaat het om het beheer van de continue levenscyclus.”

Volgens Michael Cade is het jammer dat we geen toegang hebben tot nieuwe functionaliteiten in het algemeen. Dat geldt ook voor databases. “Als je kiest voor Amazon RDS, ben je afhankelijk van de updates van deze database door Amazon. Dat kan Postgres 16 of 17 zijn. En als de update niet snel genoeg komt, loop je de nieuwe functionaliteiten van de nieuwe versie van Postgres mis als je ervoor kiest om bij Amazon RDS te blijven in plaats van je eigen versie te gebruiken. Uiteraard moet je dan deze versie meer beheren dan de RDS-versie.”

Niet meer nodig? Dan weg ermee!

Het belangrijkste is dat we kunnen samenwerken, evolueren en redundantie kunnen onderzoeken. Met andere woorden: redundante, verouderde of triviale gegevens identificeren. En de vraag “Hebben we dit nog nodig?” kunnen beantwoorden.

“Dit leidt tot een gezondere benadering van gegevens: als we ze niet meer nodig hebben, kunnen we ze beter weggooien, want de opslag ervan is waarschijnlijk duur. Zorg er vervolgens voor dat de bewaarde gegevens van de hoogste kwaliteit zijn, dat ze op de meest performante opslag staan, dat ze beschermd zijn en optimale veerkracht bieden. Dan zit je goed!”

foto : Jan Volejníček