In this article, we will continue covering the basic concepts of Power BI. I wanted to write about licensing and how to start with Power BI, but it wouldn’t be effective, if we didn’t cover some of the key concepts of Power BI cloud infrastructure. So, what is exactly Power BI Service, what are the main building blocks and how Power BI assets are organized; these are the topics we will try to cover today. Before that happens, let’s cover fundamental definitions related to cloud computing.
What is cloud computing?
When it comes to delivery of software applications, services, or infrastructure, we have two different deployment models:
- On-prem (on-premises) – services/infrastructure are installed and operated within company’s own datacenters. In this scenario company is responsible for procuring, managing, and maintaining their resources. There are huge upfront costs involved (CAPEX) and companies need to plan and allocate resources for future demand growth. This not only takes time, but you also risk spending a lot of money for hardware, which will be underutilized when demand drops.
- Cloud services – delivery of computing services over the internet by third party vendors. Your resources can be rapidly scaled up when demand is high, and scaled down when demand is lower. Cost model shifts to operational expenditures (OPEX), as cloud services operate on pay-as-you-go or subscription models.
- Infrastructure as a Service (IaaS) – cloud offering, which is the closest to on-prem scenario, which makes it perfect choice when companies want to start working with cloud. In a nutshell, with IaaS cloud provider is responsible for: physical datacenter, network security, servers, and storage. Typical example is Azure Virtual Machines.
- Platform as a Service (PaaS) – it includes the same offering as in IaaS, with addition of: development tools, middleware, database management services, and more. It’s a complete development environment that allows you to build both simple and complex applications. Typical examples are Power Platform, Azure Synapse Analytics, Azure SQL Database.
- Software as a Service (SaaS) – the easiest to deploy among all cloud offerings, but at the same time, it’s least customizable option. It includes offerings from IaaS and PaaS types, and top of that, delivers a complete software solution. In this scenario, customer is responsible only for: managing own data, provisioning access and devices used to consume the software. Typical examples are MS Office tools, Azure DevOps and Power BI Service.
- Serverless – serverless computing is a type of cloud offering, which allows developers to focus on business logic, without being worried about underlying infrastructure. It still means that there is a server in the background running all the operations, but tasks related to provisioning and resource maintenance are abstracted from developer. Typical example is Azure Functions.
What is Power BI Service?
You may also hear it being referred to as Power BI Online. As mentioned in this article, Power BI Service is a cloud based SaaS solution, used to host and share your Power BI Reports. With its intuitive web-based interface, it allows you to publish (even create), share and collaborate on Power BI Artifacts. Power BI Service provides data storage, automatic refresh capabilities, access control mechanism, allowing to access your data wherever you are in safe manner controlled by Azure Active Directory.
Power BI Artifacts
It’s important to mentioned that we are going to talk about Power BI only in this article, therefore we will not cover anything related to Microsoft Fabric today. Before we talk about building blocks of Power BI Service, and how Power BI Artifacts are organized, let’s clarify first what are these artifacts.
We could say that Power BI Artifacts, are individual components, that make up a full Power BI Solution. It may seem a bit vague, but it will be more clear when examples arrive. Let’s look at the most basic scenario. You are authoring your Power BI Report in Power BI Desktop, when you’re done, you are publishing it to Power BI Service. Here comes the part, which is not very intuitive for beginners, as you see two different objects in Power BI Service:
- Report
- Dataset
Even though we created a single Power BI file in Power BI Desktop, we see two separate objects in Power BI Service. We will deep dive in this topic more in separate article, as from operational perspective this behavior makes a lot of sense. However, the most fundamental idea here is a Dataset being a semantic layer of our Data Product. This is the so called “source of truth” of the report we created. This “source of truth” could be used by other teams, that might want to create their own reporting, following the concept of re-usability of objects. It simply means that there can be many reports created from single Dataset. They can answer different business needs, but the “source of truth” remains the same. We don’t risk showing different calculations in separate reports, making sure that business logic is aligned between them. Therefore, it’s absolutely crucial for Power BI Reports and Datasets being displayed as separate objects.
These objects are the most basic and most obvious Artifacts we may find in Power BI Service. But there is more, let’s see the list of all available Artifacts we can create in Power BI Service:
This is the picture taken from Power BI Service. We will discuss them briefly:
- Report – as we explained above, this is the visualization layer of Power BI Solution we designed in Power BI Desktop, or in the Power BI Service directly.
- Paginated report – allows to design pixel-perfect reports, mainly for printing purposes. Option is available in Power BI Service, but it then redirects you to download page to get desktop authoring tool – Power BI Report Builder.
- Scorecard – very underestimated solution, that allow to setup metrics and KPIs for your organization and track the progress against your targets.
- Dashboard – here comes the confusing part. When we create our solution in Power BI Desktop, most people will say that they are creating a Power BI Dashboard. The truth is that we create a Power BI Report, while Dashboard is a bit separate story. Dashboard solution allows you to build a single page data story. It means that you may “pin” different visuals (or even entire report page) from multiple Power BI Reports in a single page, providing sort of a summary of all your Power BI Solutions in one place.
- Dataset – semantic layer and a source for our Power BI Report (explained above).
- Dataflow – Power Query online experience, that allows to run ETL process and expose the data in form of separate entities (tables). Why to use it if we have Datasets? We may have many different tables in our dataset, all following specific business logic. The purpose of Dataflow is to not re-create that business logic among different datasets but re-use the existing one. With Dataflow we achieve re-usability of our data on more granular level than Dataset. Very cool feature, and for sure we will spend a lot of time on this topic 🙂
- Datamart 💎- very large topic to be covered with separate article. For now, let’s think about it as a solution similar to Data Warehouse, but designed in a way so it’s suitable even for Citizen Developers. It still allows you to interact with the data using SQL, either directly in portal, or with desktop tools of your choice, using SQL endpoint. With Datamart you may design relational data model, create DAX measures and calculated columns, even create Row Level Security rules. When you build a Datamart, together with it you receive a default Power BI Dataset, which gets updated together with Datamart. Today, it’s the only way to create a Power BI Dataset from scratch in Power BI service.
- Streaming dataset – special type of dataset designed in a way, so it’s capable of constantly pushing the data to Power BI, providing near real time experience. You cannot build typical dataset in this scenario, that will support filtering and other experience you are used to. You don’t build a standard Power BI Report from it either, as data from streaming dataset is exposed through a single tile within a Dashboard.
- Streaming Dataflows 💎 – as it is in standard dataflows, we get the streaming data exposed in form of single entity, therefore, it is possible to build a full Power BI Report using streaming data. All we need to consume that data in Power BI is to choose dataflows as a source, use Direct Query type of connection and setup Report Page Refresh.
Power BI Artifacts is not the only termy that you may find in the web, even in Microsoft documentation. You may sometimes find Artifacts being called Power BI Assets, especially especially in regards to data catalog / governance tools like Microsoft Purview. Sometimes they are also called simply Objects. All of them work just fine, it’s just for you to know that these terms may appear interchangeably.
I hope you enjoy the content so far, as probably we are only half way there. We covered all the relevant definitions, to be able to focus on building blocks of Power BI Service, starting with Power BI Artifacts and travel all the way up to higher levels of abstraction.
Building blocks of Power BI Service
Before we start discussing individual blocks, let’s look holistically at the structure of Power BI Service:
We see quite a structure here. At the center of the Workspace boxes, we can see icons of Power BI Artifacts (exactly these are reports, datasets and dataflows). They are just representing the lowest grain within Power BI Service, meaning all the types of Power BI Artifacts, covered in previous section.
Workspaces
Basic container in Power BI Service. When we publish a Power BI Report from Power BI Desktop, we need to select a Workspace where we want to send our report. If we want to use Power BI Service, we need at least one Workspace. Purpose of the Workspace is to invite people to build the content together in a collaborative spirit. It means that we can grant workspace access to other users, by assigning to them one of the following roles:
- Admin – most privileged type of access. With this role you may Update or Remove the workspace, add/remove other users (including Admins), allow contributors to update apps.
- Member – can do the same as Admin, except of tasks mentioned in Admin section. In general, this role has full rights to share the content, manage datasets permissions, and add/remove users with Member role or lower.
- Contributor – role that is perfect for Power BI content creators, when we can’t or don’t want to assign Member or Admin role. This is the least privileged role that allow to publish and edit Power BI Reports.
- Viewer – the least privileged role. Allow end users to view and interact with reports. If granted with “Build permission”, Viewers may also build their own content using Power BI Datasets, or using “Analyze in Excel” feature. This role also grants visibility into dataflows available in given workspace.
Workspaces provide a lot of settings and, as you might guess already, it deserves separate article. For today, let’s remember only that Workspaces are containers for Power BI Artifacts, allowing to store and collaborate on available content.
Apps
This item is not available in a graphic above, but this is another way to share the content within your organization. Apps allow to bundle reports (and even other web content) and share them all together in form of App. We may decide to share the App with individual users, Security Groups, Entire Organization, and even decide to install the application automatically for all the users. Apps also provide capability of Content Control. It means that within single App, we are allowed define different types of audiences, and limit the access to specific reports. This is great feature, as previously you needed to create separate App for this purpose. Which is problematic considering, that you may have only one App per Workspace.
Capacities
Arguably, the most important concept within Power BI Service. Capacity is a set of resources, that allow to publish, share, and interact with the available content. It is a very broad topic, we will cover it in one of the future articles, and partially in next one related to Licensing. Today, we will cover most important information only.
When Workspace is created in Power BI Service, we need to decide to which Capacity we are going to assign that Workspace. This process is reversable, so we can always move the workspace to different capacity if needed. As presented in above graphic, we have two types of Capacities
Shared Capacities – Offering for companies based on Power BI Pro licenses. In this scenario you share the computational resources with other customers, therefore you must consider lower report performance, than you might have with Premium Capacity. To ensure that “fair play” rules are in place when using Shared Capacity, we have a limits of 1 GB per dataset, and maximum of 8 dataset refreshes per day. Total storage for organization is calculated as 10 GB * number of users with Pro Licenses. Microsoft manages for us not only computational resources, but also a storage. It means that our data resides in region associated with Power BI Tenant. We will cover the Tenant part in next section.
Premium Capacities we can split into two options:
- Premium per Capacity – Dedicated resources that Organization is buying from Microsoft. It means that no one besides that organization is allowed to utilize dedicated resources, ensuring best achievable performance. Premium Capacities grant also access to Premium features (we will cover them in future :)). There are different sizes of Capacities that we can buy, depending on which one we choose, we have access to following resources:
- CPU Power – between 8 and 128 v-cores
- Max memory per dataset – between 25 GB and 400 GB
- 100 TB of total storage per Capacity
- Premium per User (PPU) – People tend to complain about complex licensing models within Microsoft offerings. True, but this is related to answering to different needs, and allow companies to pay less for some services. This is exactly the case with PPU. When it comes to licensing specifically, we will cover it together with remaining part. As for the resources, when there is a first PPU license provision in your organization, a PPU Capacity is created within your tenant. It has a total storage of 100 TB, and when it comes to resources this is the only number we know. The computational part is managed by Microsoft, just as it is with Shared Capacity, even though we get Dedicated PPU Capacity for our tenant. Another similarity to Shared Capacity is that with PPU Capacity we also get only one location for our data, associated with Power BI Tenant Region. Still, it provides access to most of the Premium features, making it very affordable for small / medium sized companies, that don’t need their data to reside in different regions. Comparing PPU to Shared and Premium Capacities, we could say that PPU is something in between the other two.
We are almost there, there is only one last concept to be covered.
What is a Tenant?
The easiest way to put it (although not always 100% accurate) is to say that a Tenant is an Organization, that “rents” a piece of Microsoft Cloud. The reason it’s not always accurate is that Organizations sometimes go with multitenant setup. While most probably it is justified, from Power BI perspective it would make it harder to provide a decent overview of what is going on within organization, would make it a bit more difficult to manage resources efficiently, and it would duplicate the administrative effort.
Tenant is broader term, and not related to Power BI only. In fact, you may create a Tenant in MS Office 365 portal, and in Azure Portal, by creating new Azure Active Directory. Even if you are a Power BI Admin, probably you will not create a Tenant. But there is very important part of Tenant creation – you need to specify default Region. It doesn’t have to be the Region where your company is registered. Rather choose something that is closest to majority of your End Users.
As it was covered in Shared and PPU Capacity, this Region indicates where our data is stored when we work with those Capacities. It’s more important decision than it looks, as we need to consider following factors:
- Latency – Region selected in location closest to majority of Users, will ensure better performance for those Users. Microsoft operates many datacenters all over the world, therefore choice of available Regions is pretty impressive.
- Data Residency Requirements – There are types of data, defined in country specific regulations, that due to legal requirements may not leave boundaries of the given country. This simply means that if you are in Germany, you may not be able to publish your data to Shared Capacity Workspace, if you default Region is US WEST for example. If you are not sure, ask question to your Power BI Admin to clarify, where your data will be stored.
Each Tenant should have a Power BI Administrator assigned. Even though there is certain level of flexibility when it comes to Capacity or Workspace settings, the most important decisions are made on Tenant level. Power BI Administrator may control availability of certain features, to make sure that settings comply with organization rules.
Conclusion
If you are still here, I am impressed 🙂 Thank you for bearing with me till the very end, as we again covered a lot of information today. After you are done with the reading, you should be able to:
- Briefly explain basic cloud concepts
- Describe what is Power BI Service
- Name available Power BI Artifacts
- Have general overview on content sharing through Apps and Workspaces
- Explain what is Capacity and what types of Capacities there available
- Understand what is a Tenant
We are still at the very beginning of exploring basic concepts, and so far there is a lot of topics introduced, even though very briefly. For future articles, I will try to provide more focused content 🙂
For now, thank you for reading, and see you in next article!
Thanks for the explanation