0

If I've understood the docs properly, azure service fabric-based apps/microservices cannot be installed together with their service-fabric operational environment in one "packaged installer" step. For example, if I want to deploy a set of microservices on premises at a company that is running a typical windows server 2012 or VMWare IT center, then I'm out of luck? I'd have to require the company to first commit to (and execute) an installation of an azure app service fabric on several machines.

If this is the case, then the Azure Service Fabric is only an option for pure cloud operations where the service fabric cluster can be created on-demand by the provider or for companies that have already committed to azure service fabric. This means that a provider of classical "installer-based" software cannot evolve to the azure service fabric advantages since the datacenter policies of the potential customers is unknown.

What have I missed?

GGleGrand
  • 1,565
  • 1
  • 20
  • 45

1 Answers1

2

Yes, you always have to have a cluster to run Service Fabric Applications and Microservices. It is however not any more limited to a pure cloud environment, as of September last year the on-premise version of Azure Service Fabric for Windows Server went GA (https://azure.microsoft.com/en-us/blog/azure-service-fabric-for-windows-server-now-ga/) and that lets you run your own cluster on your own machines (whether physical or virtual, doesn't matter) or in another data center (or even at another cloud provider).

Of course, as you say, this requires your customer company to either have their own cluster or that you set one up for them (https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-creation-for-windows-server). They will also need to have the competence to manage that cluster over time. It could be argued though that this shouldn't be much more difficult than managing a VMWare farm or setting up and managing say a Docker container host(s).

For the traditional 'shrink-wrapped-DVD-installer-type' of software vendor this might not be as easy as just supplying an .exe and some system requirements, i agree with you on that. If the customer can't or don't wan't to run their own cluster and cloud is not an option then it definitely adds additional complexity to selling and delivering your solution.

The fact that you can run your own cluster on any Windows Server environment means that there is no real lock-in to Azure as a cloud platform, I think that this is a big pro for SF as a framework. Once you have a cluster to receive your applications then you can focus on developing that, this cannot be said of most other cloud-based PaaS frameworks/services.

yoape
  • 3,285
  • 1
  • 14
  • 27
  • Thanks. Got it. I guess I was hoping to achieve and end-to-end scenario where we dev on SF and deliver on-demand (cloud) SaaS using SF and also sell appliances into bunkered-firewall shops with a low-end SF-in-a-box solution. OK, so hybrid still remains a challenge for architects in this context. I remain an SF fan... and look forward to more. FAQ: minimum number of seperate cluster nodes (machines) is 3, correct? – GGleGrand Jan 11 '17 at 18:43
  • Yes, the minimum number of nodes is 3, but if you want to have a higher durability (https://learn.microsoft.com/sv-se/azure/service-fabric/service-fabric-cluster-capacity#the-durability-characteristics-of-the-cluster), i.e. better SLA for your cluster as a whole, you may need more. Bronze durability is 3, Silver 5, Gold 7. If you have Bronze then infrastucture updates (rebooting a VM for instance) will mean that you cannot have quorum during that event. For production I would recomment 5+ nodes. – yoape Jan 22 '17 at 00:30