How to deploy a service multiple times for multiple tenants

Advice
1

Hi there,
we just started designing our deployment process in Octopus and so far everything works flawless. :+1:

So, we have a white-label software that we deploy to 5 different customer systems, each with a testing/prod environment. We created 5 tenants for our customers and have a deployment process running for that. Let’s name them “customer1… to customer5”.
Each of our customers is again serving 2-15 customers with our software. We created tenants for each customer’s customer and have a second project that deploys stuff specfic for that “subcustomer”. That works fine so far. Let’s name them “customer1:subcostumerA…to customer1:subCustomerZ, customer2:subCostumerA…to customer2:subCostumerF and so on”
Now, we have a third party software (a windows service) that needs to be deployed 1-5 times per subCustomer.

I found something like this here. The advice there is to add additional tenants for each service.

I’m tempted to do this and add a multitude of tenants, using tags to group them. We’ll end up with > 100 tenants for this specific service then. My questions are:

  1. Is that a valid solution?
  2. Or is there something like “tenants-in-tenants” I’m missing?
  3. Is it ok to use multi-tenancy for different purposes ("customers as tenants and “multiple 3rd-party-services as tenants”)?
  4. If we go the way described above: Is there a limit of tenants or something else like that?

Thx a lot!

3

Hi @dennis.h,

Firstly, let me welcome you to the Octopus community, it is great to see you here :wave:

Thank you for reaching out with your questions surrounding Tenants.

From the sounds of things, you are getting on well with you implementation for Tenants, this is great to hear.

If you are planning to manage the deployments for your customers and sub-customers, then I feel your best option is to create multiple Tenants.

For your scenario it sounds like you modeled your Tenants this way:

Tenants:

  • Customer 1
  • Customer 2
  • Customer 1 - Customer A
  • Customer 1 - Customer B
  • Customer 2 - Customer A
  • Customer 2 - Customer B

And so on…

Given what you have mentioned, it sounds like for your scenario you could treat each Tenant as an endpoint destination for where you need your software to end up for your customer and sub-customers.

From your description, it sounds like you may have 3 projects. With Tenants you can attach multiple projects to each Tenant (only selecting the Tenants where that deployment applies to).

For example:

Project A - Main Software (Attached Tenants):

  • Customer 1
  • Customer 2
  • Customer 1 - Customer A
  • Customer 1 - Customer B
  • Customer 2 - Customer A
  • Customer 2 - Customer B

Project B - For specific items (Attached Tenants):

  • Customer 1 - Customer A
  • Customer 1 - Customer B
  • Customer 1 - Customer C
  • Customer 2 - Customer A
  • Customer 2 - Customer B
  • Customer 2 - Customer C

And so on…

Project C - Windows Service (Attached Tenants):

  • All sub customers (Tenants) that require the service.

I also just wanted to double check what the difference between Project A and B would be in terms of packages/binaries and deployment steps. Are you deploying different binaries here or do you need specific configuration applied to each Tenant for example connections strings, URLs, username and passwords where you could look to use Project Templates to help.

I feel your solution is valid (but the caveat from my side here is that I do not fully understand your current CI/CD pipeline).

As for a Tenants in Tenant feature, we don’t have this feature, so it feels here that creating a Tenant per customer and sub customer is a good approach.

From the link you provided, this looks to be referencing a question for deploying multiple services to a single machine, while this is another approach, form what you have described, if this is 1 service that needs to be deployed to multiple Tenants. I would suggest having the service deployment as a project and attach any Tenant (customer) that requires the service in the same way you are deploying to your other projects (unless I have misunderstood anything here).

I hope this helps.

Let me know if you have any further questions.

Alll the best
Doug

4

Thanks for your response, Doug.

I also just wanted to double check what the difference between Project A and B would be in terms of packages/binaries and deployment steps. Are you deploying different binaries here or do you need specific configuration applied to each Tenant for example connections strings, URLs, username and passwords where you could look to use Project Templates to help.

You are right, Project A, B and C have completely different packages and deployment steps. Here’s how it looks:

Project A - Main Software (Attached Tenants)

  • Customer 1
  • Customer 2
  • …
  • Customer 5

Project B - SubCustomer Software (Attached Tenants)

  • Customer 1 - SubCustomer A
  • Customer 1 - SubCustomer B
  • Customer 2 - SubCustomer A … F (each SubCustomer from A to F is a Tenant)
  • …
  • Customer 5 - SubCustomer A … P (each SubCustomer from A to P is a Tenant)

Project C - 3rd-Party Windows Service (The plan is to use a Tenant for each of them)

  • Customer 1 - SubCustomer A - Service A1
  • Customer 1 - SubCustomer A - Service A2
  • Customer 2 - SubCustomer A - Service A1
  • Customer 2 - SubCustomer A - Service A2
  • Customer 2 - SubCustomer A - Service A3…A5
  • Customer 2 - SubCustomer B - Service B1
  • Customer 2 - SubCustomer B - Service B2
  • Customer 2 - SubCustomer B - Service B3…B5
  • …
  • Customer 2 - SubCustomer F - Service F1…F5
  • …
  • Customer 5 - SubCustomer A…F - (each with) Service 1…5

All of the Windows Services from Project C are installed on a single machine from e.g. Customer 1’s servers (that’s how I came to the link in my first post). These services typically only differ in a port, so having a separate tenant for each of them could work for us (the Project templates are super useful for this use case). But, as you can see, the number of tenants quickly increases for project C if we model each service instance as a separate tenant. That’s why I wanted to ask for things to consider or problems this amount of tenants could cause.

5

Hi @dennis.h,

Thank you for your reply. Apologies, I interpreted your first email as a single service that will need to be deployed between 1-5 times for each sub customer.

I now understand this a bit better now, thank you for clarifying.

I can see how this exponentially can start to grow quite quickly and understand your concerns. There is not currently a hard limit (within reason) for the number of Tenants you can have, so you should be OK as you increase.

If it helps, we do have customers using 1000s of Tenants happily with the highest I have seen around 8000.

In terms of considerations, you will need to take into account the compute needed to support the running of multiple tasks on your Octopus instance for your Tenanted deployments. When you are deploying to a large number of Tenants, each deployment to a Tenant will add 1 task to your queue, so something to keep in mind as your start deploying to more Tenants and you see your task queue growing.

We do have some guidelines within our best practices when thinking about your task cap in our Installation Guidelines. If you haven’t seen this, we have a guide on how to Increase The Octopus Server Task Cap.

I hope this has helped, let me know if you have any further questions on this.

All the best,
Doug