Delen via

Architectuurbenaderingen voor besturingsvlakken in multitenant-oplossingen

  • Artikel

Besturingsvlakken zijn een belangrijk onderdeel van SaaS-oplossingen (Software as a Service) en multitenant-oplossingen, met name om een oplossing op schaal te beheren. Normaal gesproken zijn er twee hoofdonderdelen waaruit een besturingsvlak bestaat:

  • De tenantcatalogus, waarin belangrijke informatie over uw tenants wordt opgeslagen, zoals:
    • Tenantconfiguratie.
    • SKU's die zijn geïmplementeerd voor tenantbronnen.
    • Aan welke implementaties de tenants worden toegewezen.
  • Processen voor het beheren van wijzigingen in de omgeving, die worden geactiveerd door levenscyclusgebeurtenissen van de tenant. Bijvoorbeeld tenant onboarding, tenant offboarding en eventueel vereist regelmatig onderhoud.

Een besturingsvlak is zelf een toepassing. U moet zorgvuldig nadenken over uw besturingsvlak en deze ontwerpen met dezelfde rigor en zorg dat u met elk ander deel van uw oplossing gebruikt. Zie Overwegingen voor multitenant besturingsvlakken voor meer informatie over wat een besturingsvlak is, waarom u het moet gebruiken en overwegingen voor het ontwerpen van een besturingsvlak.

In dit artikel worden enkele benaderingen beschreven die u kunt overwegen voor het ontwerpen en maken van een besturingsvlak. De lijst met methoden die hier worden beschreven, is niet volledig. Hoewel de benaderingen allemaal geldig zijn, zijn er andere geldige architecturen.

Benaderingen en patronen om rekening mee te houden

De volgende tabel bevat een overzicht van de verschillen tussen een aantal benaderingen die u voor een besturingsvlak kunt overwegen. Handmatige, weinig code en aangepaste benaderingen worden vergeleken.

Overweging Handmatig Weinig code Aanpassen
Operationele overhead Hoog Laag/gemiddeld Beperkt
Frequentie van levenscyclus-gebeurtenissen die de aanpak geschikt is voor Zeldzaam Af en toe Vaak
Tijd en complexiteit om te implementeren Beperkt Gemiddeld Hoog
Onderhoudsverantwoordelijkheden voor besturingsvlak Beperkt Gemiddeld Hoog
Testbaarheid Beperkt Gemiddeld Hoog
Risico op inconsistenties Hoog Gemiddeld laag Beperkt

Handmatige processen

Het is niet altijd essentieel om een volledig geautomatiseerd besturingsvlak te bouwen, vooral wanneer u begint en slechts een klein aantal tenants hebt.

Mogelijk houdt u uw tenantcatalogus centraal op een centrale locatie, zoals in een Excel-werkmap of een JSON-bestand dat is opgeslagen op een locatie waartoe uw team toegang heeft. Ongeacht de indeling is het een goed idee om de informatie op een gestructureerde manier op te slaan, zodat u eenvoudig programmatisch met de gegevens kunt werken.

Notitie

Een handmatig besturingsvlak is een uitstekende manier om aan de slag te gaan met het beheren van uw multitenant-toepassing, maar het is alleen geschikt voor een klein aantal tenants (minder dan 5-10). De administratieve overhead en het risico op inconsistenties nemen toe met elke tenant die u handmatig onboardt. U moet deze benadering alleen gebruiken als u slechts een paar tenants hebt en u geen geautomatiseerde of selfservice-onboarding nodig hebt.

Voor processen zoals tenant-onboarding en onderhoudsactiviteiten:

  • Maak waar mogelijk scripts of geautomatiseerde pijplijnen, zelfs als u ze handmatig uitvoert. Door scripts of pijplijnen te gebruiken, zorgt u ervoor dat de stappen consistent worden uitgevoerd voor elke tenant.
  • Documenteer het proces grondig en expliciet voor taken die u in eerste instantie niet kunt uitvoeren. Documenteer hoe en waarom. Als iemand de taak in de toekomst automatiseert, moeten ze een goed begrip hebben van beide.

In het volgende diagram ziet u een manier om handmatige processen te gebruiken voor een eerste besturingsvlak:

Diagram met een manier om scripts en andere handmatige processen voor een besturingsvlak te gebruiken.

