With the release of Microsoft Dynamics NAV 2013 R2, one of the topics of discussion this autumn has been the newly supported multi-tenant architecture.
Multi-tenancy is a principle in software architecture where a single instance of the application runs on a server (or group of servers) and serves multiple clients or tenants. Multi-tenant hosting for Dynamics NAV 2013 R2 is available to be run on both Azure cloud and partner-hosted deployments.
How the NAV architecture has evolved since 2009 | Source
But it’s important to note that multi-tenancy is not expected to be a common deployment approach for NAV customers.
“Multi-tenancy is optional,” said Freddy Kristiansen, a Dynamics NAV software architect with Microsoft, in his session at last week’s NAV Tech Days event in Antwerp (recording can be found here). “NAV is still capable of running single tenancy exactly as it was before and Microsoft doesn’t have any plans to change it.”
Kristiansen explained that multi-tenancy for NAV isn’t intended to be used with traditional Dynamics NAV installations, whether hosted or on-premises because the majority of those installations have customizations and add-ons.
“Multi-tenancy is all about having a lot of customers running the same application,” he said. “It’s targeted at giving partners the opportunity to pursue new and repeatable business in the cloud where their customers can sign up for a hosted solution based on NAV, with very limited customization capabilities.”
Multi-tenancy also lets partners more easily add new customers to their solutions, and roll out updates quickly with limited downtime, Kristiansen said. A multi-tenancy deployment also cuts down on server costs because multiple customers are sharing the cost. And one customer doesn’t have to worry about another customer seeing its data.
“Multi-tenancy was designed for a larger number of customers running the same app,” he said. “With multi-tenancy every customer gets a tenant and the users who are connecting to that tenant will be unable to see data from the other tenants. Tenant data is put in different databases and [you cannot] connect to the database of a different tenant.”
Multi-tenancy is also about how many simultaneous users want to run on one server, Kristiansen said.
“If you have a number of separate legal entities and you want those guys to run on the same app, multi-tenancy is the way to go,” he said. “If you only have five customers it’s not worth the effort. Maybe with ten, it’s worth the effort. But with hundreds and thousands of customers – yes.”
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 or 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 challenge for the Dynamics NAV team was to design an architecture with thousands of tenants that only occasionally access the system,” according to a blog post by Arend-Jan Kauffmann, a development manager for Dynamics NAV, at Microsoft partner at Xperit Group B.V., in the Netherlands.
The multi-tenancy 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,” Kauffmann said. “Data is separated in tenant databases. One NAV Server Tier (NST) can serve one application database and multiple tenant databases. [On] 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.”
Matt Traxinger, ArcherPoint’s resident Dynamics NAV MVP, explains multi-tenancy this way: “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’s a shared app, he added.
“That sounds like a simple idea on the surface, and to be honest it is,” Traxinger said. “Where it gets complicated is turning NAV into a multi-tenant capable system.”
In a blog post, Traxinger said if Dynamics NAV is to keep to the tenets of multi-tenancy, then 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,” he said. “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.”
Additionally, Traxinger explained that because there is only a single service tier, there is only one code base, which means every customer shares the same customizations – if there are any. In order to maintain the tenet of zero-overhead per tenant, customers can’t have their own customizations because their customizations would also affect all the other companies.
One attendee at NAV Tech Days asked Kristiansen how to deal with multi-country installations.
“You would have to run the same app, meaning you would have to put them into one,” he responded. “You’d have to combine them or if you cannot combine them, you’d have to run multiple services.”
Another attendee expressed concern that a username and password was the only security that stood between one customer and another customer’s data – no additional unique network or data center security elements.
“If you have access to a tenant’s username and password, then you have access to that data, yes,” Kristiansen said. “But that is the same as if you had my username and password you would have access to my email, right? If you were running an on-premise installation, you would have a firewall or something like that,” Kristiansen said. “But if you’re running a hosted service [today] you wouldn’t have that.”