Regelmatig ben ik in gesprek met bedrijven waarbij vaak herhaaldelijk dezelfde onderwerpen aan bod komen. Voor een deel zijn dat traditionele IT onderwerpen en voor een deel zou je ze modeverschijnsel of hype kunnen noemen. Deze onderwerpen lijken onderling een verband te hebben. Om te beginnen zijn het natuurlijk allemaal architectuuronderwerpen. Maar dat is niet wat ik bedoel. Wat ik bedoel is dat het behalen van een doelstelling bij het ene onderwerp lijkt samen te hangen met die van een ander onderwerp. Simpeler gezegd, de doelstellingen van meerdere onderwerpen zijn vaak middels een enkel design te behalen. In dit artikel belicht ik deze invalshoek.

RTO en RPO

Sinds jaar en dag proberen IT architecten te achterhalen wat de beschikbaarheid van een applicatie is (of moet zijn). Dit gegeven is een belangrijk aspect bij het design. Dit wordt Recovery Time Objective genoemd (RTO). Dat is de tijd dat een applicatie maximaal niet beschikbaar mag zijn. Als de applicatie niet beschikbaar is, of slecht functioneert, kan er data verloren gaan. Graag ontwerpen we applicaties ook daarvoor. Wat is het maximale verlies van data dat we kunnen toestaan. Dit wordt Recovery Point Objective genoemd (RPO).

Ik probeer deze vragen altijd aan bod te laten komen, maar mij valt op dat klanten hier nogal eens het antwoord niet weten. De “Business” bepaalt dit vaak aan de hand van bijvoorbeeld het financiële verlies dat geleden wordt als de applicatie niet beschikbaar of bij het verlies van data. De kosten om bepaalde RTO en RPO waarden te halen moeten opwegen tegen dit veronderstelde verlies. Dit is iets waarover je in gesprek moet gaan met de “Business”.

Meestal zijn de eisen die aan RTO en RPO gesteld worden niet zo hoog. Een goede backup (en restore) zijn dan een voldoende garantie om de applicatie binnen een paar uur termijn weer operationeel te hebben. Backup & restore is dan ook de eenvoudigste van de 4 Disaster Recovery methoden die er zijn. Het meest complexe en duurste DR scenario is multi site. Hierbij draait de applicatie op twee plekken (twee datacenters, of in combinatie met een hyper scaler). Het voordeel hiervan is dat een dergelijke setup een veel betere RTO en RPO waarden mogelijk maakt.

Welke DR scenario's zijn er dan allemaal?

Als eerste en meestal simpele DR scenario is er "Backup & restore". Bij dit scenario duurt de restore het langste (enkele uren) en zijn er de hoogte (slechtste) RTO en RPO waarden.
Als tweede is er de "Pilot Light". Hierbij draait een basis setup (vooral de data) van de applicatie ook op een andere site. Bij een disaster kan deze kant verder opgestart en opgeschaald worden. Dit gaat al sneller dan de restore van de backup.
Als derde is er het DR scenario van de "Warm Standby". De applicatie "Leeft" op twee locaties. Failover kan snel, maar het nadeel is dat altijd een van de twee onnodig actief is, dubbele kosten dus.
Als laatste DR scenario is er "Multi Site". Hierbij wordt de applicatie op beide kanten actief gebruikt en is er de kortste fail over tijd. Beide kanten worden actief gebruikt.
Voor de laatste drie DR scenario's geldt dat er data replicatie gedaan moet worden.Data moet op beide locaties beschikbaar zijn in het geval van een fail over. https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html

Kostenreductie

Een ander onderwerp dat altijd ter sprake komt zijn oplopende kosten – veelal in combinatie met het inzetten van een cloud provider / hyper scaler. De kosten zijn vaak opgelopen omdat er van alles beschikbaar is en de engineers / developers die applicaties bouwen niet direct met de kosten geconfronteerd worden. Strak sturen op kosten is best ingewikkeld en verlangt dat alle betrokkenen daaraan mee werken. Afspraken over wanneer resources verwijderd kunnen worden zijn bijvoorbeeld erg effectief, wat je niet gebruikt kost ook niets. Van datgene dat je dan nog wel gebruikt is het zaak dat optimaal te gebruiken. Right Sizing is het afstemmen van de gebruikte resources en datgene dat er echt nodig is.

