Moln rationalisering

Moln rationalisering är processen att utvärdera tillgångar för att fastställa det bästa sättet att migrera eller modernisera varje tillgång i molnet. Mer information om rationaliseringsprocessen finns i Vad är en digital egendom?.

Rationaliseringskontext

De fem R:na för rationalisering som anges i den här artikeln är ett bra sätt att märka ett potentiellt framtida tillstånd för alla arbetsbelastningar som betraktas som en molnkandidat. Den här etiketteringsprocessen bör placeras i rätt kontext innan du försöker rationalisera en miljö. Granska följande myter för att ge den kontexten:

Myt: Det är lätt att fatta rationaliseringsbeslut tidigt i processen

God rationalisering kräver djup kunskap om arbetsbelastningen och tillhörande tillgångar (program, infrastruktur och data). Viktigast av allt är att bra rationaliseringsbeslut tar tid. Vi rekommenderar att du använder en inkrementell rationaliseringsprocess.

Myt: Molnimplementering måste vänta på att alla arbetsbelastningar rationaliseras

Rationalisering av en hel IT-portfölj eller till och med ett enda datacenter kan fördröja genomförandet av affärsvärdet med månader eller till och med år. Undvik fullständig rationalisering när det är möjligt. Använd i stället Power of 10-metoden för att släppa planeringen för att fatta kloka beslut om de kommande 10 arbetsbelastningarna som är planerade för molnimplementering.

Myt: Affärsmotivering måste vänta på att alla arbetsbelastningar rationaliseras

Om du vill utveckla en affärsmotivering för en molnimplementering bör du göra några grundläggande antaganden på portföljnivå. När motiven är inriktade på innovation, anta omarkitektur. Om de är justerade efter migrering antar du att de är värdar. Dessa antaganden kan påskynda processen för affärsmotivering. Antaganden utmanas sedan och budgetar förfinas under utvärderingsfasen av varje arbetsbelastnings implementeringscykel.

Granska nu följande fem R:er för rationalisering för att bekanta dig med den långsiktiga processen. När du utvecklar din molnimplementeringsplan väljer du det alternativ som bäst överensstämmer med dina motiveringar, affärsresultat och aktuella tillståndsmiljöer. Målet med rationalisering av digital egendom är att ange en baslinje, inte att rationalisera varje arbetsbelastning.

Rationalisering – fem punkter

De fem R:na för rationalisering som anges här beskriver de vanligaste alternativen för rationalisering.

Ange ny värd

Även känd som en lift and shift-migrering flyttar en värdsatsning en aktuell tillståndstillgång till den valda molnleverantören, med minimal förändring av den övergripande arkitekturen.

Vanliga drivrutiner kan vara:

  • Minska kapitalkostnaden.
  • Frigör datacenterutrymme.
  • Uppnå snabb avkastning på investeringar i molnet.

Kvantitativa analysfaktorer:

  • VM-storlek, inklusive CPU, minne och lagring
  • Beroenden som nätverkstrafik
  • Tillgångskompatibilitet

Kvalitativa analysfaktorer:

  • Tolerans för ändring
  • Affärsprioriteringar
  • Kritiska affärshändelser
  • Processberoenden

Omstrukturera

PaaS-alternativ (Plattform som en tjänst) kan minska de driftskostnader som är associerade med många program. Det är en bra idé att omstrukturera ett program något så att det passar en PaaS-baserad modell.

Refaktor syftar också på programutvecklingsprocessen för refaktorisering av kod för att göra det möjligt för ett program att leverera nya affärsmöjligheter.

Vanliga drivrutiner kan vara:

  • Snabbare och kortare uppdateringar.
  • Kodportabilitet.
  • Större molneffektivitet för att hjälpa till med resurser, hastighet, kostnader och hanterade åtgärder.

Kvantitativa analysfaktorer:

  • Programtillgångens storlek, till exempel CPU, minne och lagring
  • Beroenden som nätverkstrafik
  • Användartrafik som sidvisningar, tid på sidan och inläsningstider
  • Utvecklingsplattformar som språk, dataplattformar och mellannivåtjänster
  • Databas som innehåller CPU, minne, lagring och version

