Azure bouwen die de echte wereld overleeft — met Mike Martin [MVP]

Azure-architectuur ziet er eenvoudig uit zolang alles werkt.De echte test begint wanneer afhankelijkheden uitvallen, regio's onbeschikbaar worden, het verkeer piekt, aannames onjuist blijken, vereisten veranderen en iemand uiteindelijk de ongemakkelijke vraag stelt: waarom hebben we dit destijds zo ontworpen?In deze aflevering van M365.FM gesprekt Mirko Peters met Mike Martin [MVP] over hoe Azure-architectuur eruitziet wanneer die moet standhouden onder echte productieomstandigheden, en niet alleen goed moet lijken in een diagram.Mike brengt decennia ervaring mee op het gebied van ontwikkeling, infrastructuur, architectuur, leiderschap, coaching, training en Microsoft Azure. Een van zijn sterkste observaties is dat veel problemen waar architecten vandaag mee te maken hebben niet echt nieuw zijn. DNS faalt nog steeds. IP-afhankelijkheden zijn nog steeds belangrijk. Kosten worden nog steeds een probleem. Integraties falen nog steeds. Afhankelijkheden verdwijnen nog steeds op het slechtst mogelijke moment.Wat wel is veranderd, is het niveau van complexiteit dat we rond die problemen bouwen.

VAN VISUAL BASIC TOT MODERNE AZURE-ARCHITECTUUR
Mike kijkt terug op bijna drie decennia in IT, begonnen als Visual Basic-ontwikkelaar in de jaren negentig en via gedistribueerde systemen, netwerken, enterprise-software en infrastructuur uiteindelijk bij Azure beland.Zijn kernobservatie is eenvoudig: de sector blijft dezelfde fundamentele problemen oplossen, maar de architecturen eromheen zijn veel complexer geworden.Moderne systemen zijn verschoven van client-server-applicaties naar gedistribueerde architecturen, cloudplatforms, containers, microservices, Kubernetes, hybride omgevingen en nu ook AI-ondersteunde ontwikkeling.Dat biedt enorme mogelijkheden, maar brengt ook een nieuw risico met zich mee: overengineering.Mike stelt dat veel teams vandaag eenvoudige problemen onnodig ingewikkeld maken. Goede architectuur draait vaak niet om het toevoegen van meer technologie, maar om weten wat je juist niet moet toevoegen.

WAT DOET EEN AZURE-ARCHITECT EIGENLIJK?
Voor Mike gaat architectuur niet over het kiezen van zoveel mogelijk Azure-services of het maken van een indrukwekkend diagram.Het gaat erom te begrijpen welke componenten bij elkaar horen, welke vermeden moeten worden, welke noodzakelijk zijn en hoe je iets bouwt dat onderhoudbaar, schaalbaar, veilig en veerkrachtig blijft.Architectuur omvat veel meer dan compute.

• Identiteit
• Netwerken
• Datastromen
• Beveiliging
• Monitoring
• Integratie
• Afhankelijkheden
• Schaalbaarheid
• Operations
• Herstel
• Deployment
• Kosten

Mike daagt ook het idee uit dat cloud-native automatisch betekent: Kubernetes of containers.Azure biedt veel beheerde en native services die problemen kunnen oplossen zonder onnodige operationele overhead.De rol van de architect is het begrijpen van de volledige oplossing en het kiezen van de eenvoudigste architectuur die nog steeds aan de echte vereisten voldoet.

BEGIN MET ZAKELIJKE VEREISTEN, NIET MET AZURE-SERVICES
Een van de belangrijkste lessen in deze aflevering is simpel: begin niet met technologie.Voordat je kiest tussen Azure Kubernetes Service, App Service, Azure Functions, containers, Service Bus of een ander platform, moeten teams eerst begrijpen wat de oplossing daadwerkelijk moet doen.Vragen om te stellen:

• Is het intern of klantgericht?
• Hoeveel gebruikers zullen ervan afhankelijk zijn?
• Moet het wereldwijd schalen?
• Hoe lang mag het onbeschikbaar zijn?
• Hoeveel data kan de business zich laten verliezen?
• Welke compliance-eisen gelden?
• Wat gebeurt er als de applicatie enkele uren verdwijnt?
• Wie wordt erdoor getroffen?
• Welk niveau van operationele ondersteuning is vereist?

Deze vragen leiden rechtstreeks naar concepten als SLA's, SLO's, RTO's en RPO's.Ze bepalen ook of de architectuur single-region, multi-region, active-active, active-passive of iets veel eenvoudigers moet zijn.

