1.1 Cloud vs On-Premises Architecture & Deployment Typologies

Cloud vs On-Premises Architecture & Deployment Typologies

Quick Answer: The MB-500 exam requires developers and technical architects to understand the structural divide between Cloud (SaaS) and On-Premises (Local Business Data / LBD) deployments. In the Cloud, Microsoft fully manages infrastructure, high availability (HA), disaster recovery (DR), Azure SQL Database, and Azure Blob storage, while enforcing the One Version continuous update cadence and providing cloud-native features like embedded Power BI. In contrast, LBD deployments require the customer to host and maintain their own hardware, deploy a standalone Service Fabric cluster, configure Active Directory Federation Services (AD FS), maintain SQL Server Always On Availability Groups, and manage local file storage. LBD lacks embedded Power BI, automated cloud updates, direct machine learning, and Azure Synapse Link.

---

1. Enterprise Architectural Overview: Cloud (SaaS) vs. On-Premises (LBD)

Dynamics 365 Finance and Operations (F&O) is architected as an enterprise multi-tier business application consisting of a web-based client presentation tier, an application compute tier (Application Object Server / AOS), and a relational data tier. While the underlying business logic written in X++ and compiled into Common Intermediate Language (.NET CIL) remains largely identical, the infrastructure topologies, data persistence mechanisms, security perimeters, and operational maintenance responsibilities diverge sharply between deployment types.

Architectural Tier Comparison

---

2. Core Architectural Components

Application Object Server (AOS)

The Application Object Server (AOS) is the core runtime execution engine for Dynamics 365 F&O. It runs as an ASP.NET Core / .NET application hosted inside Internet Information Services (IIS) worker processes or Service Fabric guest executables.

• Stateless Design: In both cloud and on-premises environments, AOS nodes are strictly stateless. User session states, active forms, and temporary cursors are preserved across database tables or distributed memory caches rather than tied to a single physical machine.
• Load Balancing: Client traffic is distributed across multiple AOS nodes using Azure Application Gateway / Azure Load Balancers in the cloud, or hardware/software load balancers (such as F5 or Windows Server Network Load Balancing) in LBD.

Dedicated Batch Server Roles & Processing

AOS instances can be configured to act as interactive web servers, dedicated background batch servers, or a hybrid of both:

• Batch Processing Architecture: The batch framework processes asynchronous tasks, scheduled jobs, and integration pipelines without impacting interactive UI responsiveness.
• Batch Groups & Server Affinity: Developers and administrators organize batch tasks into Batch Groups. By binding specific batch groups to designated AOS instances, organizations ensure that heavy computational tasks (such as overnight Master Planning, depreciation runs, or massive DMF imports) do not consume CPU or memory allocated to user-facing interactive AOS nodes.
• Priority-Based Batch Scheduling: Modern F&O uses priority-based scheduling to prevent low-priority maintenance jobs from starving business-critical financial postings.

SQL Server Reporting Services (SSRS) Architecture

• Cloud SSRS: In cloud SaaS environments, SSRS runs on dedicated microservice nodes managed entirely by Microsoft. Reports are rendered into PDF, Excel, or Word formats and streamed directly back to the browser or routed to physical on-premises network printers via the Document Routing Agent (DRA).
• On-Premises SSRS: In LBD deployments, SSRS must be installed and configured on customer-provided Windows Server nodes integrated with on-premises SQL Server instances and configured within the local Service Fabric cluster topology.

Data Management Framework (DMF) Integration Boundaries

The Data Management Framework (DMF) provides high-volume asynchronous batch import/export, data entity staging, and integration packages:

• Cloud Storage Boundary: In the cloud, the DMF staging pipeline relies entirely on Azure Blob Storage. When an integration pushes a data package via the DMF REST API, the package is placed in a secure Azure Blob container using Shared Access Signatures (SAS). AOS batch workers retrieve the package, parse the source files into staging tables, and commit them to target transactional tables.
• On-Premises Storage Boundary: In LBD, Azure Blob Storage is not accessible for internal staging. Instead, the Service Fabric AOS nodes utilize a high-availability customer-managed SMB network share (UNC path). If this network share experiences latency or permissions misconfigurations, DMF batch jobs fail immediately.

---

3. Capabilities Unavailable or Restricted in Local Business Data (LBD)

One of the most frequently tested areas on the MB-500 exam is knowing which advanced capabilities cannot run in an on-premises LBD topology. Because LBD lacks direct native connectivity to Microsoft's hyperscale cloud fabric, the following features are completely unsupported or severely restricted:

