Rationalisering van de cloud

Cloudrationalisatie is het proces van het evalueren van assets om de beste manier te bepalen om elke asset in de cloud te migreren of te moderniseren. Zie Wat is een digitaal onroerend goed voor meer informatie over het rationalisatieproces.

Rationaliseringscontext

De vijf R's van rationalisatie die in dit artikel worden vermeld, zijn een uitstekende manier om een mogelijke toekomstige status te labelen voor elke workload die wordt beschouwd als een cloudkandidaat. Dit labelproces moet in de juiste context worden geplaatst voordat u een omgeving rationaliseert. Bekijk de volgende mythen om die context te bieden:

Mythe: Het is gemakkelijk om al vroeg in het proces rationalisatiebeslissingen te nemen

Goede rationalisering vereist een grondige kennis van de workload en de bijbehorende assets (toepassingen, infrastructuur en gegevens). Het belangrijkste is dat goede rationaliseringsbeslissingen tijd in beslag nemen. We raden u aan een incrementeel rationalisatieproces te gebruiken.

Mythe: Cloudimplementatie moet wachten tot alle workloads worden gerationaliseerd

Het rationaliseren van een hele IT-portfolio of zelfs één datacenter kan de realisatie van bedrijfswaarde met maanden of zelfs jaren vertragen. Vermijd indien mogelijk volledige rationalisatie. Gebruik in plaats daarvan de Power of 10-benadering om planning vrij te geven om verstandige beslissingen te nemen over de volgende 10 workloads die zijn bedoeld voor cloudimplementatie.

Mythe: Zakelijke reden moet wachten tot alle workloads worden gerationaliseerd

Als u een zakelijke reden voor een cloudacceptatie wilt ontwikkelen, moet u enkele basisveronderstellingen maken op portfolioniveau. Wanneer motivaties zijn afgestemd op innovatie, gaat u ervan uit dat u de architectuur opnieuw gaat ontwerpen. Als ze zijn afgestemd op migratie, gaat u ervan uit dat deze opnieuw worden gehost. Deze veronderstellingen kunnen het bedrijfsproces versnellen. Veronderstellingen worden vervolgens uitgedaagd en budgetten verfijnd tijdens de evaluatiefase van de acceptatiecyclus van elke workload.

Bekijk nu de volgende vijf Rs van rationalisatie om vertrouwd te raken met het langetermijnproces. Kies tijdens het ontwikkelen van uw cloudacceptatieplan de optie die het beste aansluit bij uw motivaties, bedrijfsresultaten en de huidige statusomgeving. Het doel van rationalisatie van digitale activa is het instellen van een basislijn, niet om elke workload te rationaliseren.

De vijf R's van rationalisatie

De vijf R's van rationalisatie die hier worden vermeld, beschrijven de meest voorkomende opties voor rationalisatie.

Opnieuw hosten

Ook wel een lift-and-shift-migratie genoemd, verplaatst een herhosting een huidige statusasset naar de gekozen cloudprovider, met minimale wijzigingen in de algehele architectuur.

Veelvoorkomende stuurprogramma's kunnen zijn:

  • Kapitaalkosten verminderen.
  • Ruimte vrijmaken voor datacentrums.
  • Snel rendement op investeringen in de cloud bereiken.

Kwantitatieve analysefactoren:

  • VM-grootte, inclusief CPU, geheugen en opslag
  • Afhankelijkheden zoals netwerkverkeer
  • Assetcompatibiliteit

Kwalitatieve analysefactoren:

  • Tolerantie voor wijziging
  • Zakelijke prioriteiten
  • Kritieke bedrijfsevenementen
  • Procesafhankelijkheden

Herstructureren

PaaS-opties (Platform as a Service) kunnen de operationele kosten verlagen die aan veel toepassingen zijn gekoppeld. Het is een goed idee om een toepassing enigszins te herstructureren zodat deze past bij een PaaS-model.

Herstructureren verwijst ook naar het ontwikkelingsproces van de toepassing voor het herstructureren van code om een toepassing in staat te stellen nieuwe bedrijfskansen te leveren.

Veelvoorkomende stuurprogramma's kunnen zijn:

  • Snellere en kortere updates.
  • Draagbaarheid van code.
  • Meer cloudefficiëntie voor hulp bij resources, snelheid, kosten en beheerde bewerkingen.

Kwantitatieve analysefactoren:

  • Grootte van toepassingsassets, zoals CPU, geheugen en opslag
  • Afhankelijkheden zoals netwerkverkeer
  • Gebruikersverkeer, zoals paginaweergaven, tijd op pagina en laadtijden
  • Ontwikkelplatforms, zoals talen, gegevensplatforms en services in de middelste laag
  • Database met CPU, geheugen, opslag en versie

