Understanding the Power Platform architecture

Power Platform is one of the three Microsoft cloud offerings and is part of the overall Microsoft cloud infrastructure. In this section, we will focus on explaining the Microsoft cloud infrastructure, the structure of a customer cloud ecosystem, the Power Platform technology and environments, as well as their main components. This is key to understanding the architectural principles of the Power Platform and making proper decisions about the overall architecture of your solution. First, we will describe the Microsoft cloud infrastructure to better understand the key concepts.

Learning about the Microsoft cloud infrastructure

The Microsoft cloud products and solutions of all three clouds are operated out of Microsoft data centers, which are grouped into regions and geographies. Each region contains two or more data centers for failover safety and high availability. Microsoft has more than 50 cloud regions worldwide. For Microsoft Azure, Microsoft Office 365, and Power Platform, these regions are structured differently. For example, for Microsoft Azure in Europe, there are many separate regions, such as North Europe, West Europe, UK West, UK South, France Central, France South, Germany West Central, Germany North, Germany Northeast, Germany Central, Norway West, Norway East, Switzerland North, and Switzerland West. These can all be selected when you're provisioning Azure services.

However, for Power Platform, there's currently just three separately selectable regions in Europe; namely, Europe, United Kingdom, and France. This indicates that Power Platform cloud services are not available in all existing Microsoft data centers.

For Power Platform cloud services, the customer cannot select the region in such detailed granularity as for Azure. This is because – for example – the customer can select the Power Platform region Europe but can't decide whether it will be North Europe or West Europe like they can for Azure. Currently, the following regions are available worldwide when a customer wants to create a new Power Platform environment (the number of available regions can grow in the future):

• Asia
• Australia
• Canada
• Europe
• France
• India
• Japan
• South America
• United Kingdom
• United States
• US Government (GCC)
• Preview (United States)

Within these regions, there is one specific region called Preview (United States), which contains preview features of the Power Platform components not available in the other regions. Selecting this region is useful for testing the latest product features and giving feedback to Microsoft. Currently, no Common Data Service (CDS) database can be created in this region, so no CDS and model-driven app preview features are available when using this channel.

Understanding the customer cloud structure

When a customer first purchases a Microsoft cloud service, they always get a certain basic structure that is necessary for operating the service, or any other additional cloud service from Microsoft. This structure is built around a tenant. This tenant is technically an Azure Active Directory domain that's used to support the central services for each cloud solution, regardless of whether it is Microsoft Azure, Microsoft 365, or Microsoft Power Platform.

Within one tenant environment, there can exist several subscriptions of cloud services from all three Microsoft clouds. Depending on the subscription type, there can be various cloud services belonging to those subscriptions.

Let's assume our fictitious company, Contoso Inc., already uses various Microsoft cloud services. Their cloud structure could look as follows:

Figure 3.1 - Contoso Inc. structure of the Microsoft cloud services

As we can see, a large organization can have a very complex structure consisting of many parallel cloud subscriptions from different cloud services.

The tenant itself is always located in a certain Microsoft cloud region, but any Power Platform environments are independent of the tenant's region and can be created in any Power Platform-enabled region. This can be selected by the creator.

For the purpose of Power Platform, the central tenant services that are essential for running any Power Platform application are as follows:

• User management
• License management
• Group management
• App registrations
• Office 365 Activity Logging

In the following sections, you will learn more about these services.

User management

Any user of any Microsoft cloud service, including Power Platform, must first be registered in the Azure Active Directory of the customer's tenant. User management in the tenant can be done in a variety of ways:

• Manual user management using the Microsoft 365 management portal
• Synchronizing user identities automatically from the customer's on-premises active directory
• Using scripting automations with PowerShell
• Using a third-party identity management solution, integrated with Azure Active Directory using the Graph API

License management

