Indien u gebruikmaakt van een clouddienst dan zult u vaak ook de data die u invoert in de cloud bewaren. Met andere woorden, u voert uw data in en deze wordt niet op uw eigen server opgeslagen maar op een server van de clouddienstverlener. De server kan in eigendom zijn van de dienstverlener of van een derde. Deze derde is de hoster. Om de keten nog langer te maken: de server staat weer in een rack en dit rack staat in een datacenter. Dat datacenter is weer een andere partij.
Ook hier zijn meerdere scenario’s mogelijk om de continuïteit (van uw data en de applicatie) zeker te stellen. Welk scenario het beste is, is afhankelijk van wat de dienstverlener wilt, wie de dienst (hosting) levert, waar het eigendom (van de server) ligt en hoever uw budget reikt. Het doel blijft ervoor te zorgen dat uw data en eventueel ook de applicatie intact en toegankelijk blijft zodat er voldoende tijd is voor migratie van de data of een overname van de applicatie door een andere dienstverlener.
Indien de SaaS dienstverlener de data door een derde laat hosten, dan zal de Stichting een overeenkomst sluiten met de ingehuurde hoster. Op het moment dat de continuïteit bedreigd wordt, moet deze overeenkomst ervoor zorgen dat de hoster gewoon blijft hosten en niet de stekker eruit trekt. Juridisch gezien zal er vaak sprake zijn van een overeenkomst die tot leven komt onder de opschortende voorwaarde dat de continuïteit bedreigd wordt.
Het is echter niet handig om klakkeloos bestaande contracten over te nemen. Dit kan de kosten flink opjagen. Er moet gekeken worden wat nodig is. Er moet een periode van continuïteit worden afgesproken waarin de hoster blijft doorleveren en de Stichting zorgt dat die rekening betaald wordt.
Het kan ook zijn dat dienstverlener kiest voor colocatie en dus de servers in eigendom heeft die bij een ander in het datacenter staan. Op het moment dat de eigenaar de rekeningen van het datacenter niet meer betaald, is er een kans dat de stekker eruit gaat. In het ergste geval is het de curator die de server verpatst. In het minder ernstige geval, is het de datacenter-houder het die de stekker eruit trekt. Beide gevallen moeten voorkomen worden.
Bij een eigen server (van de dienstverlener) is het een goed idee om met een sale-and-leaseback-constructie te werken. Wees hierbij wel altijd scherp op mogelijke verpandingen van de servers aan derden. In deze constructie worden de servers verkocht aan een ander dan de dienstverlener die de servers dan weer aan de dienstverlener verhuurt. Deze ander kan zijn de klant of een aparte economische entiteit. De Stichting sluit een overeenkomst met de nieuwe eigenaar omtrent het gebruik van de servers voor de duur van de continuïteit die geboden moet worden om overname van de dienst of migratie mogelijk te maken.
Indien uw budget het toelaat en indien het noodzakelijk is voor uw bedrijfsvoering, kunt u er voor kiezen om een mirror van uw data bij een andere hoster te draaien. Óf zelfs een hotstandby, daarmee bedoel ik dat niet alleen de data dubbel wordt opgeslagen maar ook de applicatie (volledig up to date en direct te gebruiken) dubbel draait bij een andere hoster. Dit kan betekenen dat er een extra licentie moet worden afgenomen. Voorgaande voorkomt zowel discontinuïteit bij faillissement van de clouddienstverlener als van de hoster. Of u beide aanpakt, hangt af van hoever u wilt gaan en in hoeverre uw bedrijfsvoering afhankelijk is van de data en applicatie.
Er is wel een kanttekening bij bovenstaande oplossingen. Uw data moet migreerbaar zijn. Als er sprake is van een vendor lock-in wordt het lastig de data uiteindelijk over te zetten naar een applicatie van een andere clouddienstverlener. Ik raad dan ook aan dat u bij het uitzoeken van een applicatie hiermee rekening houdt.
Het volgende deel in deze serie gaat over de mogelijk voor de continuïteit cruciale factor: de bedenkers en uitvoerders van de clouddienst, de werknemers of ZZP’ers.
