Microservice deployment with multiple replica global instances


I can’t find an option to my deployment issue in octopus or in the forums. Can anyone help?

We have several microservices, deployed in self-contained clusters worldwide… i.e. each cluster contains many services. Each cluster is a replicated copy of each other with configuration etc. local to the cluster.

When we deploy we deploy on a microservice by microservice basis, thereby updating part of the cluster. However, each cluster needs to be updated at the same time.

We currently have each service as a seperate project, each each cluster is a seperate environment. We have Test, UAT, Live cluster copies worldwide. Test may contain 2 clusters (aka octopus environments), UAT 3 clusters and Live 5 clusters. Therefore we have many octopus environments to one “logical” environment. What I can’t seem to work out is how:

  • Is this the best option, and will 3.4 (multi-tenancy) help?
  • From the TFS vNext Octopus Release component to have multiple --DeployTo environments (i.e. it’s just one). We would like to deploy to the 2 clusters in TC at the same time
  • When we promote, we want to promote to all clusters in a logical “environment”. We tried using lifecyles, using “phases” for a logical environment, for this but we can’t “gate” between logical environments. It appears that when we set “auto” deploy, it deploys to everything. What we want is to gate between phase Test and phase UAT, but then auto-deploy to all within that phase

Is there a better way do this?


Hi Graham,

Generally for scenarios such as yours we recommend a different approach.
We would suggest you model your environments so they correspond to your concept of an environment (i.e. Test, UAT, Live), and use Roles to identify your application clusters.

For example, you may create a role named ServiceA, which will be applied to one or machines in each environment. You would then scope the appropriate steps in your projects to that role (i.e. those that should be deployed your ServiceA cluster).

I believe this will answer your questions:

  • Multi-tenancy will not be required
  • Multiple --deployTo parameters will not be required
  • You will be able to simply promote to a single environment, and it will work as expected.

I hope that helps. Please let me know what you think?


In case this makes a difference, we are running in Azure using a localhost listening tentacle.

Would we add several roles to the one tentacle? (e.g. “cluster Test-1”, “cluster Test-2”, “cluster UAT-1”, “cluster UAT-2”, “cluster live-1”, “cluster live-2” etc) or would we create several new localhost tentacles.

Just trying to visualise this.

Roles map steps to targets, within a given environment.
To word it another way, when you’re deploying a step to an environment, it is the roles that determine which deployment targets (machines) the step will execute on.

I would suggest you make your roles correspond to components (or functions). They should be abstract of both environments and physical machines. For example, you may have roles named Service A or WebSite X. The names generally shouldn’t be environment specific (Test, Live, etc), as this is the function of environments. They also shouldn’t directly correspond to physical machines.

By following this scheme, let’s say you have a WebSite named ‘Acme Web’, and a service named ‘Acme Backend’. You create roles named ‘Acme Web’ and ‘Acme Backend’. In your Test environment, you may have just a single Tentacle VM (hosted in Azure in your example). It would have both roles, as you want both components deployed to it for testing. However, in your Live environment, you may have two physical Tentacles dedicated to hosting the WebSite, so these machines would both be given only the ‘Acme Web’ role. And you may have another two physical servers for hosting the backend service, these would both be given only the “Acme Backend” role.

I hope that helps illustrate the utility of roles.
Please feel welcome to ask any follow up questions.