After a user has been registered in Azure Active Directory, access to any cloud service is granted by assigning the respective product license. After the license has been assigned, a background process starts provisioning access to the service for the user. For license management, the same management options that are available for user management are provided.

Group management

Groups are used for the following purposes for Power Platform solutions:

• Managing user provisioning into distinct Power Platform environments
• Managing authorization within CDS applications
• Managing the integrated Office 365 groups

For group management, the same options for manual, scripting-based, or automated management for user or license management are available.

App registrations

App registrations is a security feature necessary for implementing OAuth authentication scenarios for external applications or integrations connected with the Power Platform API.

Office 365 Activity Logging

Office 365 Activity Logging is an auditing capability for Office 365. This also includes CDS auditing.

Important note

More details about user, license, and group management, as well as app registrations, will be discussed in later chapters.

Learning about Power Platform technology

Power Platform is a cloud service and therefore there are not many publicly available technical details about the background technology. Power Platform is operated on so-called scale groups, which are unified blocks of cloud infrastructure that consist of various infrastructure components necessary for running services. There are database servers, reporting servers, web servers, app servers, integration servers, and much more, but the Power Platform customer doesn't have access to these infrastructure components. Scale groups are only located in the Power Platform-enabled cloud regions.

Due to the nature of the Software as a Service (SaaS) cloud model, scale groups are shared among multiple customers. One single scale group can host Power Platform environments for dozens or even hundreds of customers. This approach requires certain expected and also enforced behavior standards, specifically to refrain from any activities with potential heavy performance impacts on the underlying infrastructure. For example, customers aren't allowed to run stress tests against the Power Platform API. Certain enforced restrictions will be described later in this chapter. It is a matter of fact that the platform usually allocates more resources for production than non-production environments.

Understanding Power Platform environments

Power Platform solutions (other than Power BI) always run within Power Platform environments. An environment is a logical and physical unit and is the foundation for creating Power Platform solutions. It also acts as a container for all the resources that are used in the solutions. In this section, you will learn about the environments and their main components.

Let's start by describing the different types of Power Platform environments, before we describe the main components within them.

There are six types of environments:

• Default: This is automatically created in every Power Platform licensed tenant. It can be used for evaluating, proof of concepts, and so on, but should not be used for complex solution development or production.
• Trial: This is a temporary environment, best suited for testing specific product features, third-party solutions, demonstration purposes, and so on.
• Developer: This is a specific environment, provisioned with the Power Apps community plan license. This environment can have only the owner as a single user.
• Sandbox: This can be used for pre-production purposes such as development, testing, training, support, and so on. However, it is not intended for production purposes.
• Production: This is typically used for running a deployed solution in production.
• Support: This is a specific environment that cannot be created by the customer, only by Microsoft support personnel, in order to resolve service case issues. It is usually created as a copy of the existing troublesome environment and deleted after the issue is resolved.

  Tip

  Do not consider using the developer environment type for team development in large projects. It is only suitable for individual developers.

When created, every environment has some basic parameters that must be specified upon creation:

• The display name of the environment
• Environment type, which can be either a Sandbox, Production, or Trial environment
• Region, which is selected from a list of Power Platform-enabled regions
• The purpose of the environment as a free text description

In this step, you can also decide whether a CDS database should be created for the new environment.

If a CDS database should be created for the new environment, then the following additional parameters need to be specified:

• Language: This is the base user interface language of the CDS database and is used in all model-driven applications created in this CDS.
• Currency: This is the base currency of the CDS database used by currency data type fields.
• You need to either enable the deployment of some Dynamics 365 applications or a few sample model-driven applications with sample data.

If a CDS database isn't created for an environment, then no model-driven apps can be developed in that environment. However, it is possible to create a CDS database later, for already created environments.

Tip

The region, base language, and base currency of an environment cannot be changed once the environment has been created.

A Power Platform environment consists of the following main components:

• CDS and its components
• Power Platform connectors
• Data Loss Prevention (DLP) policies
• On-premises data gateway

