WAF-patronen toepassen op echte architecturen

Het toepassen van WAF-patronen op echte architecturen is geen theoretische oefening: je moet elke ontwerpbeslissing aan de hand van de vijf pijlers evalueren en onderbouwde afwegingen maken. Een gebruikelijk startpunt is het architectuurdiagram: volg het pad van een gebruikersverzoek door elk onderdeel en vraag je bij elke stap af wat er gebeurt als dit onderdeel uitvalt, wat het kost en hoe het is beveiligd.

Neem een traditionele monolithische webtoepassing: één VM waarop samen een webserver en database draaien, achter een openbaar IP-adres. Volgens de WAF-pijlers scoort deze op alle vijf slecht: geen redundantie (betrouwbaarheid), database op dezelfde host als de weblaag (beveiliging), altijd ingeschakelde VM ongeacht het verkeer (kosten), geen CI/CD (operationele excellentie) en alleen verticaal schalen (prestatie-efficiëntie).

Om de pijler Betrouwbaarheid aan te pakken, verspreid je de weblaag over meerdere VM's in verschillende beschikbaarheidszones, ondersteun je de database met geografische replicatie naar een secundaire regio en plaats je een Azure Load Balancer ervoor. Hierdoor elimineer je het single point of failure en kan de toepassing een storing van een zone of regio overleven zonder handmatige tussenkomst.

Voor de pijler Beveiliging plaats je de weblaag en database in verschillende subnetten met NSG-regels die alleen toestaan dat de weblaag verbinding maakt met de databasepoort. Sla de verbindingsreeks voor de database op in Azure Key Vault en gebruik een beheerde identiteit in de web-app om deze tijdens runtime op te halen — zo verwijder je hardgecodeerde referenties uit toepassingscode en configuratiebestanden.

Vervang voor Kostenoptimalisatie VM's die altijd actief zijn door een Virtual Machine Scale Set die tijdens daluren afschaalt. Ga voor de database na of een beheerde PaaS-service zoals Azure SQL Database met een geschikte DTU-laag minder kost dan een volledige VM met SQL Server. Koop Reserved Instances voor alle basiscapaciteit die je 12 maanden van tevoren kunt voorspellen.

Verbeter Operationele uitmuntendheid door de volledige infrastructuur te definiëren als Bicep- of ARM-sjablonen die in versiebeheer zijn opgeslagen. Bouw een CI/CD-pijplijn in Azure Pipelines of GitHub Actions die wijzigingen aan de infrastructuur en toepassingscode automatisch implementeert. Voeg implementatiepoorten toe — geautomatiseerde rooktests en handmatige goedkeuring — voordat wijzigingen productie bereiken.

Introduceer voor Prestatiese efficiëntie Azure Cache for Redis vóór de database om vaak gelezen query's te cachen en de belasting van de database te verlagen. Implementeer statische assets (afbeeldingen, CSS, JavaScript) via Azure CDN, zodat ze worden geleverd vanaf edge-knooppunten dicht bij gebruikers wereldwijd. Voer na elke wijziging een laadtest uit om te bevestigen dat de verbeteringen meetbaar zijn.

Elke architectuurwijziging brengt een afweging met zich mee. Een architectuur met meerdere zones verbetert bijvoorbeeld de betrouwbaarheid, maar verhoogt de kosten (twee zones = twee VM's). Redis-caching verbetert de prestaties, maar voegt operationele complexiteit toe (nog een service om te bewaken en te onderhouden). Goede architectuurdocumentatie legt deze afwegingen expliciet vast, zodat toekomstige architecten begrijpen waarom beslissingen zijn genomen.

Probeer niet om in één herontwerp perfectie te bereiken — die aanpak is duur, riskant en traag. Kies in plaats daarvan voor een iteratieve verbeteringscyclus: voer een Well-Architected Review uit, identificeer de drie problemen met de grootste impact, los ze op, meet de verbetering en herhaal dit. Deze aanpak stemt architectuurverbeteringen af op agile oplevering en maakt de voortgang bij elke sprint zichtbaar voor belanghebbenden.

Microsoft publiceert referentiearchitecturen voor veelvoorkomende patronen van workloads in het Azure Architecture Center. Deze omvatten architecturen voor webtoepassingen, microservices op AKS, pijplijnen voor gegevensanalyse en nog veel meer. Elke referentiearchitectuur is al geëvalueerd aan de hand van de WAF-pijlers en bevat opmerkingen over de afwegingen die voor dat specifieke patroon zijn gemaakt.

Gebruik Architecture Decision Records (ADRs) om belangrijke architectuurkeuzes, de context waarin ze zijn gemaakt, de overwogen alternatieven en de gevolgen voor de WAF-pijlers te documenteren. ADR's die naast de codebase in versiebeheer zijn opgeslagen, creëren een controleerbare geschiedenis die nieuwe teamleden helpt begrijpen waarom de architectuur eruitziet zoals deze eruitziet.

In deze les heb je geleerd: WAF-patronen worden toegepast door elke architectuurbeslissing aan de hand van alle vijf pijlers te evalueren; verbeteringen kunnen iteratief worden doorgevoerd door te beginnen met de problemen met de grootste impact; en afwegingen moeten worden gedocumenteerd, zodat toekomstige architecten de achterliggende redenering begrijpen. Hierna bekijken we Azure-SLA's en hoe je samengestelde SLA's voor architecturen met meerdere services berekent.