Inledning
De av er med bra minne undrar säkert vad jag är för en skojare som kan med att skriva en artikel om hur ni lyckas med er multicloudstrategi när jag för inte så länge sedan ingående förklarade varför ni skall undvika multicloud till varje pris.
Flera kommentarer till den artikeln påpekade att jag missat SaaS, och att SaaS tvingar företag att ha en multicloudstrategi, något som är helt korrekt i båda fallen. Min expertis rör först och främst IaaS och PaaS, SaaS är något jag inte jobbat med i större utsträckning, varför SaaS inte kom med i den artikeln.
I den här artikeln har jag för avsikt att ge övergripande riktlinjer när det gäller multicloud, och först och främst för SaaS, så att er organisation förstår dels när det är nödvändigt att använda flera moln, och dels vad ni skall tänka på när ni gör det.
Varför innebär SaaS-tjänster automatiskt multicloud?
Som jag beskrev i min förra artikel [1] finns det ett flertal tjänstemodeller i molnet, där de vanligaste är IaaS, PaaS, och SaaS. SaaS - Software as a Service - är den tjänstemodell som är absolut tydligast avgränsad. Det är finns bara så mycket ni kan göra i en SaaS-tjänst innan ni stöter på begränsningar, på både gott och ont.
Allt fler tjänster går dessutom endast att konsumera som en molntjänst vilket innebär att en organisation, nästan oberoende av storlek, oundvikligen konsumerar ett flertal olika molntjänster. Då dessa tjänster sällan kommer från samma leverantör resulterar detta i att multicloud är något ni måste förhålla er till.
Är det en nackdel med SaaS multicloud?
Det tråkiga svaret här är "Ja och nej." Så snart vi har fler än en leverantör att förhålla oss till blir det mer komplicerat, oavsett var vi sedan kör dessa tjänster, men på grund av hur väl definierade SaaS-tjänster oftast är (eller i alla fall skall vara) innebär för det mesta att gränsdragningen mellan de olika tjänsterna också är väl definierad.
Om vi jämför med exempelvis ett datacenter on-premise, eller IaaS i molnet, är det så många olika variabler och komponenter som konstant interagerar med varandra att det inte är självklart vem som ansvarar för vad, oavsett om det är under normal drift eller när problem uppstår.
Detta ansvar är mycket tydligare definierat i leveransen av en SaaS-tjänst, och om leverantören är det minsta professionella har de tydliga processer, policys och riktlinjer för hur de och ni förväntas agera i exempelvis det fall att ett problem med tjänsten uppstår.
Även om SaaS-tjänster är mycket mer strikt definierade är SaaS rent generellt den modell i molnet ni skall sträva efter att konsumera, förutsatt att den uppfyller era krav, då den i slutändan erbjuder flest fördelar.
Vad skall ni tänka på när ni kör fler än ett moln?
Oavsett varför ni använder fler än ett moln är det kritiskt att ni har samma krav på säkerhet, identitetshantering, incidenthantering, styrning, rutiner, ansvarstagande, med mera, oavsett vilken plattform ni kör era applikationer på eller lagrar er information i.
När det gäller IaaS och PaaS är det oftast enklare att säkerställa att dessa tjänster lever upp till era krav då relativt få leverantörer tillhandahåller den här typen av tjänster, även om det finns flera lokala spelare som erbjuder någon variant av IaaS. Oavsett om det är en lokal spelare eller en stor molnjätte skall leverantören emellertid leva upp till de krav ni har definierat.
Det finns jämförelsevis många fler leverantörer av SaaS-tjänster, och varenda leverantör och tjänst ni använder måste genomlysas för att säkerställa att de lever upp till era krav.
Tydlig och uppdaterad dokumentation av era SaaS-tjänster är också ett måste. Vem är tekniskt ansvarig i er organisation för tjänsten? Vem, om någon, är ansvarig från verksamheten? Hur är informationen som lagras i tjänsten klassificerad? Vilka SLA har ni med leverantören, och så vidare. Information som är ett måste så snart något händer med tjänsten eller när den behöver uppdateras.
Utöver detta måste ni också dokumentera vilka integrationer och anpassningar ni gjort. Förmodligen har ni någon slags koppling mellan en SaaS-tjänst och en tjänst eller applikation i ert eget datacenter. Det är också troligt att ni har kopplingar mellan olika SaaS-tjänster. Att förstå dessa samband är ovärderligt vid felsökning eller när en tjänst skall ut- eller avvecklas.
Livscykelhantering av den information som lagras i tjänsten samt de identiteter som är knutna till tjänsten är även detta något som ni måste tänka på. Med väl definierade policys och rätt verktyg är detta dock inte så komplicerat som det var en gång i tiden.
En för- och nackdel med en SaaS-tjänst är att den är i konstant förändring. Ibland sker förändringarna ofta, ibland mer sällan, men oavsett måste någon hos er äga ansvaret för att löpande utvärdera om tjänsten fortfarande är rätt för er, eller om ni skall byta. Det kan exempelvis vara att en teknisk förmåga försvinner eller att leverantören ändrar en policy som gör det omöjligt för er att använda tjänsten.
En gemensam strategi
Som jag antyder till i stycket ovan är det viktigt att ni har gemensamma strategier och policys, och allra helst gemensamma verktyg, för varje tjänst eller plattform ni använder. SaaS-tjänster är på grund av sin natur svårare att samla i ett och samma fack men en tumregel är att ha så få undantag från en övergripande policy som möjligt.
I valet av SaaS-tjänst skall denna aspekt tas i beaktning. Hur väl en tjänst passar med er strategi, era policys, er driftsorganisation, era finansiella rutiner, er informationsklassificering samt er identitetshantering kan innebära skillnaden mellan en tjänst som ger er en fördel och en tjänst som gör det svårare för era anställda att göra sitt jobb.
Trots att en SaaS-tjänst är mycket mer väl definierad och sålunda rigid i sin utformning krävs det att ni har någon som förstår hur såväl verksamhet som IT påverkas av valet av tjänsten. En duktig lösningsarkitekt som inte bara möjliggör utan också förenklar den analysen är en viktig roll inför valet och införandet av en ny tjänst.
Avslutningsvis
Det är i praktiken omöjligt att undvika multicloud när ni kör SaaS-tjänster, och det går att bygga ett väl fungerande ekosystem av SaaS-tjänster så länge ni förstår vilka åtaganden som krävs från er sida för att framgångsrikt välja och implementera dem.
Förenkla så mycket som möjligt med hjälp av gemensamma policys, rutiner och verktyg för era SaaS-tjänster och tumma inte på säkerhet, informationsklassificering, och identitetshantering bara för att kunna implementera en specifik tjänst.
Involvera såväl IT som verksamhet i införandet av alla nya tjänster och dokumentera redan från det skede ni bestämmer er för att skaffa en ny tjänst så att ni vet varför en specifik tjänst valdes över en annan. Fortsätt sedan att löpande dokumentera så att ni förstår hur tjänsten fungerar.
Tveka inte att kontakta mig, antingen via e-mail, telefon eller formuläret här på hemsidan, om ni är intresserade av att diskutera ämnet vidare med mig.
Tack för er tid!
Commentaires