In the following sections, you will learn more about these main components of an environment.

Common Data Service

Common Data Service is used to store the metadata, business data, and application artifacts of model-driven apps. The CDS storage is subdivided into the following three storage types:

• File: Used for storing files associated with business data such as attachments for email activities, files attached to any record within an annotation or file, and image data types.
• Log: Used for storing logging information such as auditing or traces from plugins.
• Database: Used for storing all other relational data.

Capacity restrictions

Within a Power Platform environment, as well as generally for the whole tenant, there are certain capacity restrictions that need to be considered when designing Power Platform solutions:

• Storage capacity limits
• Request limits and allocations
• API limits

These restrictions will be described in more detail in the following sections.

Storage capacity limits

Storage capacity limits apply to all Power Platform environments created in one tenant together. There are separate capacity limits for the file, log, and database storage types, and the capacity depends on the various Power Platform license types and number of user licenses a customer has purchased. Currently, the basic storage capacity every new customer gets with their first subscription is as follows:

• File: 20 GB
• Log: 2 GB
• Database: 10 GB

The following environments are excluded from the storage capacity limits:

• Trial
• Preview
• Support
• Developer

It is important to plan accordingly with regards to how many and what type of environments need to be created in order to stay within these limits.

Tip

Microsoft offers the possibility to purchase additional storage capacity add-ons to increase the available storage within the tenant.

The concept of storage capacity limits is illustrated in the following diagram:

Figure 3.2 - Storage capacity limits

As we can see, the database storage capacity, the file storage capacity, and the log storage capacity from all the environments in a tenant are added together and compared against the capacity limits.

Request limits and allocations

These limits apply to every individual Power Platform environment separately and limit the number of requests any individual user can make against the Power Platform CDS solution within a 24-hour period. Requests that count toward these limits can come from the following:

• Interactive end user work
• API calls against the CDS
• Canvas apps or Power Automate communication with the CDS using the CDS connector

The values of the request limits depend on the license type the user communicating with the platform has. These vary between 1,000 and 20,000 requests per 24-hour interval.

Tip

Microsoft allows us to purchase capacity add-ons to increase these request limits.

API limits

These limits apply to every individual Power Platform environment separately, but only for API requests. These are evaluated automatically in 5-minute windows for every web server within a scale group. The following measures are evaluated regarding the API limits:

• Number of requests
• Execution time
• Number of connections

These limits can have negative performance impacts on Power Platform integration solutions and specifically on the data migration process, which is usually performed as part of the solution's deployment.

Tip

If you consult the Microsoft Power Platform documentation, you will see that there are recommendations on how to handle the signals coming from the platform in case the API limits are exceeded. Please refer to the following article: https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/api-limits.

Let's move on to the next section, where we'll learn about Power Platform connectors.

Power Platform connectors

Power Platform connectors are basically wrappers around certain APIs provided by various Microsoft and non-Microsoft services. These connectors allow us to connect to services from canvas apps, Power Automate flows, and Azure Logic Apps. There are three types of connectors:

• Standard connectors are not bound to any licensed technology and can be used with any subscription; for example, with a Microsoft 365 subscription.
• Premium connectors require a Power Apps subscription in order to be used.
• Custom connectors are connectors developed by a customer for connecting to a certain technology, for which there is no public connector available or the public connector capabilities are not sufficient for the implementation.

Power Platform connectors offer the following capabilities for canvas apps and Power Automate flows:

• Tables are available for certain connectors in canvas apps and make it possible to connect the data source behind the connector with canvas apps controls (gallery, data card, and so on). The CDS connector is an example of a connector that provides the Tables property.
• Triggers are available for certain connectors for Power Automate flows to start the flow of execution. For CDS connector, for example, there are triggers such as the following: Record created, Record updated, Record deleted, and Record selected available. Record selected is an indirect trigger since the flow is triggered manually by the user from a model-driven application.
• Actions are available for certain connectors for both canvas apps and Power Automate flows and are basically executions of changes in data or other manipulations, performed by the connector from within a canvas app or Power Automate flow. For CDS connector, for example, there are actions such as Create record, Update record, Delete record, Get record, and many others available.

