Management

Dit is een bijdrage van Rubrik
Apps
Tips om je app naar de cloud te migreren

Tips om je app naar de cloud te migreren

De concepten en vereisten om een app van een lokaal datacenter naar een andere locatie te migreren.

22 juli 2019
Door: Rubrik, partner

De concepten en vereisten om een app van een lokaal datacenter naar een andere locatie te migreren.

Door Filip Verloy, Field CTO EMEA bij Rubrik

In dit blog bespreek ik wat er nodig is om een app van een lokaal datacenter naar een andere locatie te migreren. Deze nieuwe locatie is meestal een cloudprovider, maar veel van de concepten zijn ook van toepassing bij het verhuizen naar een DR-locatie of zelfs naar de laptop van een developer. In ons voorbeeld gebruiken we een van de meest voorkomende drielaagse apps: WordPress

Nu de kosten van cloud computing dalen en hybride cloud-infrastructuren de gewoonste zaak van de wereld zijn, proberen veel bedrijven een manier te vinden om hun apps naar de cloud te migreren. Er is een flink aantal redenen waarom app-migratie momenteel zo’n hot topic is:

  • Potentiële kostenbesparingen
  • Gebruik voor disaster recovery
  • Apps refactoren of moderniseren
  • Toegang tot snel schaalbare bronnen
  • Integratie met SaaS-platformen of nieuwe cloudgebaseerde tools (bijvoorbeeld Amazon RDS, Azure App Services en Google Cloud Spanner)

In ons voorbeeld gebruiken we een van de meest voorkomende drielaagse apps: WordPress. Het onderstaande diagram beschrijft de componenten van deze app.

Cloud App Migration Overview

 

Begrijp je App
Laten we eerlijk zijn - apps kunnen best complex zijn. Als je een achterstand hebt opgebouwd in het documenteren van je apps of als je niet goed weet hoe ze in verbinding staan met andere apps of bedrijfsprocessen, dan heb je huiswerk te doen. Je moet alle aspecten van de app documenteren en begrijpen, inclusief:

  • Het platform
  • De applicatiestaat
  • Het data-format en de opslag
  • Het netwerk
  • Veiligheid en compliance

Laten we wat dieper op deze onderwerpen ingaan.

Het platform
Je kunt het best beginnen met het doorgronden van het applicatieplatform. Enkele vragen die je kunt stellen:

  1. Werkt de app op een speciale bare metal-server, op een VM of in een Docker-container?
  2. Welke hypervisor gebruik je voor virtualisatie?

Elk van deze scenario’s zorgt voor een ander "pad" wanneer het wordt aangepast. Ons WordPress-voorbeeld bestaat uit op VMware gebaseerde VM's, wat een uitdaging vormt als we ze willen verplaatsen naar een grote cloudprovider (zoals AWS, GCP of Azure), vanwege de incompatibiliteit met hypervisor. Dit wordt meestal een "lift en shift"-benadering genoemd. Het is mogelijk om bestaande VM's te converteren naar het format dat door de provider wordt gebruikt. Verdiep je hiervoor goed in de documentatie van de tools en wees voorbereid op een zekere mate van vallen en opstaan.

De applicatiestaat
Het volgende principe dat je moet doorgronden is de applicatiestaat. Deze heeft verschillende definities, afhankelijk van het gedrag van de app of het framework, maar in het algemeen geeft het aan waar de app informatie opslaat. De applicatiestaat kan een aantal dingen vertegenwoordigen: de configuratie-instellingen, de inhoud van het winkelwagentje, de productbestellingen of een blogpost met comments. Zonder deze gegevens is de app als een onbeschreven blad met weinig waarde. Je moet deze gegevens samen met de app overzetten, anders moet je weer helemaal opnieuw beginnen. Vaak kun je de applicatiestaat in een database vinden, zoals in het WordPress-voorbeeld.

Databases gebruiken verschillende methoden voor het verplaatsen van staatgegevens (bijvoorbeeld replicatie, back-up/restore), dus je moet de methode kiezen die het beste bij de use-case past. Voor ons WordPress-voorbeeld maak ik gebruik van snapshot-gebaseerde back-ups via CDM. Dit kan problematisch zijn voor databases vanwege het feit dat een momentopname mid-write kan worden gemaakt, wat kan resulteren in een niet-functionele database wanneer je hem herstelt. Dit concept wordt ook wel "back-upconsistentie" of "snapshotconsistentie" genoemd en het is vooral belangrijk om dit te begrijpen wanneer je een op snapshots gebaseerde back-upmethode gebruikt.

Voor consistente back-ups van stateful apps, zoals databases, kan een agent op het besturingssysteem nodig zijn, of bijvoorbeeld pre- en post-snapshot-scripts. Dit principe is van toepassing op zowel storage-array-gebaseerde snapshots als op VM-gebaseerde snapshots. Een manier om dit aan te pakken is een pre-snapshot-script gebruiken om de databasetabellen te vergrendelen en een post-snapshot script om ze te ontgrendelen. Dit is een werkbare oplossing voor onze eenvoudige MariaDB-database, maar er zijn ook app-bewuste back-upmethoden voor populaire bedrijfsdatabases zoals Microsoft SQL en Oracle beschikbaar om dit op te lossen.

https://www.rubrik.com/wp-content/uploads/2019/05/Migrating-Cloud-Apps-8.png

Dataformat en opslag
Wanneer je eenmaal inzicht hebt gekregen in de app en de staat van de app, is het tijd om naar de 'massa' van de app te kijken.

  1. Hoeveel data moet je met de app meeverhuizen?
  2. Hoeveel kost het in connectiviteit en opslagkosten om te verplaatsen en te draaien?