Een Visio-bestand van deze architectuur downloaden.

Voordelen van een handmatige benadering

  • Lichtgewicht: Documentatie, scripts en pijplijnen zijn eenvoudig te ontwikkelen en te wijzigen. Dit maakt ze geschikt wanneer u uw processen uitzoekt, omdat u ze snel kunt herhalen en ontwikkelen.
  • Lage kosten: het onderhouden en uitvoeren van een handmatige benadering is goedkoop.
  • Valideert uw proces: Zelfs als u uiteindelijk van plan bent om een meer geautomatiseerde benadering te gebruiken, is het een goede manier om uw onderhoudsstrategie te valideren voordat u tijd investeert in het ontwikkelen van robuustere automatisering.

Nadelen van een handmatige benadering

  • Gebrek aan controle: Deze aanpak is afhankelijk van iedereen die het juiste doet. Iemand kan afwijken van de voorgeschreven processen, hetzij per ongeluk of opzettelijk. Elke variatie in het proces verhoogt het risico op inconsistentie in uw omgeving, waardoor doorlopend beheer veel moeilijker wordt.
  • Uitdagingen met betrekking tot toegangsbeheer: Wanneer u deze aanpak gebruikt, moet u doorgaans een breed bereik verlenen aan iedereen die uw oplossing beheert, waardoor het moeilijk is om de aanbevolen procedures voor toegangssegmentatie te volgen.
  • Schaalbaarheid: het werk dat nodig is om handmatige processen uit te voeren, wordt geschaald met het aantal tenants dat u moet beheren.
  • Testbaarheid: handmatige processen zijn moeilijk te valideren en te testen.

Wanneer u kunt overwegen om van een handmatige benadering af te stappen

  • Wanneer uw team niet kan bijhouden hoeveel werk ze moeten doen om de toepassing te onderhouden. Wanneer uw aantal tenants bijvoorbeeld buiten een kritiek punt wordt geschaald, wat voor de meeste teams tussen 5 en 10 tenants ligt.
  • Wanneer u verwacht dat tenantgroei verder gaat dan een kritiek aantal tenants en u moet zich voorbereiden op het werk dat betrokken is bij het beheren van dat aantal tenants.
  • Wanneer u het risico op inconsistenties wilt beperken. U kunt bijvoorbeeld enkele fouten observeren omdat iemand de processen niet correct volgt of omdat er te veel dubbelzinnigheid is in de processen. Het risico op inconsistentie neemt doorgaans toe naarmate er handmatig meer tenants worden geïmplementeerd en naarmate uw team groeit.

Besturingsvlak met weinig code

Een besturingsvlak met weinig code of geen code is gebouwd op een platform dat is ontworpen om bedrijfsprocessen te automatiseren en informatie bij te houden. Er zijn veel platforms waarmee u deze taken kunt uitvoeren zonder aangepaste code te schrijven.

Microsoft Power Platform is een voorbeeld van een van deze platforms. Als u Power Platform gebruikt, kunt u uw tenantcatalogus bewaren in Dynamics 365, Dataverse of Microsoft 365. U kunt ook overwegen om dezelfde tenantcatalogus te bewaren die u voor uw handmatige processen gebruikt, als u zich niet volledig wilt doorvoeren om alles eerst te automatiseren.

Voor onboarding en onderhoud van tenants kunt u Power Automate gebruiken om werkstromen uit te voeren die tenantbeheer uitvoeren, tenants configureren, pijplijnen of API-aanroepen activeren, enzovoort. U kunt Power Automate gebruiken om te kijken naar wijzigingen in uw tenantcatalogus als de gegevens ergens toegankelijk zijn voor Power Automate. Als u een handmatige tenantcatalogus gebruikt, kunnen Power Automate-werkstromen ook handmatig worden geactiveerd. U kunt besluiten om handmatige goedkeuringsstappen in uw werkstromen op te nemen als u iemand van uw team nodig hebt om iets te verifiëren of aanvullende stappen uit te voeren die niet volledig kunnen worden geautomatiseerd.

Met deze aanpak kunt u ook selfservice-registratie bieden aan uw klanten door uw webtoepassing rechtstreeks records toe te voegen aan uw tenantcatalogus zonder menselijke tussenkomst.

