Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Det kan give god mening at have Zoom eller Google Meet i baghånden, hvis Teams er nede, men for forretningskritiske systemer kræves reelt en ’kopiering’ af disse.
Hvis virksomhedens webshop kører på Microsoft Azure cloudløsningen hjælper det i tilfælde af et Azure-nedbrud således ikke, hvis for eksempel virksomhedens CRM-løsning er leveret af Salesforce, der ikke kører på Azure (men leveres af Salesforce som en hosted SaaS løsning).
I det følgende argumenterer jeg for, hvor meget det vil kræve, og hvor lidt det vil give af reduceret risiko, hvis ovennævnte eksempel med webshoppen på Azure skal køre på en anden cloudløsning også.
Jeg vil også mene, at det vil være en tilsvarende situation (eller endnu værre), hvis der i stedet var tale om at lave endnu en cloud-løsning for eksempelvis et ERP- eller et CRM-system.
Det kræver ’en synkroniseret kopi’ af webshoppen
Hvis eksempelvis webshoppen også skal køre på Amazons’ AWS cloudløsning, for at denne skal være back-up i tilfælde af at Azure er nede, skal den fulde kode, alt indhold og alle data til enhver tid også være tilgængelige på AWS.
Man kunne selvfølgelig bygge en helt separat løsning, hvor der reelt ville være installeret en CMS- og eCommerceløsning som eksempelvis Episerver på både Azure og AWS, og hvor der skulle releases opdateringer, forbedringer mv. på begge systemer. Dette ville være en omfattende opgave både at udvikle og at drifte.
Så lad os i stedet forestille os, at Azure-servere, som webshoppen er på, med høj frekvens kunne spejles, dvs. kopieres og synkroniseres til Amazon servere.
Selv om det måske kunne fungere rent teknisk, ville det hurtigt give problemer for integrationerne til webshoppen.
Eksempelvis en integration til en betalingsudbyder kunne måske forholdsvis enkelt kaldes også fra det alternative AWS-miljø, men de fleste - hvis ikke alle - integrationer vil typisk være bygget i Azure-regi, herunder som microservices. De vil jo så også være nede, og derved være utilgængelige.
Derfor vil der til AWS-løsningen skulle bygges en række direkte integrationer til både eksterne parter og til virksomhedens interne systemer.
Udover at det vil være omfattende vil det også betyde, at den alternative AWS-løsning ville blive lidt et kludetæppe af spejling fra Azure- og AWS-specifikke integrationer.
Om det overhovedet kan lade sig gøre, kræver det sikkert en dygtig it-arkitekt at afgøre, men hvis svaret er ja, vil anbefalingen formentlig være en kraftig advarsel mod at gøre det.
Så vi er altså uanset hvad ude i, at det vil kræve en meget stor indsats at udvikle en løsning, der sikrer at et forretningskritisk system som en webshop kan switche til en anden cloudløsning i tilfælde af nedbrud.
Det vil derfor være ekstremt dyrt at have denne ’forsikring’
Det vil være meget dyrt at have sådan en parallel løsning klar som back-up:
- Selve implementeringen som beskrevet ovenfor vil kræve en meget stor indsats
- Der vil være løbende, høje omkostninger til hosting og overvågning hos den anden cloudpartner
- Nye opdateringer og kode skal også i et vist omfang testes og tjekkes på back-up løsningen
- Alle integrationerne på back-up løsningen skal også løbende overvåges og fejlrettes, hvis der opstår problemer
Cloudløsningen indebærer ikke i sig selv den største risiko for nedetid
Cloududbydere som Microsoft gør alt der står i deres magt for at sikre, at deres cloudløsninger ikke går ned, og de største risici for nedetid på et website ligger reelt alle mulige andre steder, herunder:
- Banale fejl opstår i integrationer eller en betalingsudbyder har et nedbrud
- Der opstår alvorlige fejl i selve koden eller softwaren bliver pludselig ustabil
- Webshoppen er afhængig af real-time kald til et internt system (eksempelvis for at få lagerstatus eller hente kundespecifikke rabatter), der går ned, eller hvor integrationen pludselig fejler
Og endelig vil det i tilfælde af et cloudnedbrud ofte være begrænset, hvor megen glæde virksomheden vil nå at have af en back-up cloudløsning.
Selv ved et cloudnedbrud vil der være en reaktionstid, inden back-up løsningen er i drift
Lad os antage, at en virksomhed alligevel har etableret en kopi af webshoppen på Amazon AWS, og at Microsoft Azure nu går ned.
Det skal da sikres, at trafikken kommer over på AWS i stedet.
Dette kunne formentlig gøres ved en load balancer, som dirigerer trafikken derhen, hvor der er kapacitet, men den skal også stå i et miljø og kan derfor også gå ned.
Hvis den står i Azure, vil den være gået ned, men omvendt hvis den står i AWS eller et tredje sted, vil et nedbrud der også få webshoppen til at gå ned.
Alternativt kan der foretages en redelegering af domænet, så det peger over på AWS-versionen af webshoppen, men det kan tage flere timer, før det er slået helt igennem.
Oveni kommer reaktionstiden fra fejlen opdages, årsag er afklaret og nødløsningen eksekveret. Og længere tid varede det i hvert fald ikke her i januar, før Microsoft havde løst fejlen (der viste sig – som det ofte er – at skyldes noget helt banalt med en IP-adresse).
Så samlet set er det min anbefaling at fokusere på andre indsatser for at reducere risici for nedbrud i forretningskritiske systemer.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.