Blog Post

FastTrack for Azure
5 MIN READ

Multitenant Microsoft Fabric architecture

OlgaMolocenco's avatar
OlgaMolocenco
Icon for Microsoft rankMicrosoft
Feb 27, 2024

You have heard this before, Microsoft Fabric is an all-in-one analytics solution that covers everything from data integration to Machine Learning, real-time analytics and Business Intelligence. The big value proposition of Microsoft Fabric is a highly integrated, end-to-end, and easy-to-use service that simplifies your analytics. 


What is not being highlighted enough, is how compelling this platform really is for ISVs and SaaS creators that want to offer analytics to their customers, either as their main product, or as an add-on to the main offering. This blog post will focus on this use-case specifically and will show what are the features in Fabric that simplify analytics for multitenant SaaS applications.
 

Proposed architecture SaaS Analytics on Microsoft Fabric 

 

 

Important! The architecture proposed here is most optimal for an ISV with a B2B model. For ISVs with a B2C model this could be over-architecting. The decision should be taken based on tenant isolation and other technical and business requirements. 

Let’s look at a proposed architecture for our use case. On our left side we have all our incoming data stream. This can be anything, customer owned, or ISV owned data sources, such as Databases, CRM systems, APIs, text files, etc. This data will land in your ingestion zone, or if you are following the Medallion architecture – your Bronze layer. You will transform your data with the Data engineering experience, essentially Spark, or Dataflow Gen 2, which is a visual way of transforming data and leverages Power Query. For those that used the Power BI dataflows previously, this experience will be extremely familiar. 

Once your data is ready, you will land it into a Lakehouse. When you create a Lakehouse in Fabric, a Power BI semantic model and a SQL endpoint are automatically created with it. You can leverage the semantic model (previously called dataset) for your Power BI reporting needs. And the SQL endpoint can be used by other clients to query and retrieve the curated data with a familiar SQL syntax. 

And the last step is to enable your end-customer, i.e. tenants, to consume these reports. For that, you will leverage Power BI Embedded and embed your reports into your web application. Your users will sign-in to your web application and get access to the reports their identity and tenant is authorized to see. We will discuss more the authentication and specifically service-to-service authentication of this architecture in the next sections. 

Note! The term tenant here refers to the end-customer of an ISV and not the Microsoft Entra ID, previously Azure Active Directory, tenant. 

Microsoft Fabric features enabling SaaS applications 

Next, we will look at ISV and SaaS specific requirements and how these are achieved in Microsoft Fabric: 

  • Tenant isolation; 
  • Tenant monitoring and billing estimation; 
  • Secure authentication of users and services. 

Tenant isolation 

Workspace based isolation is easy and the recommended way to segregate your tenant’s data in Microsoft Fabric. Workspaces isolate the data at a logical level. All the Lakehouses live in the same OneLake. What this means is that each Microsoft Fabric tenant comes with a OneLake, that under the hood is an ADLS Gen 2 account, where all the data will be stored. If your organization needs, besides customer analytics, internal analytics as well, you can create shortcuts from your Internal-Analytics workspace to the tenant workspaces and query that data without having to duplicate it. 

Each workspace is assigned to a Fabric capacity, which is a distinct pool of resources allocated to a Fabric instance. These capacities are the compute that powers all the Fabric experiences.  

Capacities allow you, as an ISV, to share compute resources among your tenants. You can group multiple tenant workspaces to use the same capacity. You can also assign your big or premium tenants to bigger capacities, or individual capacities. The options here are multiple and you are given the flexibility to create a setup that makes the most sense to your business and requirements. 

Tenant monitoring and billing 

The Fabric Capacity Metrics app allows you to monitor storage and capacity utilization. As a SaaS vendor, the ability to monitor utilization is key to understanding how your tenants are using your service, if some are abusing the service, creating a noisy neighbor problem, or others are underutilizing it signaling potential attrition. 

Besides leveraging this data to understand tenant utilization and behavior, you can also use it to estimate tenant consumption and determine whether you are billing your tenants proportional to their usage of the service. 

Secure authentication of users and services 

The following diagram shows the authentication flow for our scenario: 

 

  1. User authenticates to the web application by using  
    1. An identity provider like AAD B2C, Okta, Auth0, etc. 
    2. Your own identity service – this is usually not recommended. Building and maintaining an identity service is complex, and security requirements are changing and evolving rapidly. It is usually more optimal to delegate this task to a vendor with track record expertise in the domain.
      Once the authentication happens, your user will be logged in and able to use and see content in your app that they’re authorized to see.
  2. Your web app uses a user-assigned managed identity to authenticate against Microsoft Entra ID. 
  3. Your web app gets a Microsoft Entra token from Microsoft Entra ID and uses it to access Power BI REST APIs. 
  4. Your web app calls an Embed Token REST API operation and requests the embed token. The embed token specifies which Power BI content can be embedded. 
  5. The REST API returns the embed token to your web app. 
  6. The web app passes the embed token to the user's web browser. 
  7. The web app user uses the embed token to access Power BI. 

 

Skip this paragraph if you are not curious about why user-assigned managed identity support is a great evolution. To appreciate it, we need to know that a while ago to authenticate Power BI REST APIs you could only use service principal (or a master account which is not practical for the embed for your customer scenario). Creating a service principal per tenant is practically impossible for most ISVs. Imagine building a workspace per tenant model but having to use a single service principal to authenticate that workspace? This is how it happened for a while. However, there is a limit to how many workspaces can be assigned to a service principal before you start seeing performance degradation. That limit is 1000 workspaces for a service principal. To overcome this limitation, the Power BI team created service principal profiles. This is an elegant solution to this challenge. 

However, now that managed identities are supported, you don’t have to worry about any of it. All operations on managed identities can be done with ARM templates, Azure CLI, PowerShell, REST APIs, and of course, Azure Portal. This means you can automate its provisioning as part of your tenant onboarding automation.
 

Conclusion 

In this blog post, we looked at how Microsoft Fabric can be your go-to solution for customer analytics in SaaS solutions, and what are its features that make it uniquely compelling for ISVs. 
There is still a lot of ground to be covered that tackles development and deployment. And this is what we will talk about in the second part of this blog. Stay tuned. 

Updated Sep 04, 2024
Version 3.0
  • dtheodor's avatar
    dtheodor
    Copper Contributor

    Awaiting the second part of the blog post. Specifically addressing development and deployment of the same code artifacts (such as reports, semantic models) across all workspaces while maintaining their tenant-specific parametrization. For example, making a change to a semantic model's measure, and then deploying this in an automated fashion across all tenants' workspaces, while not breaking anything tenant-specific such as the semantic model's parameters or its connection to the correct customer database. I don't believe this is at all possible out of the box.

  • chintanshah's avatar
    chintanshah
    Copper Contributor

    Need information to manage below requirements 

    1. Development and deployment of the same code artefacts across all workspaces while maintaining their tenant-specific parameterisation and isolation

    2. Version control of models and reports