If you are evaluating Microsoft Fabric and do not currently own a Premium Capacity, chances are you’re using Microsoft Fabric Trial Capacities. All Power BI users within an organisation or specific security groups given the rights can opt into Fabric Trial Capacities. Therefore, you may already have several Trial Fabric Capacities in your tenant. Your Fabric Administrators can specifically control who can opt into the Fabric Trial capacities within the Fabric Admin Portal, on the Help and support settings section, and enabling the Users can try Microsoft Fabric paid features setting as shown in the following image:
The authorised users can then opt into Fabric Trial by following this process:
Click the Account Manager on the top right corner of the page
Click the Start trial button
Click the Start trial button again
Provide the required details
Click the Extend my free trial button
The following image shows the preceding steps:
As you see, opting into Fabric Trial is simple, unless it isn’t!
There are cases where authorised users cannot start their Fabric Trial because their tenant has already exceeded the limit of available trial capacities. In that case, the users get the following message:
In this blog post, I will explain some of the key concepts, personas, and terminologies related to Microsoft Fabric, a SaaS analytics platform for the era of AI. If you are not familiar with the basic concepts of SaaS analytics platforms and how Microsoft Fabric fits in, I recommend you read my previous blog post, where I explain them in detail.
Microsoft Fabric is an experience-based platform, meaning users can interact with it depending on their roles and personas. For example, a data engineer can use the Data Engineering experience to perform large-scale data transformation through the lakehouse. A data scientist can use Data Science experience to develop AI models on a single foundation without data movement. A business analyst can use the Power BI experience to create and consume interactive reports and dashboards. And a data steward can use the Data Activator experience to govern and secure data across the organisation. The Data Activator experience is in private preview and is not available for public use yet!
Microsoft Fabric Terminologies
To understand how Microsoft Fabric works, it is crucial to know some of the terminologies that are used in the platform. Some of them are existing terms that are also used in Power BI or Azure services, while some of them are new and specific to Microsoft Fabric. Here are some of the key terms that you should know:
Tenant: A tenant is a dedicated instance of Microsoft Fabric that is provisioned for an organisation or a department within an organisation. A tenant has its own set of users, groups, permissions, capacities, workspaces, items, and experiences. A Fabric tenant is associated with an Azure Active Directory (AAD) tenant, which is a directory service that the organisations own when they sign up for a Microsoft cloud service such as Azure, Microsoft 365, Power BI, etc. AAD provides identity and access management for cloud applications. A tenant in Microsoft Fabric can only be accessed by users who belong to the same AAD tenant.
Capacity: Capacity is a term that refers to the amount of resources available to support a computing service. In the context of SaaS applications, capacity refers to the ability of the system to handle a certain amount of load or demand based on the required resources and infrastructure such as compute power (CPU, RAM, etc.), storage, network bandwidth and whatnot. As explained in my previous post, Microsoft Fabric is a SaaS platform. So, from a Microsoft Fabric perspective, capacities are sets of resources that are allocated to a tenant to run analytics workloads. The capacities sit in a tenant, and the available resources can be shared by multiple workspaces or dedicated to a single workspace for better performance and isolation. Microsoft Fabric capacities are available in various F SKUs that offer different levels of resources and features. For more information about capacities and SKUs, see Microsoft Fabric Capacity and SKUs.
Workspace: A workspace is a logical container that holds a collection of items and artefacts. A workspace can have one or more owners who can manage its settings and permissions and one or more members who can access its items. A workspace can also be assigned to a capacity to run its analytics workloads. In Microsoft Fabric, workspaces are based on Power BI workspaces.
The above terms also apply to Power BI, so they have been used within the community for a long time. The hierarchy starts with an organisation acquiring their potential Tenants, and then the purchased Capacities are available to tenants and the Workspaces that are assigned to capacities.
One of the most important aspects of the software development life cycle is to have control over different versions of a solution, especially in a project where there is more than one developer involved in the implementation. Just like when you normally create a project in visual studio and you commit the changes back to a source control system like GitHub or Azure DevOps, it’s advised to keep the history of different versions of your Power BI reports. What we expect from a source control solution is to keep tracking of all changes happening in the source code while developing a project. So you can easily roll back to a previous state if you like to.
The other benefit of having a source control process in place is when multiple developers are working on a single project. Every single one of them makes changes in the source code then they commit all the changes into the source control server without overwriting each others’ work.
With Power BI things are a bit different though. Power BI report files are PBIX files which are stored in binary format (well, PBIX is basically a zip file isn’t it?) which at the time of writing this post, there is no official way to enforce Power BI source control in any source control solutions like GitHub or Azure DevOps (YET).
Microsoft announced a fantastic feature last week (6/05/2020) named “Deployment Pipelines” which does exactly what we’re after, but it is currently a preview feature which is only available only to organisations with Power BI Premium. So it is out of the game for the majority of us.
Having said that, there is still a way to keep history of changes in the shape of different versions of PBIX files. This is called Version Control.
There are several ways you can enable version control over your PBIX files while developing the report. Regardless of the version control platform you need to think about having multiple environments and who can access them for doing what.
Data modellers and report writers access this environment for development purposes.
User Acceptance Test (UAT)
Developers, SMEs, Technical Leads, Power BI Admins
After the development is finished the developers deploy the solution to the UAT environment. The solution will then be tested by SMEs (Subject Matter Experts) to make sure the business requirements are met.
Pre-prod (Optional but recommended)
Technical Leads, Power BI Admins
After the solution passed all UAT testing scenarios Technical Leads or Power BI Admins will deploy it to Pre-prod for final checks to make sure all data sources are correctly pointing to production data sources and all reports and dashboards are working as expected.
Technical Leads, Power BI Admins, End Users
After pre-prod checks completed Technical Leads or Power BI Admins deploy the solution to the Production environment which is then available to the end users.
Version Control Options
If your organisation does not have a Premium capacity then “Deployment Pipelines” feature is not available to you. So you need to come up with a solution though. In this section I name some Version Control options available to you