Delen via

Architectuurstijlen

  • Artikel

Een architectuurstijl is een familie van architecturen die bepaalde kenmerken delen. Zo is N-tier een bekende architectuurstijl. Sinds korte tijd worden microservice-architecturen steeds populairder. Het is niet zo dat architectuurstijlen het gebruik van specifieke technologieën vereisen, maar sommige technologieën zijn beter geschikt voor bepaalde architecturen. Zo zijn containers bijvoorbeeld perfect voor microservices.

We hebben een reeks architectuurstijlen voor u op een rijtje gezet die vaak worden toegepast in cloudtoepassingen. Het artikel voor elke stijl bevat deze informatie:

  • Een beschrijving en een logisch schema van de stijl.
  • Aanbevelingen voor het gebruiken van deze stijl.
  • Voordelen, aandachtspunten en aanbevolen procedures.
  • Een aanbevolen implementatie met behulp van relevante Azure-services.

Een kort overzicht van de stijlen

In dit gedeelte vindt u een kort overzicht van de architectuurstijlen die we hebben geïdentificeerd, samen met enkele algemene aandachtspunten voor het gebruik ervan. Houd er rekening mee dat de lijst niet volledig is. Raadpleeg voor meer informatie de gekoppelde onderwerpen.

N-tier

Logisch diagram van een architectuurstijl met N-lagen.

N-tier is een traditionele architectuur voor bedrijfstoepassingen. Afhankelijkheden worden beheerd door de toepassing op te delen in lagen die logische functies vertegenwoordigen, zoals presentatie, bedrijfslogica en gegevenstoegang. Een laag kan alleen onderliggende lagen aanroepen. Deze horizontale gelaagdheid kan echter een obstakel zijn. Het kan namelijk lastig zijn om wijzigingen door te voeren in een deel van de toepassing zonder dat de rest van de toepassing hierdoor wordt beïnvloed. Hierdoor zijn regelmatig updates een punt van aandacht en gelden er beperkingen als het gaat om de snelle introductie van nieuwe functies.

N-tier is perfect geschikt voor het migreren van bestaande toepassingen die al een gelaagde architectuur gebruiken. Om die reden wordt N-tier het meest gebruikt in IaaS-oplossingen (Infrastructure as a Service) of toepassingen die een mix van IaaS- en beheerde services gebruiken.

Web-Queue-Worker

Logisch diagram van de architectuurstijl Web-Queue-Worker.

Voor een zuivere PaaS-oplossing kunt u een Web-Queue-Worker-architectuur overwegen. In deze stijl heeft de toepassing een webfront-end die HTTP-aanvragen afhandelt en een werkrol in de back-end die CPU-intensieve taken of langlopende bewerkingen uitvoert. De front-end communiceert met de werkrol via een asynchrone berichtenwachtrij.

Web-queue-worker is geschikt voor relatief eenvoudige domeinen met een aantal resource-intensieve taken. Net zoals N-tier is de architectuur gemakkelijk te begrijpen. Het gebruik van beheerde services vereenvoudigt de implementatie en bewerkingen. Maar in het geval van complexe domeinen kan het lastig zijn om de afhankelijkheden te beheren. De front-end en de werkrol kunnen al snel grote, monolithische onderdelen worden die moeilijk zijn te onderhouden en bij te werken. Net als met N-tier, kan dit de frequentie van updates en innovatie beperken.

Microservices

Logisch diagram van de architectuurstijl van microservices.

Als uw toepassing een complexer domein heeft, kunt u overwegen om over te stappen op een Microservices-architectuur. Een microservicetoepassing bestaat uit een groot aantal kleine, onafhankelijke services. Elke service implementeert één bedrijfsfunctie. Services zijn los gekoppeld en communiceren via API-contracten.

Elke service kan worden gebouwd door een klein ontwikkelingsteam. Afzonderlijke services kunnen worden geïmplementeerd zonder veel coördinatie tussen de teams, wat regelmatige updates eenvoudiger maakt. Een microservice-architectuur is complexer om te bouwen en te beheren dan N-tier of Web-queue-worker. De architectuur vereist een ervaren ontwikkelings- en DevOps cultuur. Maar bij juist gebruik kan deze stijl bijdragen aan een hogere release-snelheid, snellere innovatie en een tolerantere architectuur.

Gebeurtenisafhankelijke architectuur

Diagram van een gebeurtenisgestuurde architectuurstijl.

Gebeurtenisafhankelijke architecturen gebruiken een model van publiceren-abonneren (pub-sub) waarbij producenten gebeurtenissen publiceren en consumenten zich hierop abonneren. De producenten staan los van de consumenten en consumenten zijn onafhankelijk van elkaar.

U kunt een gebeurtenisafhankelijke architectuur gebruiken voor toepassingen die grote hoeveelheden gegevens opnemen en verwerken met een zeer lage latentie, zoals IoT-oplossingen. De stijl is ook handig wanneer verschillende subsystemen verschillende soorten verwerking moeten uitvoeren op dezelfde gebeurtenisgegevens.

Big Data, Big Compute

Logisch diagram van een architectuurstijl voor big data.

Big Data en Big Compute zijn gespecialiseerde architectuurstijlen voor workloads die voldoen aan bepaalde specifieke profielen. De stijl Big Data verdeelt een zeer grote gegevensset in chunks voor analyse en rapportage, waarbij voor de volledige set parallelle verwerking wordt toegepast. De essentie van Big Compute, ook wel HPC (High-Performance Computing) genoemd, is dat er parallelle berekeningen worden uitgevoerd op een groot aantal (duizenden) kernen. Voorbeelden van domeinen zijn simulaties, modellering en 3D-rendering.