RTO EN RPO ZONDER DE BUZZWORDS
RTO en RPO worden vaak besproken als technische afkortingen, maar hun werkelijke betekenis is zakelijk.

• RTO — Recovery Time Objective: hoe snel moet het systeem na een storing weer beschikbaar zijn?
• RPO — Recovery Point Objective: hoeveel dataverlies is acceptabel?

Een systeem dat wordt gebruikt voor niet-kritieke monitoring kan enkele uren downtime of verloren data tolereren.Een systeem dat eerstelijnshulpverleners, financiële processen, e-commerce of kritieke infrastructuur ondersteunt, kan herstel binnen minuten vereisen.Het belangrijke punt is dat deze getallen niet door de architect mogen worden verzonnen.Ze moeten komen uit de werkelijke zakelijke impact van een storing.Zodra die vereisten duidelijk zijn, kunnen ze worden vertaald naar technische ontwerpbeslissingen.

VEERKRACHT IS NIET HETZELFDE ALS HIGH AVAILABILITY
Mike gebruikt een eenvoudige analogie om het verschil tussen beschikbaarheid en veerkracht uit te leggen.Een hoog beschikbaar systeem kan een andere component klaar hebben staan om over te nemen wanneer de primaire uitvalt.Een veerkrachtig systeem is ontworpen om problemen op te vangen, door te blijven werken, zich gecontroleerd te herstellen en terug te keren naar normaal zonder volledig in te storten.Dat onderscheid is belangrijk.Een applicatie kan technisch beschikbaar zijn en toch een slechte ervaring bieden.Ze kan:

• Traag zijn
• Gethrottled worden
• Gedeeltelijk onbeschikbaar zijn
• Afhankelijk zijn van een falend backend
• Getroffen worden door een integratieprobleem
• Onder regionale druk staan

Echte veerkracht vereist dus meer dan uptime.Het vereist een architectuur die kan omgaan met belasting, applicatiefouten, gedeeltelijke storingen, regionale problemen, kapotte afhankelijkheden, operationele incidenten en herstel nadat het incident voorbij is.

AZURE MAAKT JE APPLICATIE NIET AUTOMATISCH VEERKRACHTIG
Een gevaarlijke aanname is dat omdat Azure zelf sterk beschikbaar is, elke applicatie die op Azure draait automatisch die veerkracht erft.Dat is niet zo.Microsoft biedt de services en mogelijkheden die veerkrachtige architecturen mogelijk maken.Klanten moeten nog steeds ontwerpen voor veerkracht.Hier zijn architectuurpatronen van belang:

• Circuit breakers
• Losse koppeling
• Asynchrone verwerking
• Onafhankelijke schaling
• Meerdere availability zones
• Meerdere regio's
• Failover-mechanismen
• Monitoring
• Infrastructure as Code
• Geteste herstelprocedures

Microsoft levert de bouwstenen.De architectuur bepaalt of die bouwstenen daadwerkelijk een veerkrachtig systeem opleveren.

WAAROM ASYNCHRoon ONTWERP BELANGRIJK IS
Een van de sterkste voorbeelden in de aflevering komt uit systemen die te maken hebben met voorspelbare verkeerspieken, zoals overheidsbelastingportalen.Een veelvoorkomend ontwerpprobleem ontstaat wanneer elke actie afhankelijk is van een synchrone backend-operatie.De gebruiker klikt op een knop.De frontend wacht op de backend.De backend wacht op een andere service.Een andere afhankelijkheid vertraagt.Uiteindelijk wordt de hele gebruikerservaring geraakt.Mike legt uit waarom losjes gekoppelde systemen vaak veerkrachtiger zijn.In plaats van de frontend te dwingen op elke backend-operatie te wachten, kunnen applicaties werk in wachtrijen of event-driven systemen plaatsen en componenten taken onafhankelijk laten verwerken.Dat biedt verschillende voordelen:

• Verschillende componenten kunnen onafhankelijk schalen
• Eén service kan uitvallen zonder het hele platform neer te halen
• Backends kunnen werk asynchroon verwerken
• Verkeerspieken worden makkelijker op te vangen
• Gebruikersgerichte componenten worden minder afhankelijk van de timing van de backend
• Storingen zijn makkelijker te isoleren

HET MYTHE VAN 100 PROCENT UPTIME
Een ander belangrijk onderwerp in de discussie is de obsessie met 100 procent beschikbaarheid.Mike is hier heel duidelijk over: 100 procent uptime is geen realistisch architectuurdoel.Een oplossing bestaat meestal uit meerdere services.Elke service heeft zijn eigen SLA.Zodra verschillende afhankelijkheden worden gecombineerd, daalt de