I want to confirm the best practice when setting up multiple environments (Dev/Test/Prod) in Orchestrator in an enterprise setting.
In this post, a user links to the official docs recommending the following multi-tenant approach:
By using more than one tenant, users can split a single instance of Orchestrator into multiple deployment environments, each with its own Robots, processes, logs, and so on.
I’m tempted to consider this the final answer and just run with it. However, in that same post the same user then says:
It’s even possible but not best practice to have all three on one Orch by using three different tenants.
I don’t mean to call him out but he seems to be contradicting his own link. Or maybe I’m misunderstanding something.
Similarly, this tutorial appears to corroborate the multi-tenant approach. However, that user mentions the terms “working” environment (aka Personal Workspace?) vs. “deployment” environment, and I’m not sure if they refer to the same thing. In addition, the comparison between classic vs. modern folders may be muddying up the waters for me.
Finally, in other posts some users recommend having a separate Orchestrator server for each environment. But that appears to be unnecessarily expensive / overkill.
So to confirm, is it the enterprise-level best practice to have one single Orchestrator server / instance containing multiple tenants, one for each environment?
The enterprise level best practice is to have a separate orchestrator instance for Dev/Test/Prod.
But with the modern folders , you will be able to achieve similar separation with the help of folder structure but having a separate instance for Dev/Test and Prod allows us to be more flexible .
we have an on premise orchestrator installation . with this , we are able to test the orchestrator upgrades and additional implementations like splunk in test before expanding this to the prod server.
Once the upgrade is complete in test , we can test out the Business crucial processes in the test and see how the impact of the upgrades will be , before proceeding with the upgrades in prod . This means no surprises
Thanks for the reply @vishnuvarthanp.
Ok so what I’m understanding then is that ideally the company would pay for multiple orchestrator instances. However, if that is not possible / desired, then the next best thing would be to have multiple tenants in one orchestrator instance.
Would that be the correct interpretation?
So …to answer your question let me give ypu scenarios…
When using on prem people prefer multiple orchestrators as it would be easier for upgrade of different environment…
But when coming to automation cloud the upgrades and load balancing is not taken care by us…which is much smoother…so a multi tenant would be good as per the licensing cost and the ease of access
Hope this helps
Thanks @Anil_G for that detail.
I was wondering whether Orchestrator on-prem vs Cloud would make a difference when answering my question and it appears that it does.
I should have mentioned that I’m talking about Orchestrator Cloud (and not on-prem) because that appears to make a big difference.
With the Cloud version, it seems like the multi-tenant approach is good enough, as explained by @Anil_G. On the other hand, with the on-prem version, multiple Orchestrator instances is probably best, as explained by @vishnuvarthanp.
Since my case is the former, I suppose Anil’s solution is the most relevant, although I appreciate Vishnu’s as well.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.