Blog

Checklist deel 2: bepaal jouw architectuur voordat je migreert naar Azure

Als tweede in een reeks artikelen kijken we naar architecturen en waarom het belangrijk is om naar het totaalplaatje te kijken. In ons vorige artikel bespraken we hoe je een strategie kiest voordat je migreert naar Azure.

Wil je een route uitstippelen om te kijken waar je binnen nu en drie jaar staat? Waarschijnlijk niet. Maar je wil waarschijnlijk wel inzicht hebben in hoe je architectuur eruit ziet, wat de kosten zijn en welke toegevoegde waarde het heeft.

De voordelen voor het kiezen om te migreren naar de cloud kan gecategoriseerd worden in een van de scenario’s die wij in het vorige artikel besproken hebben (on and off, growing fast en predictable en unpredictable bursting). Afhankelijk van waar jij staat met je reis in het moderniseren van je applicatie naar azure zal een of meerdere scenario´s interessant zijn. Hoe verder je bent (Iaas-> Paas -> Serverless en Saas) hoe meer voordelen, toegevoegde waarde en efficiëntie je krijgt. Niet te vergeten; hoe verder je bent, hoe meer je focus verschuift van de IT infrastructuur naar de software architectuur.

Maar betekent dit dat je architectuur het ultieme toekomstplaatje moet zijn? Absoluut niet. Met de snel veranderende en steeds verder ontwikkelende public clouds is het vaststellen van een IT-roadmap op lange termijn niet het verstandigste om te doen. Je committeren aan een meerjarig plan is hetzelfde als het investeren in on-premis hardware met een afschrijving van 3-5 jaar. Je omgeving is ‘’oud’’ tegen de tijd dat je een nieuwe roadmap gaat bedenken/bepalen. Een van de belangrijkste voordelen van de public cloud is dat er dagelijks nieuwe functies worden toegevoegd en dat dit onwijs snel gaat. Om te voorkomen dat je overspoeld wordt met de vele opties die de cloud biedt is het belangrijk om te kijken wat je nodig hebt en te focussen op zaken als life cycle management en continuous improvement (DevOps!).

Ik hoor je denken; dat is helemaal geweldig, maar waar beginnen we? Hoe bepaal je waar je moet beginnen, wat je nodig hebt en hoe je het moet gebruiken? Alle wegen leiden (uiteindelijk) naar Rome en hopelijk zal dit artikel je hierbij helpen.

Kennis
De eerste stap is kijken naar de kennis die je nodig hebt om je plannen te realiseren. Dit kan een echte uitdaging zijn. Ga je alles zelf uitzoeken of zoek je hulp? Als het gaat om Microsoft Azure (en public clouds in het algemeen) dan is het eenvoudig om te starten. Je kunt zo een abonnement nemen, je resources uitrollen en al doende leert men. Maar wanneer je jouw propositie opzet wil je er zeker van zijn dat je de juiste kennis hebt om dit te realiseren. Als je Azure specialisten in dienst hebt dan zijn zij een goed startpunt. Maar wij zien vaker dat de juiste kennis en expertise intern niet aanwezig is. Dit is niet fout, dit komt veel voor doordat nieuwe functionaliteiten ontzettend snel worden toegevoegd. Wij adviseren in ieder geval om dit samen te doen met een Microsoft Partner, zoek de architecten op en doorloop het proces met een expert. Microsoft Partners die gespecialiseerd zijn in Azure steken veel tijd in het up-to date houden van alle nieuwe features, worden ook de hoogte gehouden van de nieuwe technieken en hebben vaak ook al informatie over features die nog niet openbaar zijn. En om eerlijk te zijn: wil je je bezighouden met het onderzoeken en testen van nieuwe features of wil je je focussen op het optimaliseren van je software en op de hoogte gehouden worden van alle nieuwe functies die interessant voor je kunnen zijn? In onze ervaring werkt een combinatie tussen beide het beste, je hebt zelf professionals in dienst die alle ins en outs weten over je software oplossing en deze kennis is waardevol. De samenwerking tussen eigen personeel en een Microsoft Partner is bij het opbouwen van een platform voor je oplossing (vaak) het meest efficiënt.

Waar kom je vandaan?
Het is belangrijk om te begrijpen waar je vandaan komt. Zeker vanuit een infrastructuur perspectief. Waar wordt je oplossing momenteel gehost? En hoe ziet je applicatie architectuur er momenteel uit? Ten eerste is het belangrijk te bepalen hoe afhankelijk je bent van je infrastructuur.

Maak je momenteel gebruik van Virtuele Machines (vm’s)?
Is je oplossing momenteel geïnstalleerd (dat wil zeggen je moet je oplossing installeren) en voeg je aanvullende services ter ondersteuning van je oplossing toe?
Of gebruik je een website welke draait of IIS?
Is je applicatie gekoppeld of monolithisch?
Ben je afhankelijk van een netwerk of VPN?
Is je oplossing multi-tenant of maak je een nieuwe omgeving voor elke nieuwe klant?

