Multi Tenancy concept as against the concept of Enterprise environments viz.: Dev, UAT and Production

Help
1

Hello,

I am trying to understand the exact usage of Multi-Tenancy from the point of view of Orchestrator instances as well as from the point of view of having separate infrastructure set-up environments viz, Dev, UAT and Prod. (And, Not the UiPath ‘Environment’ terminology)

What would be the best practice / guideline or recommended way to set up infra for below?

  1. If an enterprise wishes to have Dev, UAT and Prod environments for RPA development, then would it need to create Three-Tenants within the Same Single Orchestrator Instance?
    -OR-
  2. Would it create Three Separate Orchestrator Instances each having a Single-Tenant which means one Orchestrator instance each for Dev / UAT / Prod?

In a nutshell, is Multi-Tenancy the right way to have separate set-up for Dev / UAT / Prod environments within an enterprise doing RPA Development using UiPath?

Thanks!

2 Likes
2

Right now, we have dev/test as two tenants in a single orchestrator instance, and a completely separate prod orchestrator. Prod needs to stay separate so changes can be made to UiPath components (e.g. upgrades, patches, etc) without affecting anything already in production. Changes can be thoroughly tested prior to releasing in prod.

In the future, once we have business-critical robots in production (we currently only have lower-risk processes automated with RPA), we will have completely separate dev, test, and prod servers. Done this way, there will always be a lower environment available to support production. Upgrading to a new version would first be done on dev only. Test/prod would remain on previous stable version. This way if something happens to robots in prod, a stable release would still be available in test to fix any issues that arise. Once everything has been thoroughly tested in the dev environment, it can then proceed to test/prod.

1 Like
3

Hi Dave,

Thanks much for the response.

So, 2 points from what you say:

  1. General recommendation would be to use DEV, TEST, STAGING / UAT, PROD, as separate Orchestrator instances. (Well, at least Prod for sure if not the others).
    Correct?

  2. It is valid / recommended from UiPath as a guideline to use the concept of Multi-Tenancy to create DEV, TEST, UAT, ETC., as separate infra/set-up, if and organization/enterprise wishes to have only a single Orchestrator instance for ALL Except PROD…
    Correct?

Thanks!

4

Hi,

This is an interesting topic and something I have been wondering myself. In the previous versions the concept of multi tenancy has been “experimental”, so first of all is this stable now?

Second, what are the recommendations in regards to multiple Orchestrator instances vs. Multi tenancy from UiPath? Currently one of the projects I am working on, they are considering using multi tenancy vs. investing in a new Orchestrator license.

I would love to know the pros and cons here, so anyone from UiPath, please share :slight_smile:

5

It is no longer considered expiremental.

For your second point, you will still need a license for each tenant. The marketing materials from UiPath show that they meant for it to be used for discrete business units (Operations, Finance, HR, etc) so they can’t see each others processes/assets/queues/etc.

6

Thanks for the reply @Dave

I see. But couldn’t you technically separate this by environment? So instead of Operations, finance, HR, you could have Dev, test, prod? Or is there any other restrictions i am not aware of?

Orchestrator licenses are quite expensive, especially if a customer only have 1 or 2 robots, and i think the functionality in orchestrator is becoming more and more critical if you want a professional RPA environment.

1 Like
7

Hi,

I am in the same dilemma as you were. How did you finally setup your environments’?
I am thinking separate Orchestrator instance for each DEV,SIT,UAT and PROD. What are the cons?

Thanks.