I need help how to think about designing our application to fit into the new Azure Service Fabric template.
Today we have an application built on Azure Cloud Services. The application is built around DDD and we have separate bounded contexts for different subsystem parts of the application. The bounded contexts are today hosted in one worker role that exposes these subsystems using a single WebAPI.
Additionally we have one Web Role hosting the web frontend and one Worker Role processing a background queue.
We strive to move to a micro services architecture. The first thing I planned to do was to extract all bounded context into their own API-hosts. This will result in 5-10 new WebAPI services supporting our subsystems.
To my question, should all of these subsystem/bounded context/API-hosts be their own Service Fabric Application or a service within a single Service Fabric Application?
I've read the documentation, found here Service Fabric Application Model, over and over and I can't figure out where my services fits in.
We want the system to support different versions of the services, and the services should also be possible to scale different from another. There might even be a requirement to have one micro service to run in a larger VM size then the rest.
Please can someone guide me in which suits my needs.
Azure Service Fabric is a Platform as a Service (PaaS) offering designed to facilitate the development, deployment and management of highly scalable and customizable applications for the Microsoft Azure cloud platform. Fabric, in this context, is a synonym for framework.
Azure Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices and containers. Service Fabric also addresses the significant challenges in developing and managing cloud native applications.
Azure Service Fabric is Microsoft's platform-as-a-service (PaaS) and is used to build and deploy microservices-based cloud applications.
I think you have the right idea, in general terms, that each bounded context is a (micro) service. Service Fabric gives you two levels of organization with applications and services, where an application is a logical grouping of services. Here's what that means for you:
Logically speaking, think of an application as a cohesive set of functionality. The services that collectively form that cohesive set of functionality should be grouped as an application. You can ask yourself, for each service: "does it make sense to deploy this service by itself without these other services?" If the answer is no, then they should probably be grouped in the same application.
Developmentally speaking, the Visual Studio tooling is geared a bit more toward multiple services in one application, but you can have multiple applications in one solution too.
Operationally speaking, an application represents a process boundary, upgrade group, and versioning group:
Placement and scale is done at the service. So for example, you can scale one service in an application, and you can place another service on a larger VM.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With