D365 BC F.A.Q. 4 | Take a tour behind the scenes in the Dynamics 365 BC service

In this post, I’m taking you on a tour behind the scenes in the Business Central service. In particular, I will talk about how we have hardened the Business Central Server tier inside the data plane and introduced a new micro service that we call Licensing Service.

Let’s start the tour: Behind the scenes in Dynamics 365 Business Central Service

Licensing in Business Central is not where you would look to find the most innovative changes. For the online version, we did do some interesting things when we moved licensing from the classic license files to service plans in Azure AD subscriptions, but it still remains an area with very few changes compared to the rest of the product – well perhaps until now.

Running an online service comes with its own set of challenges. Many of them being related to securing and protecting the service from unwanted usage (see #1 if you are interested in this topic). With the move to service plans in Azure AD subscriptions, we found we had a challenge in protecting the lookup to Azure AD. We simply couldn’t allow the logic to execute on the Business Central Server tier (formerly Dynamics NAV Server) in case it was breached.

Welcome Licensing Service! This new micro service is built to protect the lookup to Azure AD and deliver licensing information to any Dynamics 365 Business Central Server asking for it. It may not seem like a big deal, but this involves quite a significant chunk of the logic that is required to start a new session. This logic has now been moved out into its own process and is even shared between several Business Central Servers running on different machines. As you can imagine, our deployment story just got a lot more complicated. Even though we’re using Service Fabric (#2), we still need to take into account that the service might not be on the same machine as the Business Central Server (#3).

There are many challenges in taking out a piece of the Business Central Server and putting it in its own process. Often, it is not the code causing the challenges but the dependencies and the interaction. As the two parts can now move independently, the interface between them must be set in stone. We can’t just add another parameter or require you to call a new method. This might work in a monolith like the Business Central Server, where we can fail to compile and show meaningful error messages if you fail to do the right thing. But for the licensing service, we must keep a strict versioning strategy for the interface. So, we added some rules; any change to the interface is automatically a new version, and we must design any change with the intent that you can continue to use the old interface. This means that when we release version 3.0, the service should still support 2.x, and so on. Naturally, this can’t continue forever, so we also need to keep track of what versions are used in production (done through telemetry), and only discontinue a version when there are no more consumers out there.

It’s an interesting change in the way we think. We have been used to similar thinking in Cumulative Updates. However, when it comes to a major release, all bets are off and we could easily break any consumer. This is no longer an option between the services. We must make sure an interface is alive as long as there is a consumer.

With the new Licensing Service, we also introduced another small service; Tenant Directory. This service is just in its early state and currently provides tenant information that is similar to what you would find in the application database when running a multi-tenant service. It might seem strange to have the same data in a separate service, but it allows us to validate callers to Licensing Service against a Business Central Server independent source (#1). And, it marks the beginning of more interesting and complicated things to come regarding what we in the product team refer to as the Data Plane; the collection of services making up a cluster that services tenants on Dynamics 365 Business Central. Already a place of many more services than mentioned here.

The future looks very interesting. For the on-premise installation of Dynamics 365 Business Central, you will still see the mighty Business Central Server as the sole service to install. It might change, but for now, there are no plans to dethrone the king. For the cloud, it is a different story. We have already begun a journey to split up the Business Central Server, and we’re actively working on new services. Soon, new gateway and tenant balancer services will direct tenant users to a “hot seat”, that mean, they will point them to the same service tier. This will make sure we minimize the number of times users have to load everything for the first time. And it doesn’t stop there. We continuously monitor the performance of the online service, and I am confident it will generate many more new services that provide new functionality or lift existing logic out of the application or Business Central Server.

The next FAQ is on how to Find the right resources and provide feedback for Dynamics 365 BC!

If you want to try this but don’t yet have a Business Central trial, that’s an easy fix. Just contact us!

Re-posted from Microsoft | Dynamics 365 Business Central Blog