Architectuurstijlen als beperkende factor

Een architectuurstijl legt beperkingen op aan het ontwerp, waaronder de set met elementen die kunnen worden weergegeven en de toegestane relaties tussen deze elementen. Beperkingen bepalen de 'vorm' van een architectuur door het universum aan keuzemogelijkheden te beperken. Wanneer een architectuur voldoet aan de beperkingen van een bepaalde stijl, worden bepaalde gewenste eigenschappen zichtbaar.

Dit zijn bijvoorbeeld beperkingen in microservices:

  • Een service vertegenwoordigt een enkele verantwoordelijkheid.
  • Elke service is afhankelijk van de andere services.
  • Gegevens zijn exclusief voor de service die er eigenaar van is. Services delen geen gegevens.

Door een systeem te bouwen dat voldoet aan deze beperkingen, ontstaat er een systeem waarin services onafhankelijk van elkaar kunnen worden geïmplementeerd, fouten worden geïsoleerd, regelmatige updates mogelijk zijn en gemakkelijk nieuwe technologieën kunnen worden geïntroduceerd in de toepassing.

Elke architectuurstijl heeft zijn eigen compromissen. Zorg er daarom voor dat u de onderliggende principes en beperkingen van die stijl begrijpt voordat u een architectuurstijl kiest. Anders zit u straks opgescheept met een ontwerp dat weliswaar in grote lijnen voldoet aan de stijl, maar dat niet het volle potentieel van die stijl benut. U moet meer aandacht besteden aan de reden waarom u een bepaalde architectuurstijl kiest dan hoe u deze implementeert. Het is ook belangrijk om pragmatisch te zijn. Soms is het beter om een beperking te versoepelen in plaats van koste wat kost de zuiverheid van de architectuur na te streven.

Het kiezen van een geschikte architectuurstijl moet in het ideale geval worden uitgevoerd met een consensus van belanghebbenden voor geïnformeerde workloads. Het workloadteam moet eerst de aard van het probleem identificeren dat ze proberen op te lossen. Vervolgens moeten ze zakelijke stuurprogramma's en bijbehorende architectuurkenmerken (ook wel niet-functionele vereisten genoemd) identificeren en ze vervolgens prioriteit geven. Als ze bijvoorbeeld kortere markttijd nodig hebben, kunnen ze prioriteit geven aan onderhoudbaarheid, testbaarheid en betrouwbaar door snelle implementatiemogelijkheden. Of als het workloadteam een beperkt budget heeft, kunnen ze prioriteit geven aan haalbaarheid en eenvoud. Het kiezen en onderhouden van een architectuurstijl is geen eenmalige activiteit, maar een continue benadering: de architectuur moet continu worden gemeten, gevalideerd en verfijnd in de loop van de tijd. Er zijn meestal aanzienlijke kosten verbonden aan het veranderen van architectuurstijl, dus meer inspanning vooraf kan worden gerechtvaardigd voor de efficiëntie en risicobeperking van het team op lange termijn.

In de volgende tabel ziet u hoe elke stijl afhankelijkheden beheert en welke typen domein het meest geschikt zijn voor een stijl.

Architectuurstijl Beheer van afhankelijkheden Domeintype
N-laag Horizontale lagen gescheiden op subnet Traditioneel zakelijk domein. Lage frequentie van updates.
Web-queue-worker Taken in front-end en back-end, losgekoppeld door asynchrone berichtverwerking. Relatief eenvoudig domein met enkele resource-intensieve taken.
Microservices Verticaal (functioneel) opgesplitste services die elkaar via API's aanroepen. Gecompliceerd domein. Regelmatige updates.
Gebeurtenisgestuurde architectuur Producent/consument. Onafhankelijke weergave per subsysteem. IoT- en realtime-systemen.
Big data Een grote gegevensset opdelen in kleine chunks. Parallelle verwerking op lokale gegevenssets. Batchgewijze en realtime-gegevensanalyse. Voorspellende analyse met ML.
Big compute Toewijzing van gegevens aan duizenden kernen. Rekenintensieve domeinen zoals simulatie.

Aandachtspunten en voordelen

Beperkingen bieden ook kansen en dus is het belangrijk om een goede afweging te maken bij het kiezen van een van deze stijlen. Wegen de voordelen van de architectuurstijl op tegen de beperkingen, voor dit subdomein en de afgekaderde context.

Hier volgen enkele punten van aandacht die belangrijk zijn bij het selecteren van een architectuurstijl:

  • Complexiteit. Is de complexiteit van de architectuur noodzakelijk voor uw domein? Of omgekeerd: is de stijl te eenvoudig voor uw domein? In dat geval loopt u het risico te blijven zitten met een 'Big Ball of Mud', omdat de architectuur niet bijdraagt aan een foutloos beheer van afhankelijkheden.

  • Asynchrone berichten en uiteindelijke consistentie. Asynchrone berichten kunnen worden gebruikt voor het loskoppelen van services, en voor het vergroten van de betrouwbaarheid (omdat berichten opnieuw kunnen worden verstuurd) en schaalbaarheid. Dit vormt echter ook uitdagingen in de afhandeling van uiteindelijke consistentie en er bestaat een kans op dubbele berichten.

  • Communicatie tussen services. Als u een toepassing afbreekt in afzonderlijke services, bestaat het risico dat de communicatie tussen de services onaanvaardbaar latentie veroorzaakt of opstoppingen in het netwerk (bijvoorbeeld in een architectuur met microservices).

  • Beheerbaarheid. Hoe moeilijk is het om de toepassing te beheren, bewaken, bij te werken, enzovoort?