Ingen verksamhet som vill vara relevant kan ignorera de fördelar molnet ger. Med detta sagt finns det dock ett antal saker att ha i åtanke för att en flytt till molnet skall vara så lyckad som möjligt. I den här artikeln beskriver jag fem av mina måsten för en lyckad flytt av en applikation till molnet.
Nummer 1 - Ifrågasätt flytten
Det absolut viktigaste ni kan göra är att ställa er frågan "Varför flyttar vi den här applikationen till molnet?"
Acceptabla svar på den här frågan är:
Det ökar organisationens effektivitet
Det sänker våra operationella kostnader
Det ger oss ett försprång gentemot våra konkurrenter
Det ger oss möjligheten att komma i kapp våra konkurrenter
Det höjer kvaliteten på vår leverans av IT
Det är ett steg på vägen till en modernisering av applikationen
Felaktiga svar på den här frågan är:
Gartner säger att alla gör det
Det är billigare i molnet
Molnleverantören betalar för flytten
Vår IT-partner tycker att det är en bra idé
Alla vet att det lokala datacentret är utdöende
Om ni inte kan rättfärdiga flytten av applikationen med faktiska, greppbara fördelar - i första hand för verksamheten och i andra hand för IT-avdelningen - skall ni inte flytta någonting någonstans.
Kanske att det i er cloud-strategi står "Cloud only!" med stora bokstäver. Mitt svar blir då att ni har en felaktig cloud-strategi. En strategi, cloud eller inte, existerar inte i ett vacuum utan måste förankras i verksamhetens övergripande strategi för att säkerställa att den på bästa sätt främjar verksamheten. Men det är en annan artikel.
Ingen förväntar sig att ni skall kunna berätta på procenten när hur många färre supportsamtal ni slipper, eller exakt hur många kronor och ören verksamheten kommer att öka i omsättning för att ni flyttar en stackars applikation till molnet, men om ni inte ens vänder på den här stenen och faktiskt frågar er själva vilken effekt en flytt ger är ni ute på tunn is.
Nummer 2 - Angrip flytten förutsättningslöst
Väldigt ofta har arkitekten, applikationsägaren eller IT-avdelningen bestämt sig för såväl hur applikationen skall flyttas som hur den skall fungera när den väl är på plats i molnet. Det finns lika många favoritramverk som det finns arkitekter (jag talar i egenskap av arkitekt).
AWS Lambda är jäkligt fräckt så det är väl klart att allt vi flyttar till molnet skall vara serverless, oavsett om det är en 25 år gammal monolit till applikation som ingen nu levande person begriper sig på. Red Hat var här och pratade om OpenShift och det ser ju jäkligt snyggt ut så det kör vi, no questions asked! Azure har enligt Microsoft superschysst stöd för Kubernetes så precis varenda applikation vi har skall köras som en container.
Lägg alla dessa förutfattade meningar åt sidan och låt applikationen och de faktiska förutsättningarna diktera val av metoder, tekniker och ramverk.
Här kommer en fungerande cloud-strategi in i bilden och skall stötta och ge råd i hur en flytt skall ske och hur applikationen skall hanteras när den väl är på plats i molnet. Er organisation skall redan innan en enda applikation hamnar i molnet ha bestämt vilken eller vilka tekniker och plattformar som är godkända och när de skall appliceras.
Hur komplex och kritisk applikationen är dikterar i allra högsta grad vilka av ovan metoder och tekniker som sedan kan appliceras. Det finns en förkärlek till att försöka använda en och samma teknik, exempelvis containers, för att lösa alla problem men den bittra sanningen är att "One size fits nobody."
Så länge er organisation kan hantera flera olika tekniker är det inget problem att använda dem. Problemen uppstår när nya tekniker appliceras utan eftertanke, ofta på grund av att det är vad arkitekten, applikationsägaren eller IT-avdelningen av olika skäl föredrar.
Finns det ingen teknik, plattform eller ramverk som fungerar skall detta adresseras i någon slags arkitektråd och sedan införlivas i cloud-strategin innan flytten sker så att den nya tekniken rimmar med resten av strategin.
Nummer 3 - Dokumentera före, under och efter flytten
Ju mer ni vet om applikationen som skall flyttas desto smärtfriare blir det att flytta den. Självklarheter kan tyckas men alldeles för ofta görs det antaganden om hur saker och ting hänger ihop, antaganden som visar sig vara felaktiga först när flytten påbörjats.
En i mitt tycke väldigt viktig aspekt som många organisationer glömmer bort vid den här typen av aktiviteter är chansen att lära sig. Oavsett om flytten går felfritt eller åt skogen innebär det en möjlighet att lära sig. För att dessa lärdomar skall komma till nytta är det ett nödvändigt ont att dokumentera hur flytten genomförs samt vad som händer under det att flytten genomförs.
Sist men absolut inte minst, dokumentera applikationen när den väl är på plats i molnet. Det finns ingen möjlighet att komma ihåg alla de planerade och oplanerade beslut som fattades, hur applikationen egentligen konfigurerades, vilka beroenden den har, vem som är ansvarig för vad samt hur den skall hanteras om den stannar.
Hur detaljerat en applikation dokumenteras står naturligtvis i relation till hur kritisk den är men även de allra enklaste applikationerna förtjänar åtminstone ett minimum av dokumentation.
Nummer 4 - Ha en plan för applikationen
Planen behöver inte vara storslagen, den kan till och med vara så enkel som "Låt ligga i molnet tills vi avvecklar den", men då har ni i alla fall funderat på vad som skall hända med applikationen efter att den flyttats.
Beroende på vem man frågar finns det ett antal olika sätt att hantera en applikationsflytt till molnet, ofta benämnt något i stil med "The 5 R's of transformation to the cloud" eller "6 R's of cloud migration." Oavsett handlar detta om att fundera på i vilken utsträckning ni vill förändra er applikation - om alls - under eller efter flytten till molnet.
Det är en helt giltig strategi att börja med "re-host", d.v.s. att ni bara flyttar en VM som den är till molnet, så länge ni vet med er vilka konsekvenser detta får. Alternativt passar ni i samband med flytten på att bygga om den så att den går att köra direkt på PaaS-tjänster.
Om ni väljer att flytta allting som det är måste ni ha en genomtänkt, realistisk och budgeterad plan för hur ni löpande skall modernisera er applikationsflora. Om ni inte har en plan för hur ni på bästa sätt skall dra nytta av molnets fördelar kommer det bli en dyrköpt lärdom när applikationerna väl ligger där.
Att flytta en applikation till molnet får inte ske "huller om buller" om ni vill få ut den effekt av flytten ni förväntar er.
Nummer 5 - Våga tänka iterativt
Om ni har en mer detaljerad plan för era applikationer är det viktigt att inse att det är i princip omöjligt att realisera den i ett enda slag. Dels med tanke på hur snabbt molntjänster utvecklas, men också med tanke på hur komplext det är att modernisera en applikation.
För många år sedan höll jag en föreläsning med titeln "Resan till molnet börjar i källaren." Budskapet var att hur gärna en organisation vill flytta till molnet måste man börja i det lokala datacentret, bland annat för att säkerställa att det gick att flytta till molnet till att börja med.
Nästa steg var att börja flytta faktiska arbetslaster, även om det i sin tur bara var nästa steg på resan, för att sedan fortsätta arbeta iterativt mot slutmålet. Att försöka flytta från en traditionell VM till en modern, cloud-native applikation på ett bräde är en utmaning få klarar av.
Med all sannolikhet innebär den här typen av iterativt arbete att ni måste skapa system, lösningar och till och med en organisation som kan hantera alla de "mellanlägen" er applikation befinner sig i.
Låt oss säga att ni börjar med att flytta en applikation som den är till molnet, d.v.s. att ni fortsätter köra den som en VM. Under tiden den körs som VM måste den ha backup, antivirus, uppdatering av OS, säkerhet och rättighetskontroll - bara för att nämna några stödfunktioner.
När ni väl itererat färdigt flytten av er applikation är det mycket möjligt att en eller flera av ovan nämnda funktioner inte längre är användbara eller behöver byggas om även de.
Detta är ett nödvändigt ont. Rom byggdes inte på en dag, och inte heller en modern applikationsflora.
Är ni intresserade av diskutera någon av punkterna ovan i mer detalj är ni mer än välkomna att kontakta mig, antingen via e-mail, telefon eller formuläret här på hemsidan.
Tack för er tid!