1. Embedded Power BI Analytical Workspaces:
   • In cloud deployments, rich Power BI analytical reports and dashboards are embedded directly inside F&O workspaces via Azure Analysis Services and Power BI DirectQuery.
   • In LBD, embedded Power BI is unsupported. Users must rely on standard operational SSRS reports, Electronic Reporting (ER), or build external standalone Power BI Desktop models connecting via custom SQL views or OData endpoints.
2. Automated Continuous Updates (One Version):
   • Cloud environments receive automated monthly or bi-monthly service updates orchestrated directly by Microsoft Lifecycle Services (LCS).
   • In LBD, automated servicing is unavailable. The customer IT team must manually download Software Deployable Packages (SDPs) from LCS, distribute them to local infrastructure, and execute the installation via the on-premises Service Fabric deployment scripts and LCS Local Agent.
3. Azure Synapse Link & Microsoft Fabric Direct Export:
   • Cloud environments can continuously stream transactional entities to Azure Data Lake Storage Gen2 and Microsoft Fabric in near-real-time using Azure Synapse Link.
   • LBD does not support Synapse Link. Organizations requiring external analytics must rely on legacy data export strategies, such as custom batch exports or direct database staging.
4. Direct Cloud Machine Learning & Cognitive Intelligence:
   • Features relying on Azure Machine Learning (e.g., Cash Flow Forecasting, Customer Payment Predictions, Intelligent Order Management recommendations) are native to the cloud.
   • These cognitive predictive services cannot execute natively within an isolated on-premises LBD data center.
5. Mobile Workspace Push Notifications:
   • While the Dynamics 365 Unified Operations mobile app can connect to LBD via configured edge proxies, cloud push notification hubs and background push triggers are unavailable.

---

4. Scenario Walk-Through: Architectural Topology Selection

Scenario: Global Manufacturing & Retail Conglomerate (Contoso Global)

Contoso Global operates corporate headquarters in North America with 45 retail stores and 4 manufacturing facilities. They also operate an ammunition and defense contract subsidiary governed by strict national data sovereignty regulations prohibiting any financial, bill of materials (BOM), or inventory records from leaving on-premises domestic hardware.

Architectural Decision Process:

1. Corporate & Retail Entities (Cloud SaaS):
   • Deployed on Microsoft-managed Azure Cloud.
   • Leverages Azure SQL Database with zone-redundant high availability and automated disaster recovery across paired regions.
   • Enables Embedded Power BI for real-time retail store sales performance monitoring.
   • Integrates with Power Apps and Power Automate via Dataverse Dual-write.
   • Enforces Microsoft Entra ID authentication with Conditional Access and Multi-Factor Authentication (MFA).
2. Defense Contract Subsidiary (Local Business Data / LBD):
   • Deployed as an on-premises LBD cluster on physical server racks within the subsidiary's hardened data center.
   • Managed via an on-premises Service Fabric standalone cluster.
   • Authenticated exclusively against local Active Directory Domain Services via AD FS.
   • Data stored in customer-administered SQL Server Enterprise with Always On Availability Groups.
   • Package staging routed through a high-availability local SMB UNC network share.
   • Custom analytical reporting delivered via SSRS and Electronic Reporting (ER) rather than embedded Power BI.

---

5. Real-World Exam Traps: Cloud vs. LBD

[!WARNING] Exam Trap 1: Assuming LBD can run Embedded Power BI Workspaces Many exam candidates assume that since Power BI Report Server exists for on-premises reporting, F&O LBD supports embedded analytical workspaces. This is false on the MB-500. Embedded Power BI analytical workspaces require the Azure-hosted Power BI service and entity store data feeds, which are strictly unavailable in LBD.

[!WARNING] Exam Trap 2: Believing Cloud SaaS Customers Can Indefinitely Pause Updates Under Microsoft's One Version policy in the cloud, customers cannot permanently freeze their application version. Organizations may pause up to three consecutive monthly service updates, but LCS will enforce a mandatory update before an environment falls out of Microsoft support boundaries. In contrast, LBD customers can remain on an older build indefinitely, albeit at the cost of losing support and security patches.

[!WARNING] Exam Trap 3: Confusing Identity Management Architecture The exam frequently presents questions where external systems attempt to authenticate against an on-premises LBD instance using Microsoft Entra ID (Azure AD) client credentials. LBD environments rely on Active Directory Federation Services (AD FS) for claim-based identity; they do not authenticate against Microsoft Entra ID natively.

[!WARNING] Exam Trap 4: DMF Storage Misconceptions in LBD Candidates often assume the Data Management Framework operates identically behind the scenes. In Cloud SaaS, DMF packages are staged in Azure Blob Storage containers via SAS tokens. In LBD, DMF staging occurs on local customer-configured SMB file shares. Writing X++ code that explicitly assumes Azure Blob REST storage APIs without abstracting through the DMFPackageExporter / DMFPackageImporter frameworks will fail in on-premises environments.