Checklist deel 4: Bepaal de beschikbaarheidseisen voor jouw applicatie op Azure
Checklist deel 4: Bepaal de beschikbaarheidseisen voor jouw applicatie op Azure
Als vierde in een reeks van artikelen gaan we kijken naar beschikbaarheid. Welke beschikbaarheidseisen zijn belangrijk voor jouw applicatie op Azure?
In het vorige artikel hebben we het gehad over schaalbaarheid. Hier hebben we aangegeven dat dit de beschikbaarheid kan verbeteren. Echter, het voornaamste doel van schaalbaarheid is het toewijzen van resources, terwijl beschikbaarheid zich juist focust op hoe en wanneer je deze resources kan benaderen/gebruiken.
Als het gaat om beschikbaarheid maken we onderscheid tussen twee aandachtsgebieden:
Contract (Service level Agreement) met financiële garanties en consequenties;
Technologie welke wordt gebruikt voor het bewerkstelligen van een hogere beschikbaarheid.
Service Level Agreement (SLA) Tijdens het ontwerpen van jouw oplossing met de SLA-vereisten in gedachten, krijg je een stukje gemoedsrust als het gaat om de beschikbaarheid van jouw oplossing, want je oplossing voldoet aan de SLA eisen. Maar, hier zit wel een prijskaartje aan.. Maar onthoudt wel dat we het hier niet over disaster recovery hebben.
Je oplossing valt doorgaans onder de SLA wanneer je meerdere exemplaren (instances) hebt uitgerold in een specifieke configuratie (bijvoorbeeld availability sets of zones), echter hebben we het hier nog steeds over de uitrol binnen een enkele regio. Wat als die regio niet meer beschikbaar is? Hoewel je een SLA hebt waarin zelfs een financiële vergoeding is vastgelegd, zit je nog steeds met de uitdaging: je applicatie is niet beschikbaar. Wat je uiteindelijk wil, is niet alleen een SLA maar ook een goed doordacht disaster recovery scenario.
Service Level Agreements: IaaS vs PaaS Zoals we in deze reeks artikelen al vaker hebben aangegeven kent Azure verschillende niveaus van service en beschikbaarheid, afhankelijk van het platform waarop je implementeert. Hoe verder je standaardiseert op native Azure technologie (IaaS -> PaaS -> SaaS), hoe meer verantwoordelijkheid ten aanzien van de beschikbaarheid wordt overgedragen aan Microsoft. Uiteindelijk ben je nog steeds zelf eindverantwoordelijk voor de beschikbaarheid van je oplossing, maar het begint allemaal bij het kiezen van het juiste platform om aan jouw beschikbaarheidsvereisten te voldoen.
Om dit te illustreren, even een kleine vergelijking tussen de SLA-vereisten van Virtuele Machines en WebApps. Virtual Machines
- Voor alle Virtuele Machines waarbij twee of meer instances zijn geïmplementeerd in twee of meer beschikbaarheidszones binnen dezelfde Azure-regio, garanderen we dat u ten minste 99,99% van de tijd connectiviteit met ten minste één instance van de Virtuele Machine hebt.
- Voor alle Virtuele Machines waarbij twee of meer instances zijn geïmplementeerd binnen dezelfde Availability Set, garanderen we u ten minste 99,95% van de tijd connectiviteit met ten minste een instance van de Virtuele Machine hebt.
- Voor Single-Instance Virtuele Machines die gebruikmaken van premium opslag voor alle Operating System-schijven en Gegevensschijven, garanderen we u ten minste 99,9% van de tijd Connectiviteit van Virtuele Machines hebt.
We garanderen dat alle Apps die worden uitgevoerd in het kader van het abonnement van een klant ten minste 99,95% van de tijd beschikbaar is. Er wordt geen SLA verstrekt voor Apps die worden uitgevoerd onder de Free- of Shared-laag. Bron: Microsoft juli 2016
Wat we hier duidelijk kunnen zien is dat de vereisten voor het verkrijgen van een goede SLA (99,95%) veel lager zijn voor Web Apps dan voor Virtual Machines. Als je met een Virtual Machine de 99,95% SLA wilt bereiken moet je ten minste twee of meer instances in een Availability Set configureren. Bovendien moet de applicatie compatibel zijn met load balancing technologie, aangezien de SLA zich richt op twee of meer Virtual Machines.
Samengevat: Maak je gebruik van IaaS dan heb je simpelweg meer resources nodig om je omgeving conform de SLA vereisten te configureren. Dit is waarschijnlijk duurder en heeft meer aandacht nodig vanuit een IT-beheerperspectief (denk aan updates, aanpassingen in configuratie en back-up). Terwijl je met een reguliere App-Service die SLA al met één deployment krijgt en je hoeft de onderliggende infrastructuur niet te beheren.
Technologie Afgezien van contractuele aspecten is de keuze van technologie van grote invloed op het aantal beschikbare disaster recovery scenario’s, ongeacht de SLA. Als je de juiste (technische) configuratie kiest, heb je uiteindelijk veel meer controle over de beschikbaarheid van je oplossing.
Houd daarom bij het ontwikkelen van je oplossing rekening met de volgende praktische tips:
Deploy vanuit een source control provider Als je de oplossing uitrolt vanuit een repository, via releasemanagement of via een continuous deployment pipeline, gegarandeert dat jouw applicatie altijd ergens anders dan in de infrastructuur wordt opgeslagen (naast alle andere voordelen die dit je biedt). Wanneer een regio uitvalt en je de oplossing opnieuw moet deployen (bijvoorbeeld in een andere regio) is het dan een kwestie van het voorbereiden van de infrastructuur en het opnieuw pushen van de software. Houd er wel rekening mee dat dit geen herstelscenario voor data is.
Goede oplossingen gebruiken het Deployment Center voor Azure App Service of Azure DevOps om de Continuous improvement en Continuous Deployment te beheren. Als je op zoek bent naar een andere oplossing is GitHub ook een geweldige manier om te beginnen!
Wanneer je gebruik maakt van Virtual Machines, gebruik Azure Back-Up Als je kiest voor een Single Instance Virtual Machine zonder SLA, zorg er dan voor dat je Azure Back-up implementeert zodat je een recovery scenario hebt. Bovendien kun je ook kijken naar Azure Recovery Service, waarbij je je omgeving over meerdere regio’s repliceert.
Wanneer je gebruik maakt van opslag (bijvoorbeeld Azure SQL, Storage accounts, CosmosDB), configureer Geo-replicatie Wanneer je gebruik maakt van PaaS- resources activeer dan ook Geo Redundancy; dit is vaak een optie bij de configuratie. Door Geo Redundancy in te schakelen worden de gegevens gekopieerd naar andere regio’s (zorg er wel altijd voor dat wanneer het nodig is, het ook snel beschikbaar is).
Als je bijvoorbeeld gebruik maakt van een storage account geldt het volgende:
Geo-redundante opslag (GRS) is ontworpen om ten minste 99,99999999999% (16 9’s) duurzaamheid van objecten in een bepaald jaar te repliceren naar een secundaire regio met een grote afstand van de primaire regio. Als u storage-account GRS is ingeschakeld heeft, zijn uw gegevens duurzaam zelfs in geval van een volledige regionale stroomstoring of een ramp waarbij de primaire regio niet hersteld.
Wanneer je gebruik maakt van Azure SQL of CosmosDB heb je veel meer opties tot je beschikking. Je kunt je applicatie configureren met actieve geo-replicatie waarmee je ook wereldwijde beschikbaarheid kunt garanderen (bekijk ons artikel over schalen).
Implementeer Traffic Manager Traffic Manager is dé go-to-resource als jij je applicatie wereldwijd beschikbaar wil hebben.
Het is makkelijk te configureren, ondersteunt meerdere endpoints en integreert goed met Azure PaaS-resources. Traffic Manager biedt een centraal toegangspunt tot de applicatie en op basis van de gewenste route kan het verkeer naar de bijbehorende backend sturen. Dit is niet alleen handig bij het wereldwijd schalen van de oplossing (omdat traffic manager het verkeer kan leiden gebaseerd op de originele DNS aanvraag), maar het is ook een goede manier om ervoor te zorgen dat de klanten hun URL’s niet hoeven te wijzigingen wanneer er een regiofout optreedt.
Microsoft heeft verschillende referentiearchitecturen met betrekking tot disaster recovery, deze kun je hier vinden. De komende periode publiceren wij van ieder onderdeel van de checklist meer informatie. Wil je dit niet missen? Laat je gegevens hier achter, dan houden we je op de hoogte.
Tags
ISV Roadmap
Migrate
Geschreven door
Wesley Haakman
Lead Azure Architect bij Intercept | Microsoft Azure MVP | CISSP | Spreker
Wellicht ook interessant:
Een slim en veilig bestelproces bij Reviva dankzij Azure
“Intercept heeft 12 uur non-stop gewerkt aan een succesvolle migratie .”
Een nieuw kwartaal vol nieuwe vernieuwingen van Azure. Azure heeft zeker niet stil gestaan! Er is ook geen teken dat het rustiger wordt. Kijk samen me onze expert naar wat Azure het afgelopen kwartaal heeft gedaan en wat er nog komen gaat!
Een nieuw jaar vol nieuwe vernieuwingen van Azure. Azure heeft zeker niet stil gestaan! Er is ook geen teken dat het rustiger wordt. Kijk samen me onze expert naar een terugblik van 2022 én vooruitblik van 2023!
Ontdek met deze checklist welke technische keuzes van essentieel belang zijn bij een migratie naar Microsoft Azure. Je ontvangt in één compacte versie de technische handvatten om jouw applicatie veilig en vertrouwt te migreren.
Overweeg je om gebruik te maken van public clouddiensten, maar wil je liever niet stoppen met je private cloud? Dan kan een hybrid cloud uitkomst bieden. Twee belangrijke redenen waarom een hybrid cloud populariteit wint zijn schaalbaarheid en flexibiliteit.
Waarom veel softwarebedrijven van IaaS naar PaaS overstappen
Met een PaaS omgeving hoef je geen tijd meer te besteden aan het instellen en onderhouden van servers, authenticatie, patches, of upgrades van het besturingssysteem en de middleware. Wanneer stap jij over?
Wat voor SQL database oplossing kan ik het beste gebruiken?
Een vraag die vaak gesteld wordt bij het transformeren van een applicatie naar Azure is; wat voor SQL database oplossing kan ik het beste gebruiken? In dit artikel gaan we je meer vertellen over de mogelijke opties, waar je op moet letten bij deze keuze en welke database wij aanraden voor welke situatie.
Stroomlijn jouw Azure cloudmigratie met een Azure Landing Zone. Zo creeer je een framework waarbinnen je organisatie efficient en gecontroleerd een cloudmigratie kan uitvoeren.
In deze workshop staat het (fictieve) softwarebedrijf Cloud Adventures centraal. Je volgt hen in hun reis naar en op de Azure Cloud. Alle bijbehorende uitdagingen en pijnpunten komen aan bod en we laten je op een heldere manier zien hoe je deze problemen kunt tackelen. Haal het maximale uit de workshop en maak van de gelegenheid gebruik om al je vragen te stellen aan onze Azure Experts.
Cloud Adoption Framework: voor een succesvolle migratie naar de Cloud
Om in Azure te werken heeft Microsoft het Cloud Adoption Framework opgesteld. Dit framework biedt richtlijnen voor een succesvolle migratie naar de Cloud.
Welke Azure Cloud Services zijn interessant voor mijn organisatie?
Azure heeft voor iedere vorm van cloud computing een aanbod aan services als aanvulling op je omgeving. Er zijn tal van Azure Cloud Services waaruit je kunt kiezen. De belangrijkste en interessantste services voor je organisatie behandelen we in dit artikel.
App en platform modernisatie: Rehost, Refactor, Rearchitect, Rebuild & Replace
Als je hebt besloten om de overstap te maken naar Azure, begint het proces van cloudmigratie. Verschillende ingewikkelde beslissingen spelen een rol in dit proces. Het is daarom aan te raden om volgens een zorgvuldig opgestelde migratiestrategie aan de slag te gaan.
Bekijk hier hoe wij waarde bieden aan onze softwarepartners
Om Independent Software Vendors (ISVs) te helpen met de versnelling van de applicatieontwikkeling en het vergroten van business kansen heeft Intercept de oplossing ’Cloudify voor ISVs’ bedacht.
Managed Service providers, hoe managen jullie je klanten?
Als Azure Expert MSP, heeft Intercept de eer om in preview deze nieuwe technologie te testen en in gebruik te nemen. We zijn dan ook erg blij om onze ervaringen te delen.
Checklist deel 2: bepaal jouw architectuur voordat je migreert naar Azure
Als tweede in een reeks van artikelen gaan we kijken naar architecturen en waarom het belangrijk is om hiernaar te kijken. 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.
Checklist deel 1: bepaal jouw strategie voordat je migreert naar Azure
Voordat je aan jouw Azure reis begint, is het belangrijk om een stap terug te doen en na te denken over wat je daadwerkelijk wilt bereiken. De eerste stap naar het succesvol moderniseren van jouw oplossing is het bepalen van je strategie, zowel op korte als lange termijn.
Independent Software Vendors (ISVs) hebben met elkaar gemeen dat ze ooit begonnen zijn met een briljant idee, een gat in de markt zagen, een applicatie ontwikkelden en vervolgens in business kwamen. De hele softwarebranche is echter sinds de komst van cloud compleet wakker geschud en overhoop gehaald.
De private cloud bestaat niet. Het is achterhaald en onnodig duur.
Lang werd investeren in private cloud oplossingen gezien als een verstandige keuze. Ondernemers dachten op die manier kennis en kunde in huis te halen, want ze controleerden het volledige systeem. Niets is minder waar.
Vier valkuilen van het migreren naar de public cloud
Wanneer je migreert naar de public cloud met jouw applicatie, data en workloads, wil je dat alles goed gaat. In dit artikel lees je de vier valkuilen die wij tegenkomen bij het migreren naar de public cloud Azure.
