Hoe u voordelen voor cloudmigratie kunt kwantificeren en kwalificeren

Het is een uitgemaakte zaak dat de toekomst van enterprise business in de cloud ligt. Dit geldt vooral als je bedenkt welke grote rol cloudmigratie de afgelopen jaren heeft gespeeld binnen de bedrijfsruimte:

De uitgaven voor cloudcomputing zijn sinds 2009 met 4,5 keer zo snel gestegen als de IT-uitgaven en zullen naar verwachting tot 2020 met meer dan zes keer zo snel groeien.

Forbes Cloud Computing Roundup

Dit wordt ondersteund door de nieuwste gegevens van Oracle, waarvan de nummer twee voorspelling voor 2019 was dat 80 procent van alle enterprise-workloads, inclusief de workloads die als "mission critical" worden beschouwd, in de komende 12 maanden naar de cloud zal verhuizen.

Ondanks de vrijwel alomtegenwoordigheid van de cloud in de hele onderneming (en de groeiende bekendheid met cloudtechnologieën voor zowel IT-experts als leken), is het verplaatsen van workflows naar de cloud geen sinecure. Dit geldt met name als het gaat om het managen van verwachtingen en het daadwerkelijk leveren van verbeteringen - of deze nu verband houden met kosten of prestaties - wanneer de migratie is voltooid.

Om ervoor te zorgen dat teams geen beloftes doen die ze niet kunnen waarmaken, hebben ze zichtbaarheid nodig in elke fase van hun cloudmigratie. Immers, "je kunt niet beheren wat je niet kunt meten, ” luidt het oude mantra, en daarom moeten IT-teams inzicht hebben in elke fase van de migratie om nauwkeurige verwachtingen te stellen en problemen voor te blijven voordat ze de hele onderneming ontsporen.

Aanvaardbare prestatiedoelen definiëren

Om te beginnen moeten teams volledig begrijpen welke applicaties, netwerkinfrastructuur of processen het vaakst kapot gaan. IT zal waarschijnlijk cross-functioneel moeten interviewen om informatie en buy-in door de hele organisatie te krijgen.

Een pleidooi houden voor cloudmigratie is misschien gemakkelijk als IT in algemeenheden denkt. Natuurlijk, het uitbesteden van het onderhoud van netwerkhardware zal aantrekkelijk lijken voor prijsbewuste besluitvormers, maar hoeveel investeringen zijn er vooraf nodig voordat het bedrijf die besparingen kan realiseren?

De kosten alleen zijn misschien ook niet genoeg om alle besluitvormers te verleiden. Als cloudmigratie de prestaties verbetert van verschillende apps die als bedrijfskritisch worden beschouwd, gaat dit dan ten koste van tools die elders worden gebruikt? Worden de app-prestaties tijdens de migratie beïnvloed, en voor hoe lang? Is er nieuwe training vereist voor gebruikers?

Teams moeten al deze vragen begrijpen voordat ze hun migratievoorstellen naar het directieteam brengen. Dit vereist dat IT serieus nadenkt over de huidige staat van het netwerk om een ​​basislijn van bestaande prestaties te creëren. Op deze manier kunnen teams de mening van besluitvormers bevestigen of informeren over waar verbetering het meest nodig is en de oplossing in de context van de cloud plaatsen.

Baseliningprestaties vóór migratie

De ervaring van de eindgebruiker is waar deze basislijning allemaal begint. IT zal immers niet succesvol zijn als de eindgebruikerservaring van medewerkers niet verbetert - of juist merkbaar slechter is - na cloudmigratie. Zelfs besluitvormers die zich uitsluitend op het eindresultaat richten, zullen het hiermee eens zijn, aangezien een slechte gebruikerservaring een domino-effect kan hebben op de prestaties van het grotere bedrijf. IT moet daarom inzoomen op de "huidige staat" van het netwerk (samen met de tevredenheid van de gebruiker) voordat architecturen worden ontworteld.

Voor applicaties vereist dit synthetische webtests die IT lokaal perspectief geven in wat gebruikers daadwerkelijk ervaren op de locaties waar ze werken, samen met duidelijk zicht op het hele leveringspad. Met deze informatie bij de hand kan IT 'acceptatiecriteria' vaststellen waaraan ze moeten voldoen tijdens en daarna cloudmigratie om ervoor te zorgen dat gebruikers tevreden blijven. Sommige voorbeeldcriteria kunnen er als volgt uitzien:

• De reactietijd moet binnen 5 procent van de niveaus vóór de migratie liggen
• Servicefoutpercentages moeten gelijk zijn aan of lager zijn dan het niveau vóór de migratie
• Beschikbaarheid van applicaties moet gelijk zijn aan of lager zijn dan de niveaus vóór de migratie
• Infrastructuurkosten moeten tijdens de migratie met ten minste X procent worden verlaagd

Teams moeten daarom een ​​​​pulscontrole krijgen over hoe snel apps momenteel aan gebruikers worden geleverd, latentie tussen servers (zowel intern als extern, DNS, enz.), Foutpercentages, soorten fouten en browserspecifieke prestatieproblemen. Alleen met al deze gegevens kan IT zich om de toestand van de pre-migratie van het netwerk wikkelen.

Doorgaan met toezicht tijdens de migratie

Als teams eenmaal baselines hebben opgesteld, is het belangrijk dat ze hun acceptatiecriteria tijdens het migratieproces blijven volgen. Teams moeten dashboards en waarschuwingen kunnen maken die kunnen signaleren wanneer het netwerk niet aan de criteria voldoet, idealiter met behulp van dezelfde metrische gegevens, zo niet monitoringoplossing, die ze hebben verwezen naar de basisprestaties.

• Uptime - Voor cloudapplicaties mag IT verwachten dat de downtime gedurende een bepaalde week beperkt is tot minuten. De meeste openbare apps streven naar 99,9% of beter (~7 minuten in elke werkweek).
• DNS - Voor apps die zich nu in de cloud bevinden, zal IT waarschijnlijk een lokale DNS-server of openbare DNS-service hebben die het IP-adres levert. Dit is iets dat actief moet worden gecontroleerd, omdat het verbindingen voor alle gebruikers op een bepaalde locatie zal voorkomen.
• Latentie, RTT - Nu services zich buiten het datacenter of buiten het kantoor bevinden, kan er een significant verschil zijn in de tijd die het verkeer nodig heeft om van client naar server te reizen. Pieken hier kunnen te maken hebben met LAN-, ISP- of app-problemen.
• Capaciteit - Betalen voor bandbreedte van een ISP is één ding, maar de end-to-end capaciteit van een netwerk tussen gebruikerslocatie en app-server zal waarschijnlijk een ander knelpunt hebben. Met deze meting kan IT vaststellen wanneer congestie de verbindingssnelheden beïnvloedt.

Pieken en sprongen zijn nuttige indicatoren van migratiegerelateerde bugs die onmiddellijk moeten worden aangepakt - zelfs voordat nieuwe zakelijke verzoeken - om problemen te stoppen voordat ze zich verspreiden. Door problemen op te lossen, zijn de ogen van IT direct op het probleem gericht, waardoor teams eerder de meest geschikte oplossing implementeren.

Maak gebruik van monitoring om succes te kwalificeren

De basislijn die teams vóór de migratie hebben uitgevoerd, moet ter vergelijking opnieuw worden gedaan zodra de nieuwe netwerkarchitectuur is geïnstalleerd. De sleutel hier is om dezelfde processen (gebruik, patronen, tijd, etc.) te gebruiken die zijn getest via het oude netwerk.

Bij alle cloudmigraties gaat er een bepaald niveau van controle verloren. Of dat nu op het bare metal-, OS- of toegangsniveau is, het is ook belangrijk dat teams moderne monitoringoplossingen gebruiken die hetzelfde niveau van zichtbaarheid kunnen bieden in het nieuwe cloudondersteunde netwerk. Als de infrastructuur geen eigendom meer is van IT, wordt de zichtbaarheid met oude monitoringtools aangetast. Dit is cruciaal, omdat veel monitoringoplossingen geen inzicht kunnen bieden in cloudomgevingen of zelfs buiten IT-firewalls.

Zonder inzichten buiten de firewall is het voor IT moeilijk om problemen die voortkomen uit ISP of infrastructuur van derden te identificeren en snel op te lossen. Dit kan zowel de migratie vertragen terwijl deze aan de gang is, als gebruikers buiten de IT nostalgisch maken voor de dagen vóór de cloud als de prestaties voortdurend worden belemmerd.