For many organizations, the Power BI service is only a part of an existing and broader cloud-based data and analytics environment. For example, the organization may already be using the Azure Data Lake Store (ADLS), Azure SQL Database, or Azure SQL Data Warehouse cloud services to store and process data for reporting analysis. In other organizations, the adoption of the Power BI service as a primary BI and collaboration platform may be part of a larger migration from an on-premises BI environment to the cloud. As one example of this migration, existing extract-transform-load (ETL) packages executed via on-premises SQL Server Integration Services (SSIS) servers could be moved (lift and shift) to virtual machines (VMs) in Azure and managed through the Azure Data Factory cloud service.
Even if neither of these two scenarios applies in the short term, an organization may still choose Azure Analysis Services over SSAS to reap the cost, performance, and agility benefits (scale-up/down) of this PaaS offering. With an Azure Analysis Services instance storing the data model(s) queried from Power BI within the same data region as the Power BI service tenant, the report and dashboard queries generated by Power BI avoid the latency incurred by accessing an on-premises SSAS instance via the On-premises data gateway. If data source(s) of the Analysis Services model remain on-premises, the same On-premises data gateway described in Chapter 9, Managing the On-Premises Data Gateway, can be used to support a recurring data refresh process of Azure Analysis Services models from on-premises sources.
Perhaps even more importantly than query performance, Azure Analysis Services dramatically reduces the following challenges with deploying SSAS at scale in enterprises:
- Planning server resource requirements:
- It's difficult to accurately predict how much CPU and RAM will be needed by an Analysis Services server, even for the next 1-2 years. Additionally, the optimal hardware for Analysis Services, such as CPU clock speed and NUMA Awareness, is sometimes not fully communicated or delivered when provisioning these servers.
- With Azure AS, optimally tuned Analysis Services resources can be quickly and easily aligned to changing needs of the workload by switching pricing tiers.
- BI teams can even schedule Azure AS resources to be scaled up at certain times to support high query volumes (such as every Monday morning) and then scaled down or even paused at times of low query volume such as nights and weekends.
- Installation and server maintenance:
- In an on-premises environment, SSAS has to be installed on the provisioned server and the server itself has to be managed and patched.
- As a PaaS offering, Azure AS servers are fully installed once deployed and the underlying servers are maintained by Microsoft to support 99.9 percent availability.
- Implementing scale-out:
- Provisioning the read-only query servers, the processing servers, and configuring load balancing can take weeks or longer in on-premises environments.
- As depicted in the Scale section earlier, Azure Analysis Services provides a graphical interface to easily configure a pool of read-only query replicas for distributing or balancing query requests.
These considerations specific to Analysis Services, as well as the broader advantages of a cloud architecture, serve as powerful motivation to choose Azure Analysis Services over SQL Server Analysis Services. For example, new features and enhancements to Azure Analysis Services are released more frequently than versions of SSAS, and some of these new features such as the Azure Analysis Services web designer are exclusive to the cloud service. Additionally, Azure AS instances are able to benefit from new capabilities and ongoing investments in other Azure services such as Azure Automation and Azure Functions. This is similar to the advantage of the Power BI service over the Power BI Report Server as described in Chapter 10, Deploying the Power BI Report Server.