2

I am trying to re-architect our current monolithic web application into a more modular (micro-service) style design.

I have a good idea of the boundaries and a plan on how to build it...

Each part of the app will have it's own domain package, a backing rest api, and a web front-end for managing the data. Plus other stuff like unit tests and possibly a connection helper library, etc.

For argument's sake, say my monolithic app has 3 main components (modules):

  1. An accounts module for creating and managing users
  2. A Products module for administering and managing the product catalog
  3. An Orders module for creating, viewing and amending orders.

In the monolithic app these are all part of the same application (and VS solution and project) and usually have distinct controllers configured using MVC / WebApi Etc:

// MyApp.Web Project (base url ~/)
myapp.com/...
myapp.com/accounts/...
myapp.com/products/...
myapp.com/orders/...

// MyApp.Api Project (base url ~/api)
myapp.com/api/...
myapp.com/api/accounts/...
myapp.com/api/products/...
myapp.com/api/orders/...

Currently we host this in IIS using nested applications and virtual folders but I want to replicate this sort of idea or structure using a service fabric cluster. But each isolated area (accounts, products, orders) will be developed and deployed independently of one another.

How do I configure service fabric cluster to enable this type of situation?

For instance if I have a cluster of 50 nodes and on those 50 nodes I have instances spread out of each service and the service's api. How do I say:

v2.myapp.com/accounts --> any available accounts web UI instance?
v2.myapp.com/products --> any available products web UI instance?
v2.myapp.com/api/products --> any available products api instance?

Should I have VM Scale Sets for web and api or one for each component too, like VM Scale Sets for just products api and another for orders web UI, etc?

Also please note that our system is BIG so there are lots of components, hence the reason for splitting out the monolithic style, so I need a consistent structure to enable all this.

We have major scaleability issues and very slow (manual) virtual server provisioning. Plus a single monolithic SQl Server database. The features of SF I want is modular design, easy provisioning and deployment and a drastic increase in response times and throughput of our system. And of course good failover.

At the end of the day I want customers to see a consistent url structure but under the covers I want to be able to have it all separate and working together over many nodes.

Thanks in advance.
Any help on how to configure this is very much appreciated.

G.

Gary Doublé
  • 436
  • 4
  • 17
  • 1
    https://azure.microsoft.com/en-gb/documentation/articles/service-fabric-concepts-scalability/ – tom redfern Jul 20 '16 at 13:06
  • Is there any reasons to do not split current solution on several solutions with several projects? As far as I understood, the advantage of SF is to balance workload and handle failover. If you don't have such problems in your existing application and just want to decouple modules, maybe it is better to just do it without SF? In other words, which feature of Service Fabric do you want to use? – cassandrad Jul 20 '16 at 13:25
  • @cassandrad We have major scale-ability issues and very slow (manual) virtual server provisioning. Plus a single monolithic SQl Server database. The features of SF I want is modular design, easy provisioning and deployment and a drastic increase in response times and throughput of our system. And of course as you say good failover. At the end of the day I want customers to see a consistent url structure but under the covers I want to be able to have it all separate and working together over many nodes. Make sense? – Gary Doublé Jul 21 '16 at 00:09
  • Perhaps its all done via the load balancer? – Gary Doublé Jul 21 '16 at 00:17
  • @GaryDoublé, yes, it makes sense. I think that effort to rewrite your current app and make everything you mentioned will be very-very huge and could take a lot of time, especially when you are saying that you have a big app. Now I see that you need more new feature and not only modularity, so using SF is appropriate in this situation. Can you add things you mentioned in your comment to the post? – cassandrad Jul 21 '16 at 08:06
  • @cassandrad We are planning on a "slow" migration so the time and effort involved isn't really a factor here. Our current system is an absolute nightmare to administer and maintain so any steps towards a better solution is acceptable. Also note that this solution will be run in parallel with the existing system, of which, as time goes on and we integrate with the new system and structures we will "switch over" the parts of the old to point to the new one.. – Gary Doublé Jul 21 '16 at 08:49

1 Answers1

2

gateway

I would suggest using a gateway pattern here. (more info)

By applying this pattern you'll have full control over how incoming http requests are routed (based on versioning, tenant, health, etc).

vmss

Putting services on specific VMS'ses will limit the options SF has to balance load on them. One application may use more memory resources, the other may use more CPU. Those could be combined on one node to optimize resource use.

Use the node sets to optimize for cost, so services demanding less resources can be placed on cheaper nodes. (using placement constraints) (Likewise for tentants on lower subscriptions)

Community
  • 1
  • 1
LoekD
  • 11,402
  • 17
  • 27
  • Looking on the SO link it seems this answer best describes what I want: http://stackoverflow.com/a/29997344/699426 I'd have to code up a Gateway service that proxies URI paths to the fabric service routes which is exactly what I wanted :) Now to actually code this up :| – Gary Doublé Jul 21 '16 at 10:54