Nedbrud og monokultur: Ingen bliver fyret for at vælge Amazon

Engang var det IBM, siden blev det Microsoft. I dag er det Amazons sky. Men hvorfor er det, at vi har det med at opbygge monokulturer inden for it?

Amazons sky blev tirsdag sidste uge ramt af et nedbrud, som i fem timer påvirkede ikke bare Amazon selv, men også en stribe internettjenester, der benytter sig af Amazons infrastruktur. Nedbruddet blev udløst af en fejl i indtastningen af en kommando, som én af Amazons systemadministratorer var i færd med.

Det var relativt få servere i én af Amazons serviceregioner, der lukkede ned, men de viste sig altså at være en vigtig komponent i infrastrukturen hos en lang række internettjenester.

150.000 hjemmesider blev berørt i forbindelse med nedbruddet, forlød det.

Man skal ikke lægge alle æg i samme kurv, lyder det. Det burde vel også gælde for it-drift. Amazons sky er den suverænt største, hvor kun Microsofts Azure reelt kan måle sig, og det endda kun på visse tjenester. Konkurrenter som Google og IBM når knapt Amazon til sokkeholderne.

Læs også: Slåfejl lagde Amazons storage-servere ned

Så når Amazons sky bliver ramt af et nedbrud, så bliver rigtigt mange websteder og applikationer taget med ned i faldet.

Er det et problem?

Der var engang, hvor man sagde, at ingen blev fyret for at vælge IBM. Det var i mainframens storhedstid. I pc'ens storhedstid blev det til, at ingen blev fyret for at vælge Microsoft. Og i skyens storhedstid er der næppe nogen startups, som mister deres funding, fordi de lægger det hele hos Amazon.

I it-branchen er der en vis tendens til at skabe monokulturer, selvom vi ved, at det fører til sårbarhed, når noget går galt.

Udfordringen er imidlertid, hvad vi skal sammenligne risikoen for et omfattende nedbrud i Amazons sky med, hvis kunderne skulle vælge en anden løsning?

Et nedbrud hos en monolit rammer mange på én gang. Til gengæld sker nedbruddene forholdsvis sjældent, og varer som regel få timer. Oppetiden er for den enkelte kunde sammenlignelig med, hvad der kan lade sig gøre med egen drift, uden at skulle ud i at bygge særligt resistente arkitekturer.

Summen af total nedetid er til gengæld sværere at opgøre. Var der sammenlagt flere timers driftsforstyrrelse for de websteder og apps, som bygger på Amazons infrastruktur, end de samme kunder ville have haft, hvis de selv skulle stå for infrastrukturen?

Læs også: Microsoft: Azure-nedbrud må aldrig gentage sig

Amazon-nedbruddet er en påmindelse om, at skyen ikke er usårlig. Det er måske en god idé at være forberedt på, at skyen kan bryde sammen, og det derfor kan være nyttigt at have et alternativ i baghånden.

Der er ingen grund til, at skyen skal være synonym med Amazons datacentre. Der er flere andre udbydere, og selvom Amazon kan være svær at slå på prisen, så er pengene til et par ekstra virtuelle maskiner eller en kopi af data hos en anden udbyder måske givet godt ud.

I sidste ende afhænger det af et velkendt regnestykke for den infrastrukturansvarlige.

Ligesom redundans og oppetid koster administrationstid, medarbejderkompetencer og penge dit eget datacenter, så gælder det samme regnestykke, når man flytter driften i skyen.

Monokulturen gør i dette tilfælde, at når noget går galt, så går det galt for mange på én gang. Skal vi undgå det, så skal der enten bruges penge på at øge redundansen, eller på at mindske skaden. I begge tilfælde er det oplagt at bruge forskellige skyer som støtte for hinanden.

Dét er ingen triviel opgave i dag, for selvom meget er standardiseret, så er hybridløsninger mellem skyer et territorium, hvor udbyderne hellere vil sælge dig redundans inden for deres egen sky.

Skyen er fantastisk for dem, der tidligere fint kunne tåle, at systemerne brød sammen i en kortere periode. Men vi må også indse, at trods kompetencerne og stordriftsfordelene ved skyen, så skal der mere end et kreditkort og et par klik til at garantere de famøse fem nitallers oppetid.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Dave Pencroof

Alt drejer sig om pengene på bundlinien, og at skulle dublere sine data over på en anden tjeneste, vil som alt er sat op i dag alene ses som en unødvendig udgift/minimering af bundlinien, og hvis vores kunder bliver utilfredse over midlertidig manglende tilgængelighed, så kan vi med ro i sindet sige til dem at det var ikke os der var de skyldige, (til trods for at vi er dem der lægger alle æggene i EN kurv, men det siger vi intet om !), for det er trods alt kunden der lider ikke os, så længe kunden betaler, og at kunden ved mindst muligt om hvad der foregår bag tæppet ! Det er en aldeles rådden verden vi lever i, men flertallet vil ikke bekymre sig, så intet ændres !

  • 2
  • 3
#5 Tobias Tobiasen

Jeg har svært ved at følge sammenligningen mellem mainframe og AWS. Med en mainframe er man typisk låst meget til platformen og det er stort set umuligt at skifte fra den. Hvis man bare tænker sig minimalt om når man deployer på AWS så bygger man ikke AWS ind i kernen af det man deployer. De systemer jeg har været med til at bygge er alle baseret på docker og kan flyttes til andre skyer eller eget datacenter med en begrænset indsats.

  • 4
  • 1
