Cloudrationalisatie
Cloudrationalisatie is het proces van het evalueren van assets om te bepalen wat de beste manier is 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 potentiële toekomstige status te labelen voor elke workload die als een cloudkandidaat wordt beschouwd. Plaats dit labelproces in de juiste context voordat u probeert een omgeving te rationaliseren. Bekijk de volgende mythes om deze context te bieden:
Mythe: Het is gemakkelijk om vroeg in het proces rationalisatiebeslissingen te nemen
Een goede rationalisatie vereist een grondige kennis van de workload en de bijbehorende assets, zoals toepassingen, infrastructuur en gegevens. Het belangrijkste is dat goede rationaliseringsbeslissingen tijd kosten. U wordt aangeraden een incrementeel rationaliseringsproces te gebruiken.
Mythe: Cloudimplementatie moet wachten totdat alle workloads worden gerationaliseerd
Wanneer een volledig IT-portfolio of zelfs één datacenter wordt gerationaliseerd, kan dit de realisatie van bedrijfswaarde met maanden of zelfs jaren vertragen. Vermijd indien mogelijk volledige rationalisering. 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 op het punt staan voor overstap naar de cloud.
Mythe: Zakelijke rechtvaardiging moet wachten tot alle workloads zijn gerationaliseerd
Als u een zakelijke reden wilt ontwikkelen voor een overstap naar de cloud, doet u enkele basisaannames op portfolioniveau. Wanneer motivaties zijn afgestemd op innovatie, gaat u ervan uit dat de architectuur opnieuw wordt aangepast. Als ze zijn afgestemd op de migratie, gaat u ervan uit dat deze opnieuw worden gehost. Deze veronderstellingen kunnen het proces van zakelijke rechtvaardiging versnellen. Tijdens de evaluatiefase van de acceptatiecyclus van elke workload worden de veronderstellingen vervolgens onder de aandacht genomen en worden budgetten verfijnd.
Bekijk nu de volgende vijf R's van rationalisatie om vertrouwd te raken met het langetermijnproces. Kies tijdens het ontwikkelen van uw cloudmigratieplan de optie die het beste aansluit bij uw motivaties, bedrijfsresultaten en huidige statusomgeving. Het doel van de rationalisering van digitale activa is het instellen van een basislijn, niet het rationaliseren van elke workload.
De vijf R's van rationalisatie
De volgende vijf R's van rationalisatie beschrijven de meest voorkomende opties voor rationalisatie.
Opnieuw hosten
Ook wel een lift-and-shift-migratie genoemd, verplaatst een rehost-inspanning een huidige statusasset naar de gekozen cloudprovider met minimale wijzigingen in de algehele architectuur.
Veelvoorkomende stuurprogramma's kunnen zijn:
- Kapitaalkosten verminderen.
- Datacenterruimte vrijmaken.
- Behaalt snel rendement op investeringen in de cloud.
Kwantitatieve analysefactoren zijn:
- VM-grootte, inclusief CPU, geheugen en opslag.
- Afhankelijkheden, zoals netwerkverkeer.
- Assetcompatibiliteit.
Kwalitatieve analysefactoren zijn:
- Tolerantie voor verandering.
- 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 in een PaaS-model past.
Herstructurering verwijst ook naar het proces voor het ontwikkelen van toepassingen waarbij code wordt geherstructureer zodat een toepassing nieuwe zakelijke kansen kan benutten.
Veelvoorkomende stuurprogramma's zijn onder andere:
- Snellere en kortere updates.
- Draagbaarheid van code.
- Meer cloudefficiëntie om te helpen bij resources, snelheid, kosten en beheerde bewerkingen.
Kwantitatieve analysefactoren zijn:
- 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 zijn:
- Doorlopende bedrijfsinvesteringen.
- Bursting-opties of tijdlijnen.
- Bedrijfsprocesafhankelijkheden.
Opnieuw ontwerpen
Sommige verouderde toepassingen zijn niet compatibel met cloudproviders. Deze incompatibiliteit wordt veroorzaakt door de beslissingen over de architectuur die zijn genomen toen de toepassing werd gebouwd. In deze gevallen moet de toepassing mogelijk opnieuw worden gearchitecteerd voordat de transformatie wordt uitgevoerd.
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 zijn onder andere:
- Toepassingsschaal en flexibiliteit.
- Eenvoudigere acceptatie van nieuwe cloudmogelijkheden.
- Combinatie van technologiestacks.
Kwantitatieve analysefactoren zijn:
- 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 zijn:
- Om zakelijke investeringen te laten groeien.
- Bedrijfskosten.
- Mogelijke feedbacklussen en DevOps-investeringen.
Opnieuw bouwen
In sommige scenario's kan de delta die moet worden overbrugd om een toepassing door te voeren te groot zijn om verdere investeringen te rechtvaardigen. Dit probleem geldt met name voor toepassingen die eerder aan de behoeften van een bedrijf voldden, maar nu niet worden ondersteund met de huidige bedrijfsprocessen. U kunt het probleem oplossen door een nieuwe codebasis te maken die is afgestemd op een cloudeigen benadering.
Veelvoorkomende stuurprogramma's kunnen zijn:
- Innovatie versnellen.
- Bouw toepassingen sneller.
- Operationele kosten verlagen.
Kwantitatieve analysefactoren zijn:
- 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 zijn:
- Afnemende tevredenheid van eindgebruikers.
- Bedrijfsprocessen die worden beperkt door functionaliteit.
- Potentiële kosten-, ervarings- 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 voor de gehoste toepassing bieden. In deze scenario's kan een workload worden gepland voor toekomstige vervanging, waardoor deze uit de transformatie-inspanning wordt verwijderd.
Veelvoorkomende stuurprogramma's zijn mogelijk:
- Standaardiseren op basis van best practices in de branche.
- Versnel de acceptatie van bedrijfsprocesgestuurde benaderingen.
- Ontwikkelingsinvesteringen opnieuw toewijzen aan toepassingen die concurrentieverschillen of voordelen opleveren.
Kwantitatieve analysefactoren zijn:
- Algemene verlagingen van de operationele kosten.
- VM-grootte, inclusief CPU, geheugen en opslag.
- Afhankelijkheden, zoals netwerkverkeer.
- Activa die buiten gebruik moeten worden gesteld.
- Database met CPU, geheugen, opslag en versie.
Kwalitatieve analysefactoren zijn:
- Kosten-batenanalyse van de huidige architectuur versus een SaaS-oplossing.
- Bedrijfsprocestoewijzingen.
- Gegevensschema's.
- Aangepaste of geautomatiseerde processen.
Volgende stappen
U kunt deze vijf R's van rationalisatie toepassen op een digitale activa om u te helpen rationalisatiebeslissingen te nemen over de toekomstige status van elke toepassing.