I’ve recently spent a lot of time developing Fabric items (pipelines, notebooks, activators, lakehouses, semantic models, etc.). I’ve also spent a lot of time reading Microsoft’s marketing material and trying to parse out the hype from the useful. I decided it’s time to give my honest appraisal.
I come from a background as a Power BI developer and more recently a data engineer using Azure Synapse, so much of my analysis is related to how Fabric compares to these two tools. Though I have some exposure to data science and streaming analytics in Fabric, I’m less equipped to give a useful assessment on these workloads.
In short, for the workloads I’ve used, I find myself equal parts impressed and frustrated with Fabric. There are days where I’m quite impressed with how the platform has made certain tasks quite simple. And there are days where I’m stuck wondering why I can’t complete the most basic of tasks because of some bug or missing feature.
Without further ado, here’s my (not comprehensive) list of positives and negatives I’ve encountered in Fabric.
Positives
1. Fabric addresses a major toolset gap that used to exist for Power BI developers
That is, the ability for Power BI developers to perform more robust data transformations and store their logic in a central location to be used across reports. Power BI developers used to be dependent on Power Query for this work, whether it existed in a published dataflow or a semantic model. Large amounts of data and complex transformations greatly reduced Power Query performance, sometimes to the degree that the reports became unusable or refreshes took hours. And despite useful features like composite models, it’s been difficult to use the output of those transformations across multiple reports.
Fabric addresses that gap by providing Power BI developers and analysts with a much more robust way to transform data using Spark notebooks, T-SQL, Python, or other familiar methods before it’s ingested into Power BI (or connected directly via Direct Lake mode). The result is an intermediate layer between the enterprise data warehouse or data source and the Power BI report that is much more optimized for resource intensive operations. This allows Power BI to shine where it’s best – as a visualization tool – instead of as an ETL tool. It also keeps the transformation logic stored in one place for downstream use.
2. Fabric Abstracts complex infrastructure tasks that used to take much longer to complete
I’ve been working for months on migrating Azure Synapse to a different cloud environment, and I can say firsthand that the experience of setting up Fabric is night-and-day better. Because Fabric is a SaaS platform, it literally takes minutes to access Fabric features, as opposed to month to get the infrastructure for other cloud platforms configured.
I’ve found this to be the case with many of the items in Fabric, as well. Deployment pipelines and GIT are much simpler to set up and integrated directly in the Fabric environment. Existing gateway and cloud connections can be leveraged instead of needing to configure linked services and integration datasets. And data warehouses and lakehouses can be spun up in the click of a button. This speed to set up is a major benefit for organizations that want to leverage a quick and simple analytics platform.
3. Fabric offers features that speed up development
Similar to the point above, there are many native features that speed up tasks such as ingesting data or writing code.
Shortcuts, for example, allow data stored in certain formats to be accessible in a Fabric without the need to move the data. This is a huge benefit to companies that already have an existing data lake in another cloud, allowing them to quickly surface data in Fabric for analysis. Another feature is mirroring, which allows some data sources to be near-real-time replicated into Fabric for free. Not having to maintain data pipelines to load data can significantly reduce the amount of work needed to load (and continue loading) data.
Finally, code suggestions and AI are embedded into many of the workflows, helping improve speed of development and offering useful suggestions. The AI outputs are arguably a mixed bag, but certain features like notebook code suggestions and SQL query suggestions have proven to be quite useful for me when developing.
4. Fabric packages what used to be separate tools into one (familiar) location
That location is Power BI Service, which used to house only Power BI content but can now host numerous Fabric items for various stages of the analytics workflow. This can sometimes lead to a cluttered UI. But if items are organized well into workspaces, folders, etc., I think this is a net positive. Your analytics can be in one place instead of spread across multiple tools, governance is much easier, and business users share a common platform on which to develop BI content.
Negatives
1. Fabric has a slow and clunky web interface
When navigating the Fabric UI, I find it’s not uncommon to have significant delays when opening items and navigating the interface. This isn’t a “performance” issue due to the capacity, and it has been reported by many users.
The reality is that Fabric is just slow to navigate. Lakehouse tables and views sometimes take 30+ seconds to display, when querying the same object using external tools take less than a second. Clicking around will inadvertently lead to spinning wheels or out-of-date displays. The result is I find myself using external tools whenever possible, instead of being able to leverage the built in UI. This is not a showstopper, but it is something that needs to be addressed by Microsoft.
2. Fabric (Still) has many BUGS and incomplete features
I had hoped this would improve over time, and it has to some degree. But there are many unresolved bugs and issues. Simple tasks like pinning lakehouses with the same name to your notebook, monitoring pipeline statuses, filtering items, viewing pipeline outputs, and much more can lead to an oftentimes frustrating experience. It’s impossible to specify all of the bugs, but I guarantee if you start developing in Fabric you will run into them quickly. Microsoft needs to focus on improving the quality of life for its Fabric users rather than focusing so exclusively on new features.
That said, incompleteness of features needs to be addressed as well. Want to save dataflows to GIT? Not supported. How about an ML experiment? Also not supported. Want to leverage the new copy data UPSERT? Not supported – if you’re copying data to a lakehouse, that is. Data warehouses are supported. Want to shortcut data cross-cloud? Good luck. Need to turn off case-sensitivity for your lakehouse SQL endpoint? Not supported. But it is for the data warehouse. There are many such feature gaps.
Oftentimes there are underlying technical reasons for these limitations. But unfortunately, these half-finished features often limit what you can do, and they aren’t advertised until you get into development and see something isn’t supported. This leads to many unnecessary workarounds. I’ll give Microsoft credit for pushing hard to release new features, and I’ve seen great improvement in the past year. But Fabric continues to feel like a half-finished product.
3. Fabric’s Shared capacity model leaves a lot to be desired
My last negative is the fact that Fabric operates on a shared capacity model and requires you to purchase a basket of compute. This is a major step back from the pay-for-what-you-use model of almost every other major cloud platform.
First, why should compute have to be purchased and shared across an entire capacity instead of just spun up as it’s used? When you force multiple groups to share a capacity, it only takes one long-running refresh or poorly optimized pipeline to bring the entire thing down. Why not instead offer unlimited scaling and just charge organizations for what they use?
Which brings me to my second concern, why should customers be charged for compute that isn’t used? If you reach 100% usage, items will get throttled and the entire capacity can go down. This means that even if you’re consistently using 80-90% of your capacity (a real challenge without having overages), you’re still wasting money on the leftover 10-20% of compute that isn’t used.
I’ve seen some improvement with this, such as being able to pay-as-you-go for Spark sessions, but I believe customers would be greatly benefited if this was rolled out for the entire set of items in Fabric. There is a pay-as-you-go capacity option which seems to be Microsoft’s answer, but though this allows you to turn the capacity on and off, it doesn’t address the two main issues above. Further, turning the capacity on and off can lead to autoscaling charges that negate the benefit of the feature.
Conclusion
Despite the issues I find in Fabric, I’m generally optimistic that the platform is going to mature over time in the same way that Power BI did. I’m hopeful that the bugs will be fixed over time and that features will continue to come in alignment with other platforms, and that the pricing and usage models will improve. But if not, I do still think Fabric can and should serve an important role in the right organizations.
What has your experience with Microsoft Fabric been? Can you relate to any of the benefits or issues? Anything you would add or modify?
Will Trickett 
Leave a comment