Att transformera eller icke transformera?

Det är frågan… som många, som har packat flyttbilen till molnet full, behöver ställa sig. Ska jag flytta alla mina applikationer med så få förändringar som möjligt eller ska jag transformera dem att passa molnets leveransförmågor? Har jag bråttom och behöver flytta allt snarast eller kan det ta tid?

I det här avsnittet tänkte jag diskutera de migreringsstrategier till molnet som är vanligt förekommande.

Egentligen finns det fler som diskuteras men eftersom jag tycker om att förenkla så tycker jag om dessa tre nivåer i ökande nivå av flytthastighet:

Organiskt

Det här är en ganska vanligt förekommande “strategi”, jag skulle vilja kalla den icke-strategin. Tjänster som råkar passa för det publika molnet flyttas eller upphandlas dit när det passar förvaltaren av tjänsten och för tillfället verkar mer ekonomiskt. Sammanfattat, det händer när det händer.

Transformera

Det här är strategin att allt som flyttas till det publika molnet ska transformeras till att kunna köras på PaaS-tjänster. Det innebär ofta att applikationer måste skrivas om, helt, delvis eller bara uppdateras. Detta kräver ju dock att det finns ett ansvarigt utvecklingsteam för applikationen som har förmågan till detta och att organisationen prioriterar den tiden.

Denna kategori delas ibland upp i två, en för de applikationer som med minimala förändringar kan lyftas till PaaS och en för de som kräver större transformation (Replatform och Refactor). I slutändan ser jag det som samma, antingen ska det transformeras eller inte.

Även med fullt fokus så är det en långsam metod, att göra om applikationer är svårt att tidsbedöma och oväntade hinder uppstår ofta.

Lift and shift

IT-infrastruktur flyttas med så lite förändring som möjligt till en publik molntjänst. I de flesta fall innebär det att du flyttar virtuella maskiner från ett datacenter till ett annat. Flytten av maskinerna i sig är förvisso relativt enkel. Men att bygga upp infrastrukturen runt omkring; nätverk, governance, brandväggslager, lastbalansering, identiteter. Sedan är dessutom infrastrukturen för själva dataflytten och förmågan att flytta last fram och tillbaka under testfasen ganska komplex.

Trots komplexiteter, så är det en ganska snabb metod, och molnleverantörer är har ofta sponsringsprogram som betalar delar av kostnaderna för flytten.

Andra kategorier är Repurchase och Retain, som jag också tycker är icke migreringsstrategier eftersom att behålla last inte är en migrering, och att köpa SaaS inte heller är någon migrering av applikationen, det är en dataflytt. Det som kvarstår då är egentligen transformera eller inte.

Egentligen tycker jag inte att någon av dessa är en molnstrategi i över huvud taget. De är metoder du kan flytta dina applikationer med när du väl exekverar på din molnstrategi. Enligt mig handlar moln om de förmågor som beskrivs i NIST definitionen, det är förmågor du kan bygga på lång eller kort sikt, i ditt eget datacenter eller upphandla hos någon annan.

En molnstrategi ska då innehålla varför de förmågorna är viktiga för din organisation, hur du ska uppnå dem, men också hur du behöver vara eller den kultur som krävs.

Exempel:
För att kunna nyttja att bara behöva betala för det du använder, behöver du ha en förmåga att hela tiden värdera dina kostnader mot ett affärsvärde(beskrivet i artikeln om FinOps). Du behöver också kunna agera på dina kostnadsförändringar och snabbt uppdatera och skala om din infrastruktur med hjälp av molnets självserviceförmåga. Då behöver du ha mer agila förmågor, något jag beskriver i artikeln om DevOps och agila arbetssätt.

Men när du har ett agilt förhållningssätt och en distribuerad beslutsprocess då behöver du kanske också en distribuerad säkerhetsförmåga som jag beskriver i artikeln om molnsäkerhet.

Jag skulle vilja påstå att när du har ovan förmågor så blir flytten till molnet också en ickefråga på bolagsnivå, dina team kommer kunna självständigt besluta vilka applikationer som bäst stannar i ditt eget datacenter eller hos din hostingleverantör, vilka som ska flytta till ett publikt moln och om applikationen behöver transformeras om eller kan flyttas i befintligt skick. Undantaget är större lift and shift migreringar, som i min mening egentligen inte har med molnstrategin att göra heller, eftersom dessa inte alls utnyttjar molnets förmågor. Här pratar vi egentligen om att byta datacenter och sedan bygga molnförmåga efter din strategi.

Det som dock behöver ingå, oavsett metod och strategi, är governance. Det behöver finnas en struktur uppsatt hos en eller flera valda molnleverantörer och ett team som ansvarar för detta. Precis som det finns ett team som sköter en fysisk datorhall måste motsvarande jobb skötas på den virtuella nivån. Din molnleverantör tilldelar dig en eller flera virtuella datorhallar som du sedan har ansvaret för att hantera. Vilka får komma in, vilka får sätta upp resurser, hur kommunicerar hallen med omvärlden. Ta hjälp här, det finns fristående leverantörer på marknaden som är mycket bra på detta moment och kan antingen hjälpa dig eller göra det åt dig.

Nu kan det ju låta som att jag säger att ingen ska flytta till molnet innan organisationen är fullt transformerad, men det är inte andemeningen i det jag säger. Jag försöker bara påpeka att en molntransformation handlar om mer än vilken metod du ska använda för att få applikationer att köras i molnet. Och om det är det du fokuserar din molnstrategi på, riskerar du att få ett sämre resultat och mindre värde än du tänkt dig.