Kwalitatieve analysefactoren:

  • Voortgezette bedrijfsinvesteringen
  • Bursting-opties of tijdlijnen
  • Afhankelijkheden van bedrijfsproces

Opnieuw ontwerpen

Sommige verouderde toepassingen zijn niet compatibel met cloudproviders. Deze incompatibiliteit is het gevolg van de architectuurbeslissingen die zijn genomen toen de toepassing werd gebouwd. In deze gevallen moet de toepassing mogelijk opnieuw worden gearchitecteerd vóór de transformatie.

In andere gevallen kunnen toepassingen die compatibel zijn met de cloud, maar niet cloudeigen, kostenefficiëntie en operationele efficiëntie creëren door de oplossing opnieuw te ontwerpen in een cloudeigen toepassing.

Veelvoorkomende stuurprogramma's kunnen zijn:

  • Schaal en flexibiliteit van toepassingen.
  • Eenvoudigere acceptatie van nieuwe cloudmogelijkheden.
  • Mix van technologiestacks.

Kwantitatieve analysefactoren:

  • Grootte van toepassingsassets, zoals CPU, geheugen en opslag
  • Afhankelijkheden zoals netwerkverkeer
  • Gebruikersverkeer, zoals paginaweergaven, tijd op pagina en laadtijden
  • Ontwikkelplatforms, zoals talen, gegevensplatforms en services in de middelste laag
  • Database met CPU, geheugen, opslag en versie

Kwalitatieve analysefactoren:

  • Groeiende bedrijfsinvesteringen
  • Bedrijfskosten
  • Potentiële feedbacklussen en DevOps-investeringen

Opnieuw bouwen

In sommige scenario's kan de delta die moet worden overwinnen om een toepassing vooruit te dragen te groot zijn om verdere investeringen te rechtvaardigen. Dit probleem geldt met name voor toepassingen die eerder aan de behoeften van een bedrijf voldoen, maar nu niet worden ondersteund met de huidige bedrijfsprocessen. Als u het probleem wilt oplossen, maakt u een nieuwe codebasis om te worden afgestemd op een cloudeigen benadering.

Veelvoorkomende stuurprogramma's kunnen zijn:

  • Innovatie versnellen.
  • Sneller toepassingen bouwen.
  • Operationele kosten verlagen.

Kwantitatieve analysefactoren:

  • Grootte van toepassingsassets, zoals CPU, geheugen en opslag
  • Afhankelijkheden zoals netwerkverkeer
  • Gebruikersverkeer, zoals paginaweergaven, tijd op pagina en laadtijden
  • Ontwikkelplatforms, zoals talen, gegevensplatforms en services in de middelste laag
  • Database met CPU, geheugen, opslag en versie

Kwalitatieve analysefactoren:

  • Tevredenheid van eindgebruikers afnemen
  • Bedrijfsprocessen beperkt door functionaliteit
  • Potentiële kosten, ervaring of omzetwinst

Vervangen

Oplossingen worden doorgaans geïmplementeerd met behulp van de beste technologie en aanpak die op dat moment beschikbaar is. Soms kunnen SaaS-toepassingen (Software as a Service) alle benodigde functionaliteit bieden voor de gehoste toepassing. In deze scenario's kan een workload worden gepland voor toekomstige vervanging, zodat deze effectief wordt verwijderd uit de transformatie-inspanning.

Veelvoorkomende stuurprogramma's kunnen zijn:

  • Het standaardiseren van best practices voor de branche.
  • Het versnellen van de acceptatie van op bedrijfsproces gebaseerde benaderingen.
  • Het opnieuw toewijzen van ontwikkelingsinvesteringen in toepassingen die concurrerende differentiatie of voordelen creëren.

Kwantitatieve analysefactoren:

  • Algemene verlagingen van bedrijfskosten
  • VM-grootte, inclusief CPU, geheugen en opslag
  • Afhankelijkheden zoals netwerkverkeer
  • Assets die buiten gebruik moeten worden gesteld
  • Database met CPU, geheugen, opslag en versie

Kwalitatieve analysefactoren:

  • Kosten-batenanalyse van de huidige architectuur versus een SaaS-oplossing
  • Bedrijfsprocesoverzichten
  • Gegevensschema's
  • Aangepaste of geautomatiseerde processen

Volgende stappen

Gezamenlijk kunt u deze vijf R's van rationalisatie toepassen op een digitaal onroerend goed om u te helpen bij het nemen van rationaliseringsbeslissingen over de toekomstige status van elke toepassing.