Moet je al je gegevens verplaatsen of is een subset voldoende?
Met behulp van deze berekeningen kun je bepalen hoeveel moeite er moet worden gedaan om de app te verplaatsen en hoeveel het kost na de verhuizing. Een ander concept dat handig is om te overwegen is de “data-zwaartekracht”. Dit sluit aan bij het idee dat data massa heeft. Naarmate de hoeveelheid gegevens toeneemt, trekt het extra apps en services aan en wordt het moeilijker om te verplaatsen. Bedenk dat het verplaatsen van een bedrijfskritische app, gevuld met jaren aan belangrijke data, mogelijk meerdere gerelateerde apps met zich meesleept, die ervan afhankelijk zijn. Het is misschien mogelijk om bepaalde apps op verschillende locaties te houden, zelfs als ze op dezelfde gegevens zijn gebaseerd, maar je betaalt dit meestal in netwerkkosten en niet te vergeten extra complexiteit.

Het netwerk
Over netwerkkosten gesproken, dat is een mooi bruggetje naar mijn favoriete onderwerp: netwerken. Laten we eens kijken naar ons WordPress-voorbeeld, dat een heel eenvoudige netwerkconfiguratie vertegenwoordigt.

Cloud App Migration Network Traffic Overview

 

Vergelijk dit eens met oudere apps die bestaan uit tientallen of honderden servers of apps zonder goed gedocumenteerd TCP/UDP-poortgebruik, en het wordt al snel duidelijk dat de planning voor het verplaatsen van een grote of slecht gedocumenteerde app al snel uit de hand kan lopen. Wat we hiervan kunnen leren, is dat je goed moet begrijpen hoe je app communiceert en welke poorten hij gebruikt om te communiceren. Als je netwerktoepassingen hebt, zoals load balancers, evalueer dan hoe nauw ze zijn gekoppeld aan de app en of er bruikbare vervanging is op de bestemmingslocatie voor de app.

Veiligheid en compliance
Het laatste stukje van de puzzel is veiligheid en compliance:

Zijn er wetten voor gegevensbeheer of nalevingsvoorschriften die van toepassing zijn op de app of de bijbehorende gegevens? Als dat zo is, dan kan dat beperkingen opleggen aan waar je de app kunt draaien.

Heb je een goed uitgewerkt beveiligingsbeleid voor de app? Zo niet, dan is het tijd om er een te maken.

Dit document moet alle beveiligingsvereisten voor de app definiëren, inclusief verificatie, autorisatie, op functies gebaseerd toegangsbeheer, firewallregels en coderingsbehoeften. Als er een bestaand beleid is, moet je vaststellen wat er moet worden gewijzigd als je de app verplaatst. Het is het vermelden waard dat het afdwingen van een beveiligingsbeleid bij een cloudprovider veel onderzoek en planning vereist.

Ik adviseer om aan het begin van het planningsproces je beveiligings- en compliance-teams te raadplegen. Ze zullen het op prijs stellen dat ze vanaf het begin deel uitmaken van het project en ze kunnen waardevolle begeleiding bieden tijdens het plannen. Je gaat geen tijd besteden aan het plannen van een app-migratie om de boel te moeten annuleren door beveiligings- of compliance-problemen.

Begrijp de bestemming
Vanuit het oogpunt van inspanning zal het altijd makkelijker zijn om een app te migreren naar een bestemming die een vergelijkbare technologieomgeving gebruikt dan naar een bestemming die aanzienlijk verschilt. Ons WordPress-voorbeeld, dat in VMware draait, vormt een probleem: geen van de grote cloudproviders draait een VMware-hypervisor in hun standaard computing-aanbod. Dit kan ertoe leiden dat je naar kleinere providers gaat kijken die dat wel doen, of dat je voor grotere use cases je toevlucht neemt tot de VMware Cloud op AWS. De grote clouds bieden de beste prijs, connectiviteit en extra diensten, dus het is vaak de moeite waard om de overstap te maken. Er zijn echter wel enkele dingen waarmee je rekening moet houden.

Het eenvoudigweg migreren van VM's naar de cloud is een makkelijke manier om vertrouwd te raken met de interface en de tools, maar in sommige gevallen zul je gedwongen zijn om "cloud-native" beginselen te volgen. Cloud-native apps zijn vanaf het begin ontwikkeld om te profiteren van de cloud en voldoen meestal aan de Twelve-Factor App-methodologie voor webgebaseerde apps. Het volledig refactoreren van de app naar een cloud-native architectuur is een optie voor het migreren, maar wellicht niet haalbaar vanwege tijd of geld. Door de VM's te migreren, kunt je de cloud-native beginselen in je eigen tempo oppakken.

De eerste grote verandering
De eerste grote verandering is voor de meeste bedrijven de overstap van VM's met statisch toegewezen IP-adressen naar dynamische adressen die zijn toegewezen door DHCP. Dit betekent dat je DNS-entries moet gebruiken om verbinding te maken met VM's en services. De grote cloudproviders maken dit zo eenvoudig mogelijk door DNS-entries voor je VM's te genereren. Ze bieden bovendien managed DNS-diensten die via een API kunnen worden beheerd.

In een traditionele omgeving is het meestal geen probleem om een IP-adres hard te coderen in de configuratiebestanden voor MariaDB, WordPress of NGINX. Dat is precies wat ik deed toen ik WordPress 

Reactie toevoegen