Dit zijn een paar vragen die je moet beantwoorden voordat je begint met het vertalen van je omgeving naar een public-cloud architectuur. Dit artikel geeft je verschillende inzichten over waar je nu bent en waar je naartoe wil.

Wat is je motivatie om naar Azure te migreren?
Vaak heb je een stimulans nodig voordat je besluit om je oplossing te hosten op een nieuw platform. Wij kunnen je veel redenen geven waarom je dit zou willen, te denken aan onder andere de volgende:

Efficiency;
Eenvoudige en geautomatiseerde implementaties/updates? (DevOps);
Het voorblijven van je concurrentie (schaalbaarheid, wereldwijde toegang/beschikbaarheid);
Concurrerende prijzen (bij gebruik van de juiste architectuur);
Focussen op het bouwen van je oplossing, niet op het beheren ervan;
Eco-systeem (community, support, features, etc.).

Als we kijken naar het voorgaande artikel (bepaal je strategie voordat je migreert naar Azure) en je de migratie opties vergelijkt met waar je nu staat en waar je naartoe wil dan weet je ongeveer waar je cloud journey start.

In het vorige artikel hebben we de volgende strategieën besproken:

Rehost (lift en shift);
Refactor ;
Rearchitect (optimaliseren van je code);
Rebuild (herbouwen).

Als je weet wat je doel is krijg je een duw in de goede richting als het gaat om welke architectuur bij jouw oplossing past. Wil jij je focussen op het bouwen van je oplossing en is dit je belangrijkste reden om gebruik te maken van Microsoft Azure? Dan zijn virtuele machines waarschijnlijk niet het beste waar je kan beginnen maar dan is platform as a service (PaaS) oplossingen wellicht interessant, zoals App services of Serverless.

Maar als je worstelt met de beschikbaarheid en het beheer van je huidige oplossing dan is de overstap naar virtuele machines interessant en kan dit je veel voordelen bieden (bijvoorbeeld; geautomatiseerd beheer, wereldwijde beschikbaarheid) en concurrerende prijzen als je bijvoorbeeld gebruik maakt van het ‘’on and off scenario’’.

Maar als je niet zeker weet of je serverless wilt gaan en nog steeds afhankelijk bent van virtuele machines is refactoring wellicht interessant (het maken van een kleine aanpassing) en kan het gebruiken van containers interessant zijn. In principe kan je overal beginnen, afhankelijk van hoeveel moeite je van plan bent erin te stoppen. Maar waar ben je naar opzoek?

Welke platformen
Laten we een stap terug doen en kijken naar de platformen die Microsoft Azure aanbiedt:

Infrastructure as a Services (IaaS);
Platform as a Service (PaaS);
Serverless ;
Software as a Service (Replace).

Infrastructure as a Service
Soms noemen we Infrastructure as a Service op Microsoft Azure ook wel Azure Compute. Eenvoudig gezegd krijg je virtuele machines, netwerken en een heleboel toevoegingen zoals back-up, disaster recovery, automatisch management, security, monitoring etc. Maar je maakt nog steeds gebruik van virtuele machines.
Het grootste voordeel bij traditionele virtuele machines is dat er geen reden is waarom je je oplossing niet op basis van IaaS op Azure kan hosten. Je kunt Windows en Linux draaien en je hebt nog steeds de volledige controle over het besturingssysteem. Maar dit betekent ook dat je het zelf moet beheren, inclusief de SLA eisen (bijvoorbeeld, beschikbaarheidseisen) En.. je kan het wereldwijd inzetten!

IaaS is geschikt voor de meeste toepassingen die gebaseerd zijn op monolithische en tightly coupled software architecturen. Als je doel is om wereldwijd schaalbaar te zijn, te beschikken over een uitstekende beschikbaarheid en gebruik wil maken van het on and off scenario dan is IaaS een hele goede optie. Maar let wel op: IaaS is goed om mee te beginnen, maar als je echt wil profiteren van alles wat Azure te bieden heeft dan is dit niet je eindstation. Als je de financiële middelen en tijd hebt dan is platform as a service of serverless wellicht een betere oplossing voor de lange termijn.

Platform as a service
De naam beschrijft het al; je krijgt een platform. Wat er gebeurt wanneer je naar een PaaS omgeving migreert is dat je veel van management (inclusief het operating system) uit handen geeft. Met PaaS op Azure wordt er veel voor je beheerd, zoals:

Besturingssysteem updates;
In de meeste gevallen krijg je een hogere beschikbaarheid (SLA);
Beveiliging (let op: dit is een gedeelde verantwoordelijkheid);
Netwerken;
Loggen;

De meest voorkomende PaaS oplossingen op Azure zijn; App Services (Web Apps), Azure SQL, Storage en Azure Kubernetes Services (AKS).

Met Paas richt je je op de implementatie en configuratie van je oplossing, maar heb je geen omkijken meer naar de traditionele IT activiteiten. In het algemeen hoeft het niet te betekenen dat je applicatie over de kop moet gooien, maar het vereist wel dat je de applicatie ontwikkelt en implementeert volgens bepaalde standaarden. Bijvoorbeeld; als je op dit moment een IIS website hebt en je documenten opslaat op een lokale disk zou je kunnen overwegen om gegevens op te slaan op caching oplossingen zoals Azure Redis Cache, of je loopt het risico dat je inlevert op flexibiliteit (kijk naar het concept van stateless).

Net als bij Microsoft Compute betaal je met Paas nog steeds naar wat je uitrolt. Als je een App Service plan uitrolt, betaal je per uur. Maar het on and off scenario gaat hier niet op. Je kan Paas diensten niet uitzetten, maar wel verwijderen als je ze niet meer nodig hebt. In tegenstelling tot Iaas, waar je wel gebruik kunt maken van het on and off scenario. Paas-oplossingen kosten over het algemeen wel minder in vergelijking met Iaas- oplossingen, dus het aan en uit scenario is dan ook minder interessant.

Serverless
Naast IaaS en PaaS hebben we ook serverless. Serverless geeft je het meeste waar voor je geld. Het concept achter serverless is dat deze functionaliteiten volkomen development gedreven zijn. Serverless computing is de abstractie van servers, infrastructuur en besturingssystemen. Je richt je op development, niet meer op beheer of platform management. Er zijn veel oplossingen beschikbaar binnen het serverless portfolio, de meest bekende zijn: Azure Functions, CosmosDB en EventGrid.

Serverless is anders qua kosten in vergelijking met IaaS en Paas. Bij IaaS en PaaS betaal je per uur en met serverless betaal je voor wat je daadwerkelijk gebruikt. Neem bijvoorbeeld Azure Functions. Je betaalt €0,169 per miljoen executions, waarbij het eerste miljoen excecutions kosteloos is.
Daarnaast is schaalbaarheid vrijwel onbeperkt en geautomatiseerd. Als je een functie een of honderden keren tegelijkertijd uitvoert zullen de prestaties hetzelfde zijn en Microsoft regelt en beheert het op en afschalen voor jou.

Een ander groot voordeel van serverless is dat je de oplossing wereldwijd kan schalen zonder veel moeite. Dit komt omdat je je kan focussen op development en de infrastructuur is beschikbaar op iedere locatie waar jij je code wilt deployen.

Daarnaast als je kijkt naar de data, wil je misschien kijken naar Azure CosmosDB, hét voorbeeld als je het hebt over data opslag in de cloud . Met CosmosDB krijg je kant-en-klare wereldwijde distributie, ongekende beschikbaarheid en je hoeft geen platform te managen, het enige waar je je zorgen over moet maken is waar je de gegevens opslaat en naartoe repliceert

Om eerlijk te zijn is serverless niet het eerste waar je aan denkt als je start met het rehosten van je applicatie maar vanuit een kosten- en functionaliteitenperspectief is dit wel waar je naartoe wil. Serverless past het beste bij event-driven architectuur, micro-services architectuur en helpt je met het ontkoppelen van je applicatie (kijk eens naar Azure Service Bus of Event Grid).

Samenvattend
Er zijn verschillende platformen waar je uit kan kiezen, maar wanneer kies je welke? Laten we de belangrijkste dingen even samenvatten. Ten eerste: elke architectuur heeft weer andere voordelen. En belangrijk is om de juiste architectuur te vinden die het beste bij jouw wensen en behoeftes past.

Hieronder zijn de belangrijkste voordelen samengevat:

(Let op: deze lijst kan je helpen om voor jou de juiste architectuur te vinden. Echter hoe meer informatie je hebt over je huidige situatie hoe specifieker er kan worden ingezoomd op de mogelijkheden van Azure. Onderstaande lijst is bedoeld om je een duw in de juiste richting te geven).

Dit is slechts een samenvatting van de voor-en nadelen van verschillende architecturen en platformen. En om eerlijk te zijn met de snelheid waarmee de public clouds zich ontwikkelen zijn sommige uitdagingen wellicht al opgelost tegen de tijd dat je begint met de implementatie. Wat belangrijk is om te begrijpen is dat je overal aan je cloud reis kan beginnen, maar je moet een goed plan hebben en goed voor ogen hebben waar je naartoe wil voordat je een platform kiest en begint.

Lees ook checklist deel 3: de basis van schalen in Azure.

Migrate ISV Roadmap