Blog_Image_Title.jpg

How to Build Multi-Tenant App Delivery in the Cloud

Rob Waggoner

Creative work of business team.jpeg

If you build applications that you sell to customers, you’ve probably thought about how the cloud could help deliver your application to more users faster than the traditional on-premises model.

Single vs. Multiple Infrastructure
When you look at delivering your solution to multiple customers, does that mean you need a separate infrastructure for each customer? Maybe, but not always. You may be able to build a single infrastructure in the cloud, then provision portions of that infrastructure for each customer. The decision on a single vs. multiple infrastructure is really based on the data security built into your application.

If you have an application that can separate customer data based on the users’ credentials, you may be able to host your application for multiple customers on a single RDS infrastructure. If your application does not have its own security model, or at least a security model based on the user credentials, you will most likely need to build a separate infrastructure for each customer.

That said, if your application can manage data security based on user credentials, the “multi-tenant” model, which is my favorite, is where a single RDS infrastructure is built, and then each “customer” has a separate RDS, or RemoteApp collection. Check out this blog that talks about the different architectures we can build for you. For our multi-tenant customers, the Standard RDS or Standard RemoteApp architectures are the best option.  If you need separate infrastructures, the basic RDS or RemoteApp architectures may be more cost effective if you have 6 or fewer users. More than 6 users, per deployment will be more cost effective using the Standard architectures.  For the rest of this discussion, I will focus on the Standard architectures.

When I talk about one collection per customer, for full desktop delivery for each customer, it would look something like this.

Full desktop delivery.png

As you can see, there is a separate collection for me (Rob), then an additional collection for Customer 2 and Customer 3. For this scenario, Customer 3 even needs the high-end graphics capabilities in Azure, so I added that as part of the customer’s name. Each collection can have one or more session hosts, this model gives you the ability to size each collection to support each customer you support.

Next, we will look at the overall Standard RDS architecture below.

Standard RDS.png

This architecture includes a RDS Management Server (Purple VM) and a separate Gateway Server (Green VM).  The separate Gateway Server allows this deployment to scale up to hundreds of simultaneous users with a single architecture.  All of the users will only connect to the RD Session Host Servers (the Red VMs).

The value of a multi-tenant model with the standard RDS architecture is that it shares the same management and gateway server, thus reducing the per user cost as you increase users within the deployment.

Want Future Tips Emailed Right to Your Inbox?
Subscribe to Our Blog