Microsoft Azure or Fabric
In my previous blog posts, I aimed to provide resources in getting started with Microsoft Fabric, along with choosing between lakehouses and warehouses and between dataflows and data pipelines.
A bigger question or decision that may exist in organizations, is how to choose between the Microsoft Azure or Microsoft Fabric platform for your data analytics workloads?
This blog will dive into some of the similarities and differences between the platforms, and relevant scenarios that will hopefully simplify this decision.
Similarities
Both Microsoft Azure and Fabric are cloud-based platforms that allow organizations to build scalable data analytics solutions. Whether you are using individual Azure services or Microsoft Fabric, you have the ability to scale vertically or horizontally to meet your needs. The configuration options for scaling these platforms actually falls into a difference between the platforms and is explained in more detail below.
Platform
Integration
With both cloud-based platforms being hosted by Microsoft, they integrate seamlessly with other Microsoft products and services. Other Microsoft products include the M365 and Power Platform suite among others.
Product Offerings
Both platforms offer a similar set of data integration and analytics capabilities. Below is a graphic that aims to compare existing Azure services to Microsoft Fabric experiences. It should be noted that the service comparison is NOT a 1:1 match, and that the technology under the Fabric platform has been improved over what was available in Azure Synapse analytics. Microsoft Fabric has blended in many existing Azure services into the platform. Based on the Fabric roadmap, it seems Microsoft will continue to add more of these Azure services into the Fabric ecosystem.
Differences
Infrastructure
Azure services offer multiple options for the deployment of your cloud infrastructure. To create Azure services, you can leverage the Azure portal, use Azure Resource Manager (ARM) templates, and choose between Bicep or Terraform if using Infrastructure as Code (IaC) in your architecture.
For Microsoft Fabric, you can create items in the Fabric portal, and most recently you can leverage the new Terraform Provider. You could also go down the route of scripting an infrastructure deployment via the Fabric APIs that are currently available.
In general, Azure services provide a more mature offering when it comes to managing your infrastructure deployments.
Compute
Azure services run individually, and thus their resource compute is controlled and managed for each resource separately. This can be both a pro and a con as it gives you more control over each individual service and its spend. However, this also requires additional maintenance and time to control and manage each Azure service.
Microsoft Fabric services all run under a single compute resource, a Fabric capacity SKU. This type of compute model also has its pros and cons as it provides a simplified path for creating new resources across all experiences. However, this compute model requires time and effort to monitor capacity usage across your entire Fabric tenant. It may also lead you to using multiple Fabric capacities to manage different workload types.
Security and Compliance
Similar to the infrastructure comparison, the security offering in Azure services is mature and comprehensive. You have full flexibility with Azure services to configure and secure them behind your private networks and ensure direct connection to the Microsoft backbone.
Microsoft Fabric also offers a number of great security features and is continually bridging the gap to meet the security capabilities and compliance of the Azure platform.
View the updated compliance offering of Azure services, including Microsoft Fabric.
Source Control and CI/CD
Another category where Azure services provide a more consistent and mature experience is source control along with continuous integration and deployment (CI/CD). Traditional source control in Azure DevOps Git Repos or GitHub Repos along with build and deployment pipelines in Azure DevOps or GitHub Actions are just a few of the source control tools that can be used with Azure services to implement a continuous integration and deployment strategy.
Microsoft Fabric aims to deliver a similar experience by integrating with Azure DevOps and GitHub repos through Git integration and deployment pipelines. It should be noted this feature is currently in preview so please review the current git integration limitations and deployment pipeline limitations.
Azure or Fabric?
Now that you've reviewed some of the similarities and differences between the Microsoft Azure and Fabric platforms, how do you decide which platform is the best choice for your data architecture?
Scenario 1 - Existing Azure Platform
In this scenario, your organization has already made a heavy investment into Azure or another cloud platform. Your organization is exploring better tools for data analytics and visualization but are unsure how to proceed.
Conclusion: Your organization may be better off keeping the majority of its Azure infrastructure intact, yet may look to leverage Fabric for its integration with Power BI and data science experiences to enhance your data analytics and self-service capabilities. Leverage Fabric's data ingestion features, such as Data Pipelines, EventStreams, shortcuts, and mirroring, to bring a single copy of the data assets you need from your existing Azure platform into Fabric. Power BI's semantic model layer is must have, in my opinion, for any organization looking to scale its self-service analytics capabilities and improve reporting accuracy across the entire organization.
Scenario 2 - Greenfield Analytics Platform
This small to mid-sized organization is looking to build out a new cloud data analytics platform and is evaluating between using Azure services or Fabric for their platform. The organization has limited IT and data team resources and is looking for a platform that reduces the time and maintenance of handling their cloud resources.
Conclusion: This organization may want to use Microsoft Fabric, due to its simplified compute model and ease of managing all their data analytics resources in a single platform.
Scenario 3 - Team Experience
This organization's data team has a lot of experience using Azure Databricks, however the organization would like to extend the current data platform and allow for more self-service analytics within the business. Many of the business users gaining access to various data layers in the data platform environment would consider themselves analysts and lack data engineering skill sets.
Conclusion: Continue to use Azure Databricks for your large data processing workloads. However, it may be worth a migration effort to move the organization's data storage layer to Microsoft Fabric. This would allow the organization's users to access the data in single location (OneLake), that tightly integrates with other user-friendly experiences for self-service analytics. Databricks workloads would also continue to process the data, now sitting in OneLake storage.
In Summary
Microsoft Azure services and Fabric contain many similarities and some differences that may pose a difficult decision for organizations when choosing between the platforms. Oftentimes the decision may come down to factors like existing platform investment (time, financial resources, and volume), team experience, or simply the hesitancy of the new and unknown. Rest assured that no matter the decision of choosing Azure services or Fabric, Microsoft provides all the capabilities and resources needed to build a scalable and enterprise level data platform.
As always, thanks for taking the time to read this blog post and happy continued learning!
© Copyright. All rights reserved.
We need your consent to load the translations
We use a third-party service to translate the website content that may collect data about your activity. Please review the details in the privacy policy and accept the service to view the translations.