In this first post in the “Behind the scenes of a cloud service” series, we will give a high-level introduction to the overall service topology of Business Central in the cloud. Subsequent posts will dig deeper into specific parts or explore specific flows through the service, such as what happens when a user logs in, how upgrades are performed, etc. At a very high level, we divide our services into 3 categories: Global services Regional control plane services Regional data plane services Let’s look at these in turn, starting from the data plane, which is where the traditional Dynamics NAV/BC processing takes place. Regional data plane services The concept of “data plane” is borrowed from the networking domain, and it refers to the part of the networking architecture that receives and forwards network packets according to routing tables etc. The network packets are the data, and the data plane processes this data by sending it to the right destination. In contrast, the “control plane” in a networking architecture contains information about the data plane, i.e., it defines the routing tables etc., but it doesn’t process the actual network traffic. In Business Central, the “data plane” refers to the set of resources and services that process user requests, such as when a user presses “Post” on an invoice. It consists of the well-known components VMs NST Web client Database server Databases … and more As shown, the data plane is also where customer data is persisted (in the databases). The following picture shows the high-level architecture of a data plane cluster, and it should look familiar to most Dynamics NAV/BC partners: A cluster consists of several VMs, each running the Web client and the NST, and there are the usual databases, both the App DB and the Customer DBs (aka tenant databases). As more and more customers come to the service, we scale horizontally by adding more clusters (and databases): Finally, for several reasons, such as to comply with legal requirements about data locality, we split the data plane into geographical regions, hence the name regional data planes. At the time of writing, we have 6 regional data planes, each containing several data plane clusters: It is important to note that these 6 regions represent Business Central regions, not Azure regions. For example, at the time of writing, the Business Central West Europe region is utilizing the following Azure regions: West Europe, North Europe, UK South, UK West. The names of the regions should also be taken with a grain of salt. They are in many cases named like they are for historical reasons, and the names don’t necessarily represent today’s situation. For example, the US region also manages Mexican customers, and the Asia region also covers parts of Africa. Subsequent blog posts will go into much more detail about the data plane, but in this blog post we will now turn our attention to the control plane. Regional control plane services The control plane services in Business Central perform administrative operations such as: · Creating a new data plane cluster · Creating a new tenant database · Upgrading a tenant · Installing an extension · Deleting a tenant database · Etc. As explained in the previous section, user requests are served by the data plane, not by the control plane. For example, when a user logs into Business Central and works with it, the control plane services are generally not aware of it and will not do anything. There are exceptions to this rule, however, such as when a user logs in for the first time, and the tenant database needs to be created. Another example is when a user installs an extension. The control plane is also activated when Microsoft performs management operations such as scaling out by adding new data plane clusters, or when rolling out platform hotfixes. Each control plane is implemented as one cluster of VMs as well as some other resources (not shown). The following picture shows one control plane cluster including two of the services that run inside it: Like the data plane, the control plane consists of 6 regional control planes, each corresponding to a data plane: Global services The regional setup of both the control plane and the data plane is useful and even necessary, but it also introduces complexity. How does an end user find his/her tenant database and cluster? We cannot expect the end user to type https://dataplanecluster14.uksouth.cloudapp.azure.com?tenant=msweuat1511242 in the browser. As you probably know, the user can in fact simply type https://businesscentral.dynamics.com in the browser, and the service still finds his/her data plane cluster and tenant database. If two different users from two different companies both go to https://businesscentral.dynamics.com, they end up in their respective tenants. This is achieved using a global service that listens on https://businesscentral.dynamics.com, and performs the following steps when a user connects: 1. Authenticates the user to identify the customer (i.e., the AAD tenant that the user is a member of) 2. Finds the customer’s Business Central region 3. Finds the customer’s data plane cluster 4. Finds the customer’s tenant database 5. … and then starts talking directly to the Web client in the correct data plane cluster The term “global service” signifies that it can handle requests for all Business Central customers in the world. For several reasons, including fault tolerance and low latency, we create multiple instances of the global services, but this is transparent to the end user. A user who enters https://businesscentral.dynamics.com in a browser will be routed to the instance that is closest. In the following picture, we show that the global services are deployed in two instances across the globe, however, this varies by service. We hope that you found this overview of Business Central in the cloud useful. If you have questions or feedback, please feel free to leave your comments below, or contact us directly.