Niet iedere applicatie kan zonder aanpassingen worden verplaatst naar een tweede cloud- of hostingomgeving. Broncode kan bijvoorbeeld vaste IP-adressen, lokale bestandspaden of providerspecifieke diensten gebruiken.
Een beter overdraagbare applicatie gebruikt centrale configuraties, omgevingsvariabelen en reproduceerbare deployments. Hierdoor kan dezelfde software in verschillende omgevingen worden uitgerold zonder de broncode afzonderlijk aan te passen.
Ook sessies en achtergrondprocessen vragen aandacht. Wanneer gebruikerssessies alleen lokaal op één server worden opgeslagen, raken gebruikers bij een overschakeling mogelijk uitgelogd. Wachtrijen en geplande taken moeten eveneens voorkomen dat werkzaamheden dubbel worden uitgevoerd of volledig verloren gaan.
Data bepaalt of een fallbackomgeving bruikbaar is
Replicatie en herstelpunten moeten aansluiten op het gewenste overschakelmoment
Een tweede applicatieomgeving heeft weinig waarde wanneer de benodigde gegevens daar ontbreken of sterk zijn verouderd. Databasereplicatie en synchronisatie van bestanden zijn daarom essentiële onderdelen van redundantie.
Bij synchrone replicatie worden wijzigingen direct naar meerdere locaties geschreven. Dit beperkt mogelijk gegevensverlies, maar kan de verwerking vertragen wanneer de afstand of netwerkvertraging toeneemt. Bij asynchrone replicatie wordt data kort na de oorspronkelijke verwerking gekopieerd, waardoor bij een plotselinge storing een kleine hoeveelheid recente data verloren kan gaan.
De gekozen methode moet technisch passen bij de applicatie. Ook moet duidelijk zijn hoe conflicten worden voorkomen en welke database leidend is wanneer de primaire omgeving opnieuw beschikbaar komt.
Failover moet worden geautomatiseerd en getest
Een uitwijkomgeving werkt pas wanneer de volledige overschakeling aantoonbaar functioneert
Tijdens een storing is er weinig ruimte om handmatig uit te zoeken welke stappen nodig zijn. Daarom moeten deployments, configuraties en overschakelprocedures zo veel mogelijk reproduceerbaar zijn.
Monitoring kan signaleren dat een applicatie of regio niet meer reageert. Een load balancer, DNS-configuratie of andere routeringslaag kan verkeer vervolgens naar een beschikbare omgeving leiden. Daarbij moet worden gecontroleerd of de fallbackomgeving voldoende capaciteit heeft en alle noodzakelijke diensten bereikbaar zijn.
Periodieke tests zijn noodzakelijk om vast te stellen of de procedure nog werkt. Configuraties, databaseversies en API-koppelingen veranderen voortdurend. Een fallbackomgeving die maandenlang niet is getest, kan daardoor juist op het noodzakelijke moment fouten bevatten.