Applicatie modernisatie

Hoewel Right Sizing van resources slim is, zegt het niets over hoe de applicatie resources aanspreekt. Het stroomlijnen van de applicatie is nodig om ervoor te zorgen dat het efficiënt met resources omgaat. Dit valt vaak onder wat men applicatie modernisatie noemt. Hieronder worden overigens meer zaken verstaan. Het stroomlijnen van het resources gebruik is er een, maar ook het vernieuwen van de code valt hieronder, of het vernieuwen van de runtime software. Maar pak je de applicatie aan voor een van deze redenen, waarom dan niet gelijk ook voor de andere?

Wil men de afhankelijkheid van Amerikaanse (of commerciële) software verkleinen, dan is het daarnaast zaak om andere productkeuzes te maken, bijvoorbeeld kies voor open source software en kies voor een Europese cloud provider. Dit is overigens iets waar nu steeds meer bedrijven over nadenken.

Maintenance effort

Zoals ik eerder al eens heb betoogd is het onderhoud (maintenance) de belangrijkste verantwoordelijkheden van een IT afdeling of IT bedrijf. De onderhoud inspanning voor een applicatie is echter niet gedurende de levensduur van de applicatie constant. In de meeste gevallen neemt de effort voor onderhoud vrijwel altijd toe. Veranderingen in software versies maakt dat upgraden steeds lastiger wordt en na verloop van tijd zelfs onmogelijk. Dat is ook waarom “Decommissioning” zo waardevol is voor een organisatie. Het moderniseren van een applicatie kan gebruikt worden de onderhoudsdruk te verlagen. Sterker nog, dat is de belangrijkste reden waarom je dat doet.

Digital Sovereignty en portability

Als reactie op alle geopolitieke ontwikkelingen willen bedrijven de afhankelijkheden van buitenlandse technologie verkleinen. Voor veel bedrijven best wel vervelend, want ze waren net klaar met de migratie naar een Amerikaanse Cloud provider / hyper scaler. Als je voorbereid wilt zijn en wilt kunnen garanderen dat je baas blijft van data (Data Sovereignty) en je de beschikbaarheid van de applicatie zeker wil stellen (Operational Sovereignty, samen wel Digital Sovereignty genoemd), dan wil je de applicatie en data naar een ander platform kunnen verplaatsten. Dat is dan portability waarover gesproken wordt. Het raakt hiermee aan de DR scenario’s die we eerder bespraken. De portability van een applicatie vergroten raakt daarmee ook aan de applicatie modernisatie. Mijn idee hierbij is: design ineens voor alle doelstellingen.

Naast algemene portability, is er soms sprake van specifieke data portability en software portability.

Hoe dan?

Ja hoe ontwerp je dan voor portability? Door het ontwerp vraagstuk bijvoorbeeld gelaagd aan te pakken. De onderste laag is het datacenter of de hyper scaler. Deze laag is specifiek, ze kunnen van elkaar verschillen. Services zijn verschillend, netwerken anders enz. Op deze specifieke laag kan je een platform bouwen, bijvoorbeeld een Kubernetes cluster. Dat cluster is specifiek voor het datacenter of hyper scaler waarop het draait, maar is generiek voor de applicatie containers. Draaien deze op het ene cluster, dan kunnen ze dat (in principe) ook op het andere. Deze derde laag (de applicatie) kan daarmee generiek zijn. Dat is een belangrijk deel van de portability.

Als in de applicatie ook data opgeslagen wordt, dan moet ook data replicatie geregeld worden (eerder schreef ik over data replicatie). Bovendien kunnen deze onderwerpen aangepakt worden tijdens een ronde van applicatie modernisatie. Daarmee raken deze onderwerpen dus aan elkaar.

Kortom, mijn kijk op de zaak is dat we verschillende doelstellingen kunnen behalen met één design. Door te ontwerpen voor portability op bijvoorbeeld Kubernetes slaan organisaties drie vliegen in één klap: lagere kosten, betere DR en digitale soevereiniteit”. Een doordachte architectuur die meerdere doelen dient.