DLP policies

DLP policies are connector-targeted policies used within an organization to protect organizational data from unintended exposure. For example, this could happen when a Power Automate flow reads some internal financial data from a database and submits it to social networks.

DLP policies can be created on two scope levels:

• Tenant level: This is valid across all Power Platform environments in the tenant.
• Environment level: This is valid only in the respective selected environments, or in all tenant environments except the selected one. These policies cannot override the tenant-level policies.

These policies define rules for what connectors can be used together in a solution to effectively block their possible dangerous exposure. The DLP policy can place these connectors into any of the following groups:

• Business data: Connectors in this group can be used only in combination with other connectors from this group, not with any connectors from the other groups. This group is initially empty and the DLP configuration will require putting the selected sensible connectors into this group.
• Non-business data: This is the default group that all the connectors are initially part of.
• Blocked: Connectors in this group are entirely blocked within the specified scope and cannot be used in canvas apps and Power Automate flows.

By default, no DPL policies are created in a new Power Platform ecosystem. It is important to understand that a combination of multiple DLP policies always leads to the most restrictive result.

On-premises data gateway

On-premises data gateway is a specific software solution for hybrid scenarios, enabling the use of a user's own on-premises data sources within the following Microsoft cloud services:

• Power Apps
• Power Automate
• Power BI
• Azure services (Azure Logic Apps, Azure Analysis Services)

There are two different types of on-premises data gateway:

• On-premises data gateway: This can be shared among multiple users.
• On-premises data gateway (personal mode): This can be used only for one user and only for Power BI.

An on-premises data gateway technically consists of the following components:

• On-premises data gateway cloud service
• Azure Service Bus
• On-premises data gateway local installation

This is illustrated in the following diagram:

Figure 3.3 - On-premises data gateway architecture

The respective components of the gateway are responsible for encrypting and decrypting the on-premises data source's credentials, connecting to the data sources, routing the requests from the cloud and the responses from the on-premises data sources, and so on. The use of the Azure Service Bus component in the architecture provides a significant security benefit, since the connection between the on-premises data center and the cloud is always outbound. This capability makes it possible to use an on-premises database to cloud connection without the need to open any inbound communication, thus exposing the internal network to potential attacks guided by malicious players.

Now, let's learn about Power BI's structure.

Learning about Power BI's structure

Power BI is technologically different from the other components of the Power Platform, and Power BI is not integrated into the concept of Power Platform environments. Power BI's structure consists of the following elements:

Figure 3.4 - Contoso Inc. example structure of the different Power BI services

The different components in the Power BI hierarchy are used for the following purposes:

• Capacity is a Power BI concept that's used for a set of infrastructure resources (compute power) to run the Power BI service. There are two types of capacities – shared, where the resources are shared among multiple customers, and dedicated, where the resources are exclusively used by one customer. The dedicated capacity requires a Power BI Premium license.
• Workspaces are containers for other Power BI components (datasets, dataflows, workbooks, reports, and dashboards).
• Datasets are data collections used directly as data sources for Power BI reports.
• Dataflows are data sources prepared for pushing into datasets.
• Workbooks are specific datasets based on Excel.
• Reports are the main visualization objects created in Power BI using one single dataset.
• Dashboards are collections of tiles, widgets, and visualizations coming from multiple reports and other sources.

In this section, we learned about the Power Platform architecture. We also learned about the Microsoft cloud infrastructure and the Customer Cloud structure, along with their central tenant services. We also learned about Power Platform technology and Power Platform environments, along with its components. Finally, we learned about the structure of Power BI.

In the next section, we'll understand the various types of clients available in Power Platform.