De løsninger vores kunder har afhænger ofte af hinanden indbyrdes, og en SaaS løsning vil i flere tilfælde give mindre værdi, fordi dens muligheder for integration med de øvrige applikationer ikke er lige så god, som hvis løsningen stod On-Premise.
Bortset fra ønsket om lavere driftsomkostninger vil mange virksomheder kun behøve de øvrige “cloud-fordele” i visse systemer, og langt fra alle. Dertil kommer at de forskellige udbyderes cloud løsninger er forskellige, både hvad angår økonomisk model og teknologi, det betyder at noget it-understøttelse bedst realiseres hos en leverandør, andet hos en anden. Men mest vigtigt lige nu er nok, at virksomheder med en eksisterende IT-portefølje, hverken kan, eller ønsker, at placere alle deres løsninger i skyen i et hug. Og for mange typer virksomhed er skyen heller ikke moden til et sådan initiativ endnu.
Det leder frem til spørgsmålet, hvilke it-funktioner egner sig til at komme i skyen, og hvordan man laver en arkitektur der tillader, at it-funktioner spredes mellem forskellige cloud-leverandører og traditionelle driftsleverandører.
Vi kan starte med at se på, hvordan vi har opdelt vores systemlandskab sikkerhedsmæssigt i dag.
De fleste vil have en DMZ, et sikkerhedsmæssigt afgrænset område, hvor man har placeret web servere, samt filservere eller gateways til udveksling af filer med andre virksomheder. Disse løsninger egner sig ofte godt til at blive placeret i skyen af flere årsager: Fælles for disse løsninger er, at de er ansvarlige for kommunikation med omverdenen, og i mange tilfælde betyder det belastningsmønstrer, der varierer over døgnet eller længere perioder, eller måske varierer i forhold til andre begivenheder. Her kan man udnytte skyens muligheder for at skalere. I nogle tilfælde kan geografisk redundans også spille ind, dvs. både fysisk nærhed til andre virksomheder og robusthed overfor nedbrud.
Ser vi på gateways i vores DMZ, har vi ofte flere åbninger i den yderste firewall, der tillader andre virksomheder at tilgå vores gateway. Det giver kompleksitet og muligheder for fejl og åbner måske for sikkerhedshuller, der tillader tilgang til andre systemer i vores DMZ end vores gateway. Placerer man derimod sin gateway i skyen, skal man blot have een sikker kanal til til sin gateway, og den gateway er nu bedre isoleret fra de øvrige systemer. Ofte reduceres administrationsbyrden af firewall og infrastruktur generelt på denne måde.
Endelig er systemerne i DMZ allerede sikkerhedsmæssigt isoleret fra vores øvrige systemer, og der er ofte lavet sikkerhedsanalyser af indholdet på disse servere, da de allerede står i DMZ’en. Af samme årsag har de veldefinerede, ofte standardiserede, grænseflader mod de øvrige systemer.
Har vi systemer i vores DMZ, der udveksler meget data med vores interne systemer, og hvor svartider er kritiske, skal vi undersøge om den ekstra forsinkelse, der er ved kommunikation til skyen har betydning.
Går vi videre og overvejer, om nogle af de systemer vi bruger internt med fordel egner sig til skyen, kan vi starte med at se på vores arkitektur generelt. Har vi en arkitektur hvor funktionsområder er afgrænset, og hvor grænseflader mellem dem er veldefineret, står vi stærkt. Vi ønsker de samme kvaliteter, som der normalt ligger til grund for en sund fleksibel arkitektur, hvor de enkelte funktionsområder kan ændres og udskiftes uden sideeffekter. Eksempelvis en fornuftigt implementeret og velstruktureret serviceorienteret arkitektur.
Så når vi ser på om et funktionsområde eller enkeltsystemer med fordel kan lægges i skyen, leder vi efter nogle karakteristika.
For det første skal de kunne få fordel at skyens overordnede kvaliteter: Skalerbarhed, robusthed, lavere omkostninger. Samtidig skal de sikkerheds- og performancemæssige konsekvenser overvejes. Oplagte kandidater er de systemer, der bruges periodevis, f.eks. systemer der har stor belastning ved måneds- eller årsafslutning.
På den arkitekturmæssige side er kandidaterne de systemer, der har få veldefinerede grænseflader, hvor der ikke udveksles for store datamænger med store krav til svartider.
De veldefinerede grænseflader gør det også lettere for os at overveje de sikkerhedsmæssige aspekter, da de fortæller, hvilke data løsningen bygger på.
De kundetilpassede løsninger (IaaS og til dels PaaS) kan let integreres med On-Premise systemer, men for løsninger der mere er hyldevare (SaaS og til dels PaaS), kan grænseflader gå hen og blive et problem. Med sidstnævnte kan man måske udemærket få den primære funktionalitet, man ønsker i skyen, men måske på bekostning af integration med de øvrige systemer. Hvis dette f.eks. leder til redundante data On-Premise og i skyen, måske endda dataredundans der ikke er synkroniseret, kan det let ødelægge en business case for at have funktionalitet i skyen.
Hvis man skal opsummere de tre vigtigste egenskaber ved de komponenter, der er egnet til at lægge i skyen må det være:
• Veldefineret afgrænset funktionalitet i arkitekturmæssig forstand
• Få og veldefinerede grænseflader
• Ikke for høje krav til datamængder og samtidig krav til lave svartider
Efterhånden som skyen modnes vil vi se, at både cloud leverandører og applikationsleverandører vil komme med produkter, der visker grænsen mellem On-Premise og cloud ud. Det ser vi frem til, og på sigt vil det betyde, at de ovenstående karakteristika for en applikation, der egner sig til skyen bliver mindre vigtige.
