Tip van Marijn: mijn ervaring leert: denk eerst goed na voordat je iets in Azure Cloud in elkaar zet. Hoe verleidelijk het ook is om meteen te beginnen met Azure, het kan later hard tegen je werken en onnodig duizenden euro’s per maand kosten. Think before you act, met als doel dat je infrastructuur passend is én dat je geen onnodige cloud kosten hebt.
Azure architectuur is als een huis bouwen; je begint niet bij de zolder 🏠
Net als bij andere Public Cloud platformen wordt het je in Azure bewust zo makkelijk mogelijk gemaakt om te starten met bouwen en resources uit te rollen. Maar weet je wát je aan het bouwen bent? Of waar je aan het bouwen bent? Het inrichten van infrastructuur op Azure kun je als het bouwen van een huis zien. Daar begin je ook niet met het bouwen van de zolder zonder eerst over de fundering te hebben nagedacht. Het liefst ontwerp je een architectuur voor de infrastructuur op Azure die direct passend is bij je applicatie voor de komende tijd. Een infrastructuur waar je ook onnodige cloud kosten mee kunt voorkomen.
Een eis uit de business waardoor cloud kosten gigantisch opliepen
Een voorbeeld om dat te illustreren: op de tekentafel kwam de wens naar voren om volledig gescheiden netwerken voor alle omgevingen op te zetten, waardoor een design met uitsluitend private subnets werd geïmplementeerd. Op het moment dat de workloads naar productie gingen, bleek dat wekelijks alle data uit de databases van de productie-omgeving naar alle andere omgevingen moest worden gesynchroniseerd. Omdat het separate netwerken waren, was dit alleen mogelijk via een NAT gateway. Elke keer als je daar data doorheen stuurt, betaal je een paar cent per GB. Het bleek als snel dat de kosten voor data-synchronisatie gigantisch opliepen. Dusdanig dat het hele netwerkplan in de prullenbak kon en de omgevingen van de grond af opnieuw moest worden opgebouwd.
Op zo’n moment kan een eis vanuit de business later hard tegen je werken. Zeker voor het MKB kunnen dit soort onverwachte (en voorkombare) kosten door fouten in de fundering deal breakers worden om wel of niet op Azure (of een andere Public Cloud) over te gaan.
Think before you act
Hoe verleidelijk het ook is om gelijk in Azure te gaan bouwen, doe het niet. Ook niet in een zandbak-achtige omgeving. Als je het nog nooit zelf gedaan hebt, is je beste optie een specialist aan te haken. In de praktijk merk ik dat als iemand het nog nooit heeft gedaan, het helemaal zelf doen vrijwel nooit lukt.
Je een-na-beste optie: begin met het Cloud Adoption Framework. Probeer alles te snappen wat er staat, wat je doet en wat je nodig heb. Bedenk de juiste elementen voor je business en doeleinden; de eisen van een fintech webapplicatie zijn anders dan die van een webshop gericht op de Benelux of die van een digital agency.
Veelgemaakte architectuurfouten in de cloud
📦 Lift-and-shift en daarbij VM’s as-is overzetten naar de cloud
Voor de korte termijn kan dit werkbaar zijn als tijdelijke oplossing om cloud migratie te versnellen. Dit is op de lange termijn duurder en heeft een minder hoge performance. Ook houdt deze oplossing geen rekening met de mogelijkheden van de cloud, zoals schaalbaarheid, wendbaarheid en managed services. Een migratie naar containers of zelfs serverless kan meer opleveren in performance en kostenbeheersing.
📦 Lift-rearchitecture-and-shift als optimaal zien
Het is al een beter idee dan lift-and-shift; bij reachitecture zet je functionaliteiten (bv een MySQL database) net wat anders in. Bij een reachitecture geldt: je bent pas begonnen en je bent nog lang niet klaar. Het kost veel tijd om er goed in te duiken en de kans op onnodige hoge kosten op de lange termijn is heel groot.
⚡ Kubernetes gebruiken voor kleine workloads
Het lijkt effectief om een trend te volgen, maar Kubernetes levert (zeker voor kleine workloads) een behoorlijke overhead. Eerder gaf mijn collega Raphaël 3 andere manieren mee hoe je kleine workloads in containers op Azure kunt draaien.
🌐 De goedkoopste regio van een Public Cloud kiezen
De goedkoopste regio werkt vaak niet. Enerzijds omdat wet- en regelgeving je aan een regio voor data-opslag kunnen binden. Anderszijds omdat de goedkoopste regio niet altijd de beste latency biedt. osten zijn een belangrijke factor voor de keuze voor de cloud, alleen geldt ook: voor een optimaal presterende architectuur is dichter bij je klanten beter.
Continuous improvement van je Azure infrastructuur
Net als je eigen huis, is een infrastructuur nooit ‘af’, maar altijd in ontwikkeling. Eisen van je klanten veranderen, de markt verandert, je ontwikkelt je applicatie door. Een meerjarenplan voor de architectuur van je infrastructuur is dan ook niet te doen. Over 4 jaar is je huidige omgeving in Azure oud, mis je nieuwe functies die Azure in die tijd ontwikkeld heeft en zijn bepaalde resources deprecated geraakt.
Continuous improvement kun je bereiken met een aantal elementen, zoals:
- Periodieke architecture review
- Stel een verloopdatum op beslissingen in
- Weet wat er draait: houd configuration drift bij
🔎 Periodieke architecture review
Alle beslissingen voor het ontwerp van je Azure achitectuur kunnen in de toekomst achterhaald zijn. Plan periodieke architecture reviews in, samen met je managed cloud partner, of haal hiervoor het Azure Well-Architected Review assessment aan.
De workloads van je applicatie kunnen met de tijd veranderen; resources kunnen anders of slimmer worden ingezet; en nieuwe functies kunnen optimaal benut worden.
Met een periodieke review hou je grip op de continue beweging van je applicatie en infrastructuur. Het helpt je ook bij audits van externe partijen, als ze naar documentatie van je architectuur vragen.
Review op regelmatige basis je architectuur, minstens één keer per jaar, liever vaker. Technologie ontwikkelt zich snel! Borg de review in je bedrijfsprocessen en zet het jaarlijks op de planning.
Vanuit True doen we dit ook voor onze klanten. Soms is dat elke maand een korte check: zijn er functies die deprecated raken en waar je nu aan moet werken om het over een jaar te hebben uitgefaseerd? Soms is dat elk jaar, zijn er nieuwe functies die bij je applicatie passen, en past de architectuur nog bij je veranderende applicatie? Ontwikkelingen houden we continu in de gaten. Omdat we onze klanten, en hun applicaties, goed kennen, weten we soms meteen of een deprecation een probleem gaat vormen, en of een nieuwe feature een goed idee is.
💡 Een voorbeeld van nieuwe functies die beter passen, vind je in de True Story van Unc Inc x HVC. Voor hun klant HVC was twee jaar geleden een single MySQL database op Azure de beste oplossing. We merkten samen echter dat de connectie naar de database langer duurde dan eerder. En de single database heeft een end-of-life eind 2024. Reden voor een nieuwe oplossing: een flexible MySQL database.
Hoe vaak een architecture review moet, is afhankelijk van je bedrijf en type applicatie. Check het echter wel, net als dat je elk jaar naar je energiecontract of zorgverzekering kijkt of je nog goed zit.
🗓️ Stel een verloopdatum op beslissingen in
Klopt je keuze over een halfjaar nog steeds? Zou een stuk van het ontwerp ook nog zo zijn als je er nú een beslissing over moet maken? Kom periodiek terug op beslissingen, zoals de separate netwerken voor omgevingen die ik in het begin van dit artikel noemde.
De aanpak: schrijf alle belangrijke beslissingen die je nu maakt, op. Stel er een verloopdatum op, bijvoorbeeld een halfjaar of een jaar. Check op die datum of de beslissing nog steeds klopt. Sta je er nog achter?
🏭 Weet wat er draait: Infrastructure Configuration Drift
Hoe ga je om met configuratie drift, waarbij de infrastructuur in productie (on)bewust anders is dan die gedefinieerd in de infrastructure-as-code? Wijzigingen in de infrastructuur kunnen gebeuren. Denk aan een quick fix tijdens een storing, of toevoegen of aanpassen van resources. Een drift check helpt je om deze configuratie drift te verkleinen.
Voor onze klanten runnen we vanuit True ‘s nachts automatisch een drift check. Daarbij wordt elke afwijking, zonder oordeel, aangegeven. We krijgen dus continu feedback van veranderingen, waarbij we kunnen bepalen om de infrastructure-as-code aan te passen. Daardoor weten we precies dat de infrastructuur zo is hoe wij ‘m willen, en dat deze ook zo in de realiteit op resources draait.
De cloud werkt anders dan on-premises of een VPS
Voor een optimale cloud infrastructuur is het goed om te weten dat de cloud wezenlijk anders werkt dan servers on-premises of een VPS. Tip: begrijp het fundament van Azure, bijvoorbeeld met de learning path Azure Fundamentals (AZ900). Daarna kun je verder gaan met bijvoorbeeld AZ305, Designing Microsoft Azure Infrastructure Solutions. In deze trainingen leer je over alle onderdelen. Investeer tijd om alle nuances goed te leren kennen. Het is de investering waard: door gedegen kennis en vaardigheden kun je veel beter nadenken voor je iets doet in Azure. Zo werk je gedegen aan de fundering in plaats van aan de zolder met een fundering die de zolder niet kan dragen.
Webinar on demand: Getting the cloud right?
Meer weten over deze onderwerpen? In het on demand webinar “Getting the cloud right?” geeft Marijn, samen met gastspreker Bogdan Grozoiu (Azure Cloud Solutions Architect bij Microsoft), jouw volgende stappen op Azure mee.
