CODEWITHSUNDEEP
deploymentconfigurationmicroservicesazure-service-fabric
Gary Doublé
Gary Doublé

Reputation: 446

Service Fabric Nested Applications

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.

Upvotes: 2

Views: 263

Answers (1)

LoekD
LoekD

Reputation: 11470

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)

Upvotes: 2

Related Questions