ISV: een multi-tenant analyseplatform als abonnementsproduct

Een gedeeld multi-tenant platform op Fabric waarbij tenantisolatie onder de modellaag zit: per klant een eigen workspace en lakehouse, of waar dat niet haalbaar is, OneLake Security tot op tabel- en rijniveau. Echte ML-modellen draaien op de gold-laag via Spark-notebooks met MLflow voor modelregistratie; AI Functions classificeert reviews en tickets als extra signaal. Gedeelde modeldefinities worden via een service principal beheerd en per klant uitgerold, zodat consultants niet voor elke klant vanaf nul beginnen.

Het businessmodel vereiste herhaalbaarheid: elke nieuwe klant moet sneller op te starten zijn dan de vorige, anders schaalt het abonnement niet. Isolatie onder de modellaag in plaats van alleen rapport-RLS was een bewuste keuze, model-RLS is een filter binnen een gedeeld model, geen datamuur, en voor een extern platform dat meerdere klanten bedient was dat onderscheid niet onderhandelbaar. Open Delta-tabellen voorkomen bovendien lock-in richting één klant-specifieke stack.

Voor elke klant een volledig gescheiden Azure-omgeving opzetten gaf de sterkste isolatie, maar maakte het product duurder dan de doelgroep (mid-market) kon dragen en verhoogde de operationele last per klant lineair. Alles in één gedeeld model met alleen rapport-RLS regelen was goedkoper, maar zou bij een datalek van klant A naar klant B het product onverkoopbaar maken.

• Gedeelde capaciteit met bewaking van CU-verbruik per tenant is nodig om te voorkomen dat één zware klant de ervaring van anderen verslechtert.
• De grens tussen "in Fabric" en "in Azure Machine Learning" moest bewust bepaald worden op basis van MLOps-volwassenheid per usecase, niet standaard voor alles hetzelfde platform kiezen.
• Harde tenantscheiding kost meer beheer dan één groot gedeeld model, maar is de voorwaarde voor een verkoopbaar product.

Microsoft Fabric (workspaces, Lakehouse, OneLake Security), Data Science met MLflow, AI Functions, Copilot in Fabric voor consultants, Git-integratie en Deployment Pipelines.

• Isoleer tenants onder de modellaag als standaard, niet als uitzondering voor "belangrijke" klanten.
• Beheer gedeelde modeldefinities centraal via een service principal, zodat een modelupdate niet per klant handmatig hoeft te worden herhaald.
• Scheid ML-promotie (MLflow-registry) van BI-promotie (Deployment Pipelines) vanaf de eerste klant, niet pas als het pijn gaat doen bij de tiende.

De grootste versnelling in onboarding kwam niet van automatisering van de techniek, maar van het vastleggen van één herbruikbare tenant-blauwdruk (workspace-structuur, beveiligingsrollen, modeldefinities) die per klant alleen nog geconfigureerd hoefde te worden. Een valkuil die het team pas laat zag: zonder CU-bewaking per tenant merkte niemand dat één klant met een zware batchjob structureel capaciteit van de andere klanten opsoupeerde, tot die andere klanten gingen klagen over trage dashboards.