#6 Jesper Frimann

Hvis man bare tænker sig minimalt om når man deployer på AWS så bygger man ikke AWS ind i kernen af det man deployer. De systemer jeg har været med til at bygge er alle baseret på docker og kan flyttes til andre skyer eller eget datacenter med en begrænset indsats.

Undskyld mig, men du snakker udelukkende om IaaS/laveste level af PaaS :)= Det er vel næppe dækkende for for begrebet 'Cloud'. Og hvis man endelig skal være fræk, så kan man jo sige at på samme IaaS/lowlevel Paas niveau, er der jo så absolut intet galt for, at du kunne deploye Docker containers på en 'mainframe' :)

// Jesper

  • 3
  • 1
#7 Bo Andersen

Det er desværre min erfaring, at IT området trækkes med fagligt inkompetente ledere, som godt nok kan alle de smarte ord, (lige for tiden er det cloud, skyen, digitalsering, gevinstrealisering, EU Persondataforordning), men som intet aner om konsekvenserne af deres valg, eller har nogen som helst idé om hvordan tingene skal realiseres.

Kunne man forestille sig eksempelvis skoleledere, økonomichefer, chefsygeplejersker, eller køkkenchefer uden en relevant uddannelse ? Næppe, men for IT området er den gængse opfattelse åbenbart, at området ikke behøver en leder med en IT faglig uddannelse, så derfor udfyldes stolen af jurister, økonomier, folkeskolelærere, kommunikationskonsulenter, historikere og andet godtfolk.

  • 0
  • 0
#8 Jesper Frimann

Kunne man forestille sig eksempelvis skoleledere, økonomichefer, chefsygeplejersker, eller køkkenchefer uden en relevant uddannelse ?

Nej, men hvis man ser på f.eks. hospitalerne i dag, så har de typisk i dag en fuld 'virksomheds ledelse'. Du har nogle meget aktive regions politikere der ser sig selv som en bestyrelse, så har du på hvert hospital en direktion bestående af en direktør og flere vicedirektører, og under den så en overordnet afdelings ledelse, som så igen har afdelings ledere, og souschefer.

Altså 4-5 ledelseslag, hvor den sundhedsfagligheden i toppen er .. ja.. nærmest ikke eksisterende, da en hospitals direktør, med få undtagelser, nærmest altid er en djøffer og på mange hospitaler er vicedirektører lige så.

Jeg tror lidt, at problemet ligger i den meget store forskel, der er mellem antallet af folk, der gerne vil være ledere og så gode ledere. En dårlig leder gør IMHO ofte langt langt mere skade end gavn. Hvorimod en rigtig god leder virkelig kan virke som en >1 multiplikator på sit 'team'. Så når man nu har valgt at adoptere den her angloamerikanske ledelseshierarki stil både i det offentlige og store dele af det private, så kombineret med at der er få rigtig gode ledere, så vil der komme en masse dårlig ledelse ind. Og mange af dem er meget ambitiøse. Hvilket også er grunden til at i mange store virksomheder, der ser du Arkitekt/CAB m.m. boards fyldt op med ledere der ikke fatter en dytmeter om, hvad det går ud på. Men det ser jo godt ud på et leder CV, at du har arkitekt board member eller CAB board member.

Så IMHO er det problem du beskriver mere generelt end bare at være begrænset til IT-branchen.

// Jesper

  • 1
  • 0
#9 Gert Madsen

da en hospitals direktør, med få undtagelser, nærmest altid er en djøffer

Så vidt jeg husker, skete det i begyndelsen af 90'erne, ud fra det mantra at en dygtig læge ikke nødvendigvis er en dygtig leder. Vi kan jo så fundere lidt på hvordan det er gået med sygehusvæsenet siden . . .

Jeg tror at der generelt mangler den erkendelse, at en dygtig DJØF'er, heller ikke nødvendigvis er en dygtig leder.

  • 2
  • 0
#10 Jesper Frimann

Vi kan jo så fundere lidt på hvordan det er gået med sygehusvæsenet siden . . .

Ja, det 'sjove' er, at jeg sagde op tilbage i Q4 sidste år, fra et af de store IT-selskaber, netop fordi jeg mente af fagligheden blev tromlet, og at man simpelt hen topstyrede med hovedet under armen, det kun ville gå mere og mere galt. Og det gjorde det så. Og min kone (mellemleder med faglig baggrund på et hospital), har lige gjort det samme, af nogenlunde samme grunde.

Jeg tror at der generelt mangler den erkendelse, at en dygtig DJØF'er, heller ikke nødvendigvis er en dygtig leder.

En Djøffer er jo typisk en administrator. En af de ting jeg gentagende gange har set i store virksomheder er, at man undervurderer kulturen og hvor langt tid det tager for en ny 'kultur' at sætte sig og blive gavnlig. Derfor er det her konstante org. ændringer simpelt hen en katastrofe. Nogle steder omorganiserer man organisationen konstant.

Jeg har prøvet at sidde i månedsvis sammen med kvalificerede kollegaer og lave oplæg til 'faglige virtuelle organisationer' som bunder i faglige frameworks og kundernes forventninger, bare for at se en ledelsesgruppe have fordelt 'posterne' og flækket noget sammen på en eftermiddag. Som man så var nødt til at lave om 2-3 gange samme år, for det første fordi det ikke virkede, men også fordi det fik folk til at flygte.

Så ja... :)

// Jesper

  • 1
  • 0
Log ind eller Opret konto for at kommentere