In het volgende diagram ziet u hoe u een besturingsvlak met selfserviceregistratie kunt maken met behulp van het Microsoft Power Platform:

Diagram met één manier om Power Automate en Dataverse te gebruiken als een besturingsvlak met weinig code.

Een Visio-bestand van deze architectuur downloaden.

Voordelen van een benadering met weinig code

  • Lichtgewicht: Het is vaak snel en goedkoop om een set werkstromen met weinig code te maken en deze te verbinden met de omringende systemen.
  • Maakt gebruik van platformhulpprogramma's: u kunt systeemeigen platformfuncties gebruiken om gegevens op te slaan, beheerportals te maken die uw team kan gebruiken en de werkstromen te bewaken terwijl ze worden uitgevoerd. Door systeemeigen platformfuncties te gebruiken, vermijdt u het bouwen van veel onderdelen zelf.
  • Aanpasbaar: Als u meer aanpassingen nodig hebt, kunt u uw werkstromen doorgaans uitbreiden met aangepaste code en processen. U kunt Power Automate bijvoorbeeld gebruiken om een implementatiewerkstroom in GitHub Actions te activeren, of u kunt Azure Functions aanroepen om uw eigen code uit te voeren. Dit helpt ook om een geleidelijke implementatie te vergemakkelijken.
  • Lage overhead: services met weinig code worden doorgaans volledig beheerd, dus u hoeft de infrastructuur niet te beheren.

Nadelen van een benadering met weinig code

  • Vereiste expertise: Als u platformen met weinig code wilt gebruiken om processen te maken en deze platformen effectief te kunnen gebruiken, hebt u doorgaans eigen kennis nodig. Veel organisaties gebruiken deze hulpprogramma's al, dus uw team beschikt mogelijk al over de vereiste expertise, maar dit kan niet. U moet overwegen of u uw team moet trainen om deze platforms effectief te kunnen gebruiken.
  • Beheer: het kan lastig zijn om het beheer van grote hoeveelheden configuratie met weinig code af te handelen.
  • Testbaarheid: Overweeg hoe u wijzigingen in uw besturingsvlak kunt testen en promoten. In een beheerd platform is het maken van een typisch DevOps-proces voor het testen en promoten van wijzigingen moeilijker, omdat wijzigingen normaal gesproken worden aangebracht via configuratie, niet via code.
  • Ontwerp: Denk goed na over het voldoen aan niet-functionele vereisten, zoals beveiliging en betrouwbaarheid. Deze vereisten worden vaak voor u beheerd op een platform met weinig code.

Wanneer u kunt overwegen om weg te gaan van een benadering met weinig code

  • Uiteindelijk kunnen uw vereisten zo complex worden dat u ze niet gevoelig kunt opnemen in een oplossing met weinig code. Wanneer u beperkingen voor hulpprogramma's moet omzeilen om aan uw behoeften te voldoen, is het waarschijnlijk zinvol om weg te gaan van een beheerde oplossing en naar een aangepast besturingsvlak.

Aangepast besturingsvlak

U kunt ook uw eigen volledig aangepaste besturingsvlak maken. Deze optie biedt de meeste flexibiliteit en kracht, maar vereist ook het meeste werk. De tenantcatalogus wordt meestal opgeslagen in een database. In dit geval werkt u niet rechtstreeks met de catalogus, maar beheert u deze via een beheerinterface. Dit kan een aangepaste toepassing zijn of een systeem zoals de CRM-toepassing (Customer Relationship Management) van uw organisatie.

Doorgaans maakt u een set onderdelen van het besturingsvlak die zijn ontworpen rond al uw tenantbeheerfuncties. Deze onderdelen kunnen een beheerportal of andere gebruikersinterface, een API en achtergrondverwerkingsonderdelen bevatten. Als u bijvoorbeeld code of infrastructuur moet implementeren wanneer er levenscyclus-gebeurtenissen voor de tenant plaatsvinden, kunnen implementatiepijplijnen ook uw besturingsvlak vormen.

Zorg ervoor dat langdurige verwerking gebruikmaakt van de juiste hulpprogramma's. U kunt bijvoorbeeld Durable Functions of Azure Logic Apps gebruiken voor onderdelen die onboarding of implementaties van tenants organiseren, of voor onderdelen die moeten communiceren met externe systemen.

