Organisaties die hun applicatielandschap geschikt maken voor de cloud, doen dat het beste in drie stappen. Om de vragen en uitdagingen die tijdens de migratie ontstaan het hoofd te bieden, speelt performance monitoring een cruciale rol.
Klanten vertellen mij regelmatig dat de cloud door hen wordt gezien als onderdeel van hun digitale transformatiestrategie. Dat kan de migratie naar een publiek, privaat of hybride cloudplatform zijn. In elk geval verkent vrijwel elk bedrijf momenteel in deze mogelijkheden of investeert hier al in.
De resultaten van nieuw onderzoek uitgevoerd door O’Reilly Media verbazen dan ook niemand: 94 procent van de respondenten noemt migratie naar cloudtechnologie de belangrijkste strategie voor de komende vijf jaar. Het vaakst wordt gemigreerd naar een publieke clouddienst.
Raamwerk voor 3 fasen
Het handigste is dan om een raamwerk met drie fasen te ontwikkelen waarin organisaties zich bevinden als ze stappen zetten naar een applicatieomgeving die cloud-native is. Deze drie fasen zijn:
Eerste fase: de bestaande applicaties migreren naar een gevirtualiseerde infrastructuur, met een lift-and-shift aanpak. Er wordt gezorgd voor een geautomatiseerde, continue integratie en/of een continue applicatiepijplijn.
Tweede fase: grote omvangrijke applicaties – ook wel monolieten genoemd – worden opnieuw ontworpen en gebouwd op basis van een microservicearchitectuur.
Derde fase: gebruik van dynamische, flexibel schalende microservices binnen de software-defined cloudplatformarchitectuur.
In deze digitale reis speelt digitale performance monitoring een essentiële rol. In elke fase ontstaan nieuwe vragen en uitdagingen, waarbij monitoring op feiten gebaseerde antwoorden geeft. Een paar voorbeelden:
Fase 1: de eerste stappen naar de cloud
Een cloudmigratieproject vereist goede voorbereiding. In ons onderzoek noemen respondenten de grootste uitdaging het op de hoogte zijn van alle applicaties die draaien in de organisatie, en de afhankelijkheden van die applicaties in de bestaande omgeving. Het zorgt voor grote risico’s als een organisatie die niet in kaart heeft. Het is daarom een belangrijke stap in het cloudmigratietraject. Monitoringssoftware kan helpen bij het automatisch in kaart brengen van de bestaande afhankelijkheden van een applicatie en de functies die door een monoliet worden aangeroepen. Gedetailleerde prestatiemetingen kunnen ondersteunen bij een juiste capaciteitsplanning.
De uitdaging die daarna wordt genoemd, is het waarborgen van service level agreements (sla’s) voor, tijdens en na de migratie. Moderne monitoringsoplossingen tonen de prestaties over verschillende datacenters naast elkaar. Dit garandeert continuïteit bij een hybride implementatie; het geeft zicht op zowel de oude als nieuwe implementaties, waarbij problemen tijdens de uitrol in de nieuwe omgeving worden opgelost.
Fase 2: de eerste implementaties, vanuit de cloud-native aanpak
Starten met het migreren van grote legacy-applicaties naar microservices kan een uitdaging zijn. Wij denken dat de beste aanpak is om geleidelijk kleine delen van de monolieten te migreren. Omdat de infrastructuur en applicaties steeds flexibeler worden, zoeken organisaties een centrale monitoringsoplossing met continue opsporing, modelering, monitoring en analyses. Geavanceerde monitoringsoplossingen bieden een geïntegreerde databron voor gedistribueerde dynamische systemen. Ze identificeren proactief performanceknelpunten en wijzen binnen luttele seconden de root cause oftewel grondoorzaak van lopende prestatieproblemen aan.
Fase 3: Flexibele microservices
In een zeer dynamische cloudomgeving is niets meer statisch. Alles kan op elk moment en tegelijkertijd worden verplaatst en op- of afgeschaald, afhankelijk van de benodigde capaciteit. Daarom zijn doorlopende automatische opsporing en instrumentatie, systeemstatusbeheer, kunstmatige intelligentie en voorspellende monitoring onmisbare functies van een flexibele en intelligente monitoringsoplossing.
Ik kan me maar heel matig vinden in dit stuk en zal me politiek verwoorden.
De stelling is dat iedere digitale organisatie moet naar de cloud en vervolgens wordt deze hele titel genereert en niet onderbouwd.
Dan heb je het over lift & shift en over micro services? Dat zijn twee hele tegengestelde zaken.
“Dat kan de migratie naar een publiek, privaat of hybride cloudplatform zijn” . Iedere cloud is een private cloud. Heb je wel eens gehoord van clouds waar iedereen bij kan? Maar goed dat is een losse discussie.
“legacy…. geleidelijk kleine delen van de monolieten te migreren.” Heb je daar een voorbeeld van?
Lijkt mij totaal onrealistisch… een eigenschap van legacy is verwevenheid. Good luck with that!
Ieder bedrijf wat “verhuisd” naar de cloud zal iets met zijn Acitve Directory moeten doen en aan het aansluiten van services daarop ofwel IAM. Dat is de basis van *iedere* migratie het kunnen aansluiten op allerlei saas diensten die extern zijn.
Legacy liften en shiften lost niets op en zeker niet in een hybride scenario waarbij een deel nog on-premise blijft of eigen hardware in een datacenter van derden.
Maar goed, ik kan hier weinig zinvols aan onttrekken….
Eens met bovenstaande reactie: het stuk zweeft op een heel globaal niveau en geeft eigenlijk geen antwoord op de zelf gecreëerde verwachting.
Neem een zinsnede in fase 2 als “Wij denken dat de beste aanpak is om geleidelijk kleine delen van de monolieten te migreren.” Mooi gezegd – maar iedereen die wel eens een monolitisch systeem onder handen heeft gehad weet dat het opknippen nu net HET grote probleem is, Als daar als extra complicatie ook nog het verdelen tussen lokale servers en cloud bij komt is het waarschijnlijk sneller, veiliger en voordeliger om compleet te migreren naar een ander systeem – al dan niet meteen cloud based.
Ik lees mijn reactie nog eens door en zie dat ik “on-premise” schrijf, dan moet natuurlijk on-premises zijn.
Nu ik ook het artikel weer lees zie ik:
“Tweede fase: grote omvangrijke applicaties – ook wel monolieten genoemd – worden opnieuw ontworpen en gebouwd op basis van een microservicearchitectuur.”
Wat je hier schrijft is het inlossen van je volledige technische schuld! Dit is zo’n beetje de grootste investering die een bedrijf kan doen en een enorm risicovol traject. Dit is de reden waarom COBOL nog all around is en apps als een extern schilletje aan de buitenkant geplaatst zijn. In feite soort van microservices met stekkers naar de cloud ingeplugd op de monoliet.
Da’s al een stuk minder heftig, maar niettemin wel doorbouwen op de bestaande technische schuld! Al die nieuwigheid migreert namelijk niet makkelijk mee als je “opnieuw begint” of zoals bij skelettransplantatie van de BRP (zie recente artikelen van Rene Veldwijk op deze site)… daar zie je dus hoe moeilijk dat is en wat een geld het kost.