Microsoft Fabric will change the analytical landscape, help solve the most demanding analytical challenges, and provide deep insight derived from our data assets. I assume we have heard, read, or seen these slogans: “Unified analytics fabric - End-to-end analytics data fabric - From the data lake to the business user.” Some might call me biased because I’m a Microsoft Data Platform MVP, but I’m convinced these slogans are true.

Nevertheless, we had access to the early bits and bytes of Fabric before the public preview, we have been working (to be honest and precise: we have been experimenting) with Fabric for more than a year. Still, we did not make up our minds about how we would organize working with Fabric. The reasons are e.g., is a Fabric solution made from a single workspace (not counting the workspaces from deployment pipeline(s)), or are there more workspaces contributing to the solutions? We also do not know how to organize the solutions around the new Fabric capacities. Will a solution “own” multiple capacities, or only one or two, and share compute power with other teams, utilizing the idea of the share economy?

If you are a data architect, a Power BI Admin, or a Power BI Developer who is already working with Fabric or you are planning to work with Microsoft Fabric, I will share some of our findings, experiences, and feelings about Fabric. Be aware that I cannot call our current thinking “best practice.” When I submitted this session, we did not use Fabric in production (most probably, this will change in Q2 2024), but we are preparing to use it. This session is not about the latest bits of configuring Spark compute, but it helps to understand some intricacies of the Fabric workspace. To follow along it will help to have an idea about the differences between PaaS and SaaS services, I will provide a short introduction, though.