As we celebrate the 3-year milestone of Microsoft Fabric becoming generally available, we reflect back on hundreds of Fabric conversations we’ve had with client eager to power the AI frontier with Microsoft latest unified cloud platform.
Over the past few years, we’ve observed that a Fabric rollout is often won or lost based on a few specific decisions early in the process. How you move data, organize workspaces, deploy changes and manage costs sets the foundation for everything after. Our recommended deployment framework for Fabric combines a “Hive-Mind approach” with our time-tested Data Success Framework.
This three-part blog series shares how our consultants approach these decisions decision around migrating, deploying, monitoring, and supporting workloads in Microsoft Fabric.
Start With a Proven Architecture
Our team follows the Well-Architected Framework for Fabric. The core idea is simple. Move data efficiently, and do not duplicate it. Data lands in OneLake. From there, it flows through the medallion layers:
Bronze: raw data, landed as-is
Silver: cleaned and conformed data
Gold: curated data with business logic and naming conventions applied
Each layer prepares data for the downstream use cases that depend on it. Data lands in OneLake once. Each layer then refines it for the next. For ERP sources, we often recommend a dedicated extraction tool to orchestrate data into the bronze layer. The right tool depends on the source system and the client's needs.
We do not apply one pattern everywhere. Our certified Fabric consultants weigh three things before choosing a Warehouse or a Lakehouse on each layer; existing code base, team skills/competency, and specified security requriements.
Secondary data sources matter too. The Lakehouse files option gives us flexibility. It handles file-based sources and APIs that sit beside the primary system.
Design Workspaces Around People
Workspace design starts with discovery. Who owns the data? Who stewards it? What workflows already exist? Only then do we turn to the platform considerations around workload segmentation, CI/CD, and governance.
We recently deployed Fabric for a multi-billion-dollar manufacturer based in Minnesota. The company already used Power BI and Azure. But it struggled to migrate an on-premises data warehouse and a mix of disparate sources.
We applied our proven data framework. It paired a centralized ingestion team with distributed data ownership. The operating model looked like this:
Central ingestion - One data team owns all ingestion into bronze. It builds, monitors and maintains every connection and tool. That includes pipelines, copy jobs, mirrors and shortcuts.
Source-based workspaces - Workspaces are organized by data sources. Bronze is the landing zone. Data then moves to a Warehouse or Lakehouse silver layer.
Domain-owned gold - Gold lives in a domain-owned workspace, as a Warehouse or a Lakehouse. We increasingly use Materialized Lake Views here where they fit. These workspaces usually hold semantic models for each domain.
Downstream consumption - Reports, data agents, data apps and Org Apps sit in further downstream workspaces. As governance matures, these can be organized by domain. Admin tasks can then be delegated to domain admins.
One central team feeds the Fabric platform. Business domains own the gold and consumer workspaces that sit downstream.
Weaving a Fabric for CI/CD
In all of our project we start small - and build with scalability in mind. Our CI/CD approach depends on how your team already works. We follow existing procedures where they apply. Where they do not exist, or do not fit Fabric tooling, we teach best practices that match your team's maturity. Our minimum recommendations:
Use workspace Git integration
Capture critical Fabric items in code repositories
Use feature branches to support team development
Set up approval workflows and version control
Plan and build rollback and disaster recovery capability
We have orchestrated this through Azure DevOps in multiple deployments. Other Git-based platforms work as well. We also split CI/CD into two workflows:
Data ingestion and integration - which typically follows Dev-Test-Prod
Data product development - where Dev-Prod is usually enough
These are often different teams working at different speeds. Separate workflows let each move at its own pace without blocking the other. Each lane deploys on its own schedule. Both share the same Git practices.
Right-size Capacity for Optimized Cost
Fabric is yet another cloud data platform that bases cost on consumption. While it’s much cheaper than its predecessor Azure Synapse - who you architect the solution will determine capacity, usage, and price.
We use our Fabric Price Guide (calculator) while we design and setup capacity based on the overall architecture and workloads being consumed.
Fabric is purchased by capacity (SKU). Each capacity provides a set amount of compute units per second, or CU(s). Monitoring cost is part of every design conversation we have.
Fabric Workspace/Activity monitoring
These tell us how large each capacity should be. Add-on monitoring tools go further. They capture granular detail and support long-term trend analysis.
Coming in Part 2…
A strong architecture is only half the story. Coming up in Part 2, we will cover governance, security, data ownership and how to scale Microsoft Fabric responsibly over time.
Additional Microsoft Fabric Resources.