Net als bij de benadering met weinig code kunt u met deze benadering selfservice-registratie bieden aan uw klanten door uw webtoepassing toe te staan records rechtstreeks toe te voegen aan uw tenantcatalogus zonder menselijke tussenkomst.

In het volgende diagram ziet u een manier om een eenvoudig aangepast besturingsvlak te maken dat selfserviceregistratie biedt:

Diagram dat een besturingsvlak illustreert dat is gemaakt met Durable Functions, een SQL-database en een servicebus.

Een Visio-bestand van deze architectuur downloaden.

Voordelen van een aangepaste benadering

  • Volledige flexibiliteit en aanpasbaarheid: u hebt volledige controle over wat uw besturingsvlak doet en kan dit wijzigen als uw vereisten veranderen.
  • Testbaarheid: U kunt een standaard SDLC (Software Development Lifecycle) gebruiken voor uw besturingsvlaktoepassing en normale benaderingen implementeren voor testen en implementaties, net zoals voor uw belangrijkste toepassingen.

Nadelen van een aangepaste benadering

  • Onderhoudsverantwoordelijkheden: Voor deze aanpak is meer onderhoudsoverhead vereist, omdat u alles zelf moet maken. Een besturingsvlak is net zo belangrijk als elk ander onderdeel van uw toepassing. U moet goed zorgen voor het ontwikkelen, testen en bedienen van uw besturingsvlak om ervoor te zorgen dat het betrouwbaar en veilig is.

Hybride benaderingen

U kunt ook overwegen een hybride benadering te gebruiken. U kunt een combinatie van handmatige en geautomatiseerde systemen gebruiken, of u kunt een beheerd platform zoals Microsoft Power Platform gebruiken en deze uitbreiden met aangepaste toepassingen. Overweeg om een hybride benadering te implementeren als u de aanpasbaarheid van een aangepast besturingsvlak nodig hebt, maar niet noodzakelijkerwijs een volledig aangepast systeem wilt bouwen en onderhouden. Houd er rekening mee dat uw geautomatiseerde aanpassingen aan uw handmatige processen of uw beheerde platform op een bepaald moment zo complex kunnen worden als een volledig aangepast systeem. Het punt is voor elke organisatie anders, maar als uw hybride benadering lastig te onderhouden is, kunt u overwegen om over te stappen op een volledig aangepast systeem.

Geleidelijke implementatie

Zelfs als u weet dat u uiteindelijk uw besturingsvlak wilt automatiseren, hoeft u niet per se met die benadering te beginnen. Een algemene benadering tijdens de eerste fasen van het maken van uw toepassing is om te beginnen met een handmatig besturingsvlak. Naarmate uw toepassing vordert en meer tenants onboardt, moet u knelpunten gaan identificeren en deze zo nodig automatiseren, waarbij u overstapt op een hybride benadering. Naarmate u meer automatiseert, hebt u mogelijk uiteindelijk een volledig geautomatiseerd besturingsvlak.

Antipatroon om te voorkomen

  • Afhankelijk van handmatige processen te lang. Hoewel het redelijk is om handmatige processen te gebruiken wanneer u begint of wanneer u een laag aantal tenants hebt en redelijk licht beheer nodig hebt, moet u plannen hoe u schaalt naar een geautomatiseerde oplossing wanneer u groeit. Als u extra teamleden moet inhuren om de vraag van uw handmatige processen bij te houden, is dat een goed teken dat u moet beginnen met het automatiseren van onderdelen van uw besturingsvlak.
  • Ongepaste hulpprogramma's gebruiken voor langlopende werkstromen. Vermijd bijvoorbeeld het gebruik van standaard Azure-functies, synchrone API-aanroepen of andere hulpprogramma's die een uitvoeringstijdslimiet hebben om langlopende bewerkingen uit te voeren, zoals Azure Resource Manager-implementaties of indelingen met meerdere stappen. Gebruik in plaats daarvan hulpprogramma's zoals Azure Logic Apps, Durable Functions en andere hulpprogramma's waarmee langlopende werkstromen of reeksen bewerkingen kunnen worden uitgevoerd. Zie de prestaties en betrouwbaarheid van Azure Functions en het Asynchrone patroon Request-Reply voor meer informatie.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Andere Inzenders:

Volgende stappen