Directions EMEA 2013 – Multitenancy

It was really a very interesting week. Directions EMEA in Vienna was all about Microsoft Dynamics NAV 2013 R2. And of course about all the very interesting products that NAV partners offer. There were so many sessions that I sometimes had to choose between two or more sessions while I wanted to visit all of them. Besides that I attended several workshops in order to get hands-on experience. The materials for these workshops can be found here: https://mbs.microsoft.com/partnersource/newsevents/news/msdnav2013workshops.htm

Thanks to the Directions committee

Let me first give a very well deserved compliment to the Directions committee. They have done a really tremendous job. Almost 1000 attendees, over a 100 sessions, a strike at the airport of Copenhagen so speakers couldn’t make it on time, it was definitely a very tough week. Congratulations, well done! And I wish you every success with organizing the event next year in Poznań, Poland.

With this post I would like to share some details about multitenancy, one of the new major changes in the architecture of the NAV Server Tier.

Multitenancy

Version 2013 R2 introduces the concept of multitenancy to Microsoft Dynamics NAV. This is a principle in software architecture where a single application instance serves multiple client organizations (tenants). It differs from multiple-instance architectures where each client organizations has a separate application instance. Multitenancy is considered to be an important feature of cloud computing. It enables a maintainable and scalable application. The multitenancy architecture is a repeatable architecture, which exactly matches the goal for Microsoft Dynamics NAV.

The challenge for the Dynamics NAV team was to design an architecture with thousands of tenants that only occasionally access the system. They have reviewed different scenario’s like multi-company, multi-instance or multi-server.

The multi-company scenario was considered a wrong option. In C/AL it is very easy to do cross company actions. Is does not seem to be very secure to have your administration sitting in one single database with other administrations.

Multi-instance, e.g. multiple NAV Server instances on one server was tested. It scaled nicely up to 7 servers, but then became rapidly slower and slower. Not a good alternative for a repeatable scenario with thousands of customers.

Cost sharing between tenants is key part of a repeatable scenario. Users that occasionally connect to the system should not pay for having a complete server up and running, waiting for them to connect. Idle time is expensive and therefore resources should be shared with other users. So multi-server is not a good architecture for a repeatable scenario with many customers.

The only architecture that addresses al the challenges appeared to be a multitenancy architecture. The multitenancy architecture in NAV 2013 R2 consists of a single application database and multiple data databases. The application database only serves as a source for metadata and source code. Data is separated in tenant databases. One NAV Server Tier (NST) can serve one application database and multiple tenant databases. At the other hand the application database and tenant databases can be opened by multiple servers. They even can sit on different SQL servers. This makes the model very flexible and scalable.

There is a lot to learn about the details of multitenancy mode for NAV 2013 R2. This would really become a long post if I would discuss every single detail. Let’s just list a couple of features of multitenancy:

Configuration

The NST can run in two different modes: single tenant or multi tenant mode. The single tenant mode is what we know from NAV 2013 RTM and NAV 2009. It is still available and as such it is backward compatible. The multi tenant mode enables new capabilities.

License

License can be in the tenant database and in the application database. When the tenant has no license, then the license from the application database is used.

Separation of application and tenant database

It is possible to have tenant and application in the same database, but that seems not to be very logical. Standard single database deployments (no multitenancy, one database per NST) have in fact one single tenant, called the default.

The system tables are separated. The application database and tenant database have a different set of system tables.

De Development Environment can only access application databases. Tenant databases cannot be openened in C/SIDE.

Backup

Since every tenant is a regular SQL database, it is possible to individual backup a tenant.

Updates

The NST is responsible for applying changes in the database schema to the tenants. This means that importing a fob in the application database will not immediately change the database schema. The Development Environment is only responsible for updating the metadata.

It depends on how a tenant is mounted if a change in the database schema that would result in data loss will be forced or not. If not, the tenant that would have loss of data will be dismounted. Therefore it is extremely important to be very careful with updates in a live environment.

When unmounted tenants are mounted again to a NST, the tenant will be updated to the latest database schema.

In the normal single database deployment the Development Environment can ask the NST if an update would result in loss of data and immediately show an error, just like it is today.

Management

The NAV environment can be managed by using PowerShell commandlets. There are cmdlets available for management of tenants. This varies from deployment of new servers to create or copy a company in a tenant. There are How-to scripts included on the DVD to show how these cmdlets can be used.

This post is based on the notes I made during several sessions and workshops. So I might have missed a couple of features. Nonetheless, this is the big picture, and I will try to dive into details in future posts. Stay tuned!