3

Organizations typically separate dev, integration test, system test, user acceptance test, and production environments. Is it possible to have all dev and test environments in one big Service Fabric cluster? Is it possible to additionally separate the environments from one another? E.g. some environments may use mock data, others confidential live data...

user1340582
  • 19,151
  • 35
  • 115
  • 171

2 Answers2

2

There's no technical reason why you can't do this. A cluster can host many Service Fabric applications. Each application is isolated and self-contained. Within the cluster, you could have 1) multiple application types, 2) multiple applications with the same type but different versions, and 3) multiple applications with the same type and version. The only thing that is required is that each application within a cluster must have a unique name.

Matt Thalman
  • 3,540
  • 17
  • 26
  • When you say unique name, is that the ApplicationTypeName under the ApplicationManifest.xml – alltej May 06 '16 at 15:38
  • No, that's the name of the application type. Although that too must be unique for a given cluster. I was referring to the name of the application (an instance of the application type) which gets assigned during creation of the application. For the Application project in Visual Studio, the application name is defined in an application parameters file. – Matt Thalman May 06 '16 at 18:50
1

I talked a bit about Blue/Green deployments that might help give you some background to Matt's answer.

The short answer though is yes, you can absolutely do this. The application instances you deploy are already separate from each other. If you're using stateful services and storing all of your data inside the services themselves - using Reliable Collections, for example - then your application instances will be completely self-contained and won't share any data between each other because the data is inside the service instances.

You can even take things a step further and use placement constraints to keep your production workloads and test workloads on separate nodes so that your test workloads don't eat up production resources.

Community
  • 1
  • 1
Vaclav Turecek
  • 9,020
  • 24
  • 29