Kvalitativa analysfaktorer:

  • Fortsatta affärsinvesteringar
  • Burst-alternativ eller tidslinjer
  • Beroenden för affärsprocesser

Arkitekturomarbetning

Vissa åldrande program är inte kompatibla med molnleverantörer. Den här inkompatibiliteten beror på de arkitektoniska beslut som fattades när programmet skapades. I dessa fall kan programmet behöva återskapas före omvandlingen.

I andra fall kan program som är molnkompatibla, men inte molnbaserade, skapa kostnadseffektivitet och driftseffektivitet genom att bygga om lösningen till ett molnbaserat program.

Vanliga drivrutiner kan vara:

  • Programskala och flexibilitet.
  • Enklare implementering av nya molnfunktioner.
  • Blandning av teknikstackar.

Kvantitativa analysfaktorer:

  • Programtillgångens storlek, till exempel CPU, minne och lagring
  • Beroenden som nätverkstrafik
  • Användartrafik som sidvisningar, tid på sidan och inläsningstider
  • Utvecklingsplattformar som språk, dataplattformar och mellannivåtjänster
  • Databas som innehåller CPU, minne, lagring och version

Kvalitativa analysfaktorer:

  • Växande affärsinvesteringar
  • Driftskostnader
  • Potentiella feedbackslingor och DevOps-investeringar

Återskapa

I vissa scenarier kan deltat som måste övervinnas för att föra ett program framåt vara för stort för att motivera ytterligare investeringar. Det här problemet gäller särskilt för program som tidigare uppfyllde behoven i ett företag men som nu inte stöds med de aktuella affärsprocesserna. Lös problemet genom att skapa en ny kodbas som överensstämmer med en molnbaserad metod.

Vanliga drivrutiner kan vara:

  • Snabbare innovation.
  • Skapa program snabbare.
  • Minska driftskostnaderna.

Kvantitativa analysfaktorer:

  • Programtillgångens storlek, till exempel CPU, minne och lagring
  • Beroenden som nätverkstrafik
  • Användartrafik som sidvisningar, tid på sidan och inläsningstider
  • Utvecklingsplattformar som språk, dataplattformar och mellannivåtjänster
  • Databas som innehåller CPU, minne, lagring och version

Kvalitativa analysfaktorer:

  • Minskande nöjdhet för slutanvändare
  • Affärsprocesser som begränsas av funktioner
  • Potentiella kostnads-, erfarenhets- eller intäktsvinster

Ersätt

Lösningar implementeras vanligtvis med hjälp av den bästa tekniken och metoden som är tillgänglig vid den tidpunkten. Ibland kan saaS-program (programvara som en tjänst) tillhandahålla alla nödvändiga funktioner för det värdbaserade programmet. I dessa scenarier kan en arbetsbelastning schemaläggas för framtida ersättning, vilket effektivt tar bort den från omvandlingsarbetet.

Vanliga drivrutiner kan vara:

  • Standardisera kring bästa praxis för branschen.
  • Påskynda implementeringen av affärsprocessdrivna metoder.
  • Omallokera utvecklingsinvesteringar i program som skapar konkurrensdi differentiering eller fördelar.

Kvantitativa analysfaktorer:

  • Allmänna minskningar av driftskostnader
  • VM-storlek, inklusive CPU, minne och lagring
  • Beroenden som nätverkstrafik
  • Tillgångar som ska dras tillbaka
  • Databas som innehåller CPU, minne, lagring och version

Kvalitativa analysfaktorer:

  • Kostnadsnyttoanalys av den aktuella arkitekturen jämfört med en SaaS-lösning
  • Affärsprocesskartor
  • Datascheman
  • Anpassade eller automatiserade processer

Nästa steg

Tillsammans kan du använda dessa fem R:er för rationalisering på en digital egendom för att hjälpa dig att fatta rationaliseringsbeslut om det framtida tillståndet för varje program.