What's New in NAV 2013 R2 Part 1: Multi-tenancy
Multi-tenancy is a principle of software architecture where a single instance of the software runs on a server and supports multiple customers or tenants. The overarching principle to multi-tenancy is to have zero-overhead for each tenant. In other words, it is a shared application.
That sounds like a simple idea on the surface, and to be honest it is. Where it gets complicated is turning NAV into a multi-tenant capable system. Let’s take a look at the pieces of NAV architecture and what would need to change to make this work.
If NAV is to keep to the tenets of multi-tenancy that means that customers who decide to go this route will all connect to the same service tier. The purpose of the service tier is to act as the intermediary for client requests to the data. The first major concern is keeping the customer’s data segregated from each other. We obviously don’t want to change the whole database structure for the application by adding something like a Tenant ID field to every table, so the service tier will have to connect to multiple databases. This will be controlled with a new configuration file on the client side that tells the RTC which service to connect to and which databases they have access to.
Next, because there is only a single service tier, there is only one code base. That means every customer shares the same customizations (if there are any). In order to maintain the tenet of zero-overhead per tenant there cannot be any customer specific customization. You might have a set of canned reports that can be used in report selections, or expand upon existing Dimension fields to an extent, for individual customers, but you can’t change posting routines or add new fields to pages without affecting everyone.
Finally, since there is only one code base, it doesn’t make sense to replicate that into each customer database. Therefore the traditional NAV database has been split into two: one for the application data and one for the customer data. The application database contains tables common to all databases and the objects, while the actual customer database contains the tables like Sales Header, Sales Line, Windows Login, and Windows Access Control. Synchronization of tables will be performed automatically so you don’t have to import objects into multiple databases. It is also required to split the database because the current development environment (old Classic Client) can only connect to a single database. This means you can backup customer data and maintain your intellectual property for the application.
Now that’s a lot to digest. You may be saying “What is Microsoft thinking in effect taking away customizations? Why are they taking away NAV’s biggest selling point, easy customization?” It’s important to understand that this is not the case at all. Multi-tenancy is optional. In reality, you are already running in a multi-tenant environment, you just happen to not be sharing it with anyone. This option will likely be for smaller customers who want to get a taste of what NAV is all about without committing to the product completely. Then they can graduate to a single tenant or on-premise solution where they can customize as much as they want. In reality this is getting more customers in sooner.