I’m designing my service fabric cluster. I’m between creating one app and hosting all the services inside vs creating 1 app per service.
I didnt find clear guidelines on this. The main advantage I see for 1 app per service is that we can deploy each service independently since it has its own app. We can also host the code in different repos. Are there downsides for this?
A better approach is to have one Application per set of services where the services provide a cohesive function. An Application should be an umbrella for n number of services which are related in their function, for instance they may be within the same bounded context or be related to a common operational unit. However, this doesn't mean they have to be deployed / updated in unison.
Services can be deployed independently within an ApplicationType if you move away from using the DefaultServices construct. You can read about why Default Services should be avoided in Production here - essentially they create a rigid deployment strategy and you lose some of the power of Service Fabric parameterization available via PowerShell.
The concept of an Application may seem at odds with a Microservice architecture, but remember its just a logical grouping, single services within an Application are still independently deployable.
Lots of useful info in the Application Model docs.
The main advantage I see for 1 app per service is that we can deploy each service independently since it has its own app.
You can also deploy\upgrade individual services in same application without affecting the other deployed services. Please check about differential packaging here and here
We can also host the code in different repos
Generally when we split our code into separate repositories is because we have a domain boundary that we don't want to track with other services, for example, services owned by different teams or deployed on different schedule, in this case would make sense to have them as separate applications.
Are there downsides for this?
Technically, no. But there are some possible points you have to keep in mind.
When we talk about Microservices we see them as independent services running on their own with as few dependency as possible on other services, when we talk about applications we kinda go against this 'law', because we have to deploy them together, we shouldn't see applications that way, because the applications is just a logical isolation for these services, so where is the benefit on SF applications?
When you have multiple services deployed (dependent or not on each other), you need a way to keep track of them as a bigger unit, otherwise you might end with:
a cluster full of services that sometimes are not required anymore, and is just there because we 'might be using them' or someone forgot to remove when their peers got obsolete.
Dependent services missing on new deployments
Version of services not compatible with each other (contracts, APIs, and so on)
SF Applications works like a snapshot of these services, so for example, whenever a new service get updated, you also upgrade the application to reference the new definition of your services and their dependencies, this will tell SF "this is how I want my services running" and SF will manage to get them exactly as you described. Does not mean you have to update all of them when a upgrade is required, SF will do if you have to, but you can update just the ones that changed, and them deploy a version of your application that SF will manage the version of each service for you. An analogy, it is like a docker compose file where you specify the containers you have to deploy as a single deployment.
Given that, when you opt out of application concept, you loose these benefits, because now you have to manage every single service on their own and keep track of the versions they depend on, and in cases where two services on different applications need to be deployed together (because of breaking changes for example) you would not be able to easily rollback if one of them fail, because they are not dependent on each other anymore, so you would have to write your own logic to handle this.
A typical scenario you might find yourself in is where a new version of a service get updated and others not updated on same release might stop working, but for your deployment, the new service looks OK, without any error.
So, at the end, is just a trade off, you opt for more flexibility deploying your service, but end up with more maintenance.
Related
As I understand there is no concept of update domain in App Services (and in other PaaS offerings). I am wondering how Azure is handling OS updates if I have only a single instance of an App Service app. Do I need to plan for two and more instances if I want to avoid such cases when an app goes down during the OS/other updates or this is handled without downtime? According to docs App Service has 99.95% SLA - is this time reserved here?
First of all, welcome to the community.
Your application will not become unavailable when App Services is patching the OS, you don't have to worry about that. Imagine if that would be the case, it would be a huge problem. Instead, the PaaS service will make sure your application is replicated to an updated worker node before that happens.
But you should have multiple instances, as a best practice listed in this article:
To avoid a single point-of-failure, run your app with at least 2-3 instances.
Running more than one instance ensures that your application is available when App Service moves or upgrades the underlying VM instances
Have a look at this detailed blog post:
https://azure.github.io/AppService/2018/01/18/Demystifying-the-magic-behind-App-Service-OS-updates.html
When the update reaches a specific region, we update available instances without apps on them, then move the apps to the updated instances, then update the offloaded instances.
The SLA is the same regardless the number of instances, even if you select "1 instance":
We guarantee that Apps running in a customer subscription will be available 99.95% of the time
Have a look at Hyper-V and VMWare, it will give you a rough idea on how App Services handle that.
If you're looking for zero-downtime deployments with App Services, what you are looking for are deployment slots.
Managing versions can be confusing, take a look at this issue I opened, it gives you a detailed how-to approach about managing different slot versions, which is not clearly described by Microsoft docs.
Can anyone tell me or explain me what are the limitations/drawbacks of deploying multiple micro services (say 2-3) on a single Azure AppService server?
To achieve following we use microservies
Serve a single purpose or have a single responsibility
Have a clear interface for communication
Have less dependencies on each other
Can be deployed independently without affecting the rest of ecosystem
Can scale independently
Can fail independently
Allow your teams to work independently, without relying on other teams for support and services
Allow small and frequent changes
Have less technical debts
Have a faster recovery from failure
But How the Azure app service works when we try to deploy one of the microservice? will it impact other mircoservices? can we use this it in production environments?
I came across few links hosting mutiple apps on single appservice by defining virtual path for windows and for linux by adding azure storage but is it best/good practice to do?
No, it's not. They will compete for compute resources, and in case of hardware failure all of them will go down.
It sounds like you're referring to hosting multiple App Service apps in a shared App Service plan. This is conceptually (and physically) the same as running multiple apps on a server, and I would think about pros/cons along those lines.
You can host many apps on the same plan as long as the plan provides enough memory/CPU/network resources to cover the needs of the combined demands of those apps. For a few small apps, a modest plan size shouldn't have a problem handling all of them in production. The main benefit of combination is saving costs, since the plan is the unit of charge, not the apps.
Microsoft documents some reasons to isolate apps on separate plans:
The app is resource-intensive.
You want to scale the app independently from the other apps in the existing plan.
The app needs resource in a different geographical region.
From my experience, I'd add some considerations:
Deployment and restarting of apps can cause CPU spikes for the plan (which is a server). If your apps are performance sensitive and you deploy often, you might want more separation
Azure maintenance requires servers to restart at least once a month or more. If all your apps are on a shared plan, a patch reboot can mean the entire system is down and that all apps compete for resources when starting up simultaneously
I generally use separate plans as environment boundaries, so a production plan separate from a test plan. "Test" apps go on test plan, "Prod" apps on production to prevent testing from impacting users.
Azure Functions may be better fit for hosting many microservices
I want to host an Orleans project on Azure, but don't want to use the (classic) Cloud Services model (I want an ARM template project). The web app sample uses the old web / worker model - what is best option? There is a Service Fabric sample - is that the best route? The nearest equivalent to the web/worker model is VM Scale Sets - is that a well tested option?
IMO, app service is closet to web role.
Worker role however, depending on the point of view
From system architecture point of view, I think Scale Set is the closet. You get an identical set of VMs running your application. However you lost all management features. How your cluster handle application configurations, work loads on each node, service interruptions from server failure or deployments are pretty much DIY. Also you need to provision the VM with dependencies for your application.
From operations point of view, I think Service Fabric is the closest. It handles problems above but then you are dealing with design/implementation changes and learning curve from the added fabric layer in the architecture. Could be small, could be big depending on the complexity of your project. Besides, service fabric is still relatively new and nothing is for sure. Best case you follow the sample change a few lines of code and it works like a charm. Worst case you may want to complete refactor orleans solution into service fabric solution.
App service would be the easiest among the three. If it doesn't meet your requirement, I personally would try Service Fabric. Same reason why people are moving to cloud and you would opt for ARM solution.
What is the reasoning behind Applications concept in Service Fabric? What is the recommended relation between Applications and Services? In which scenarios do Applications prove useful?
Here is a nice summary how logical services differ from physical services: https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/logical-versus-physical-architecture
Now, in relation to Service Fabric, Service Fabric applications represent logical services while Service Fabric services represent physical services. To simplify it, a Service Fabric application is a deployment unit, so you would put there multiple services that rely on the same persistent storage or have other inter-dependencies so that you really need to deploy them together. If you have totally independent services, you would put them into different Service Fabric applications.
An application is a collection of constituent services that perform a certain function or functions. A service performs a complete and standalone function and can start and run independently of other services. A service is composed of code, configuration, and data. For each service, code consists of the executable binaries, configuration consists of service settings that can be loaded at run time, and data consists of arbitrary static data to be consumed by the service. Each component in this hierarchical application model can be versioned and upgraded independently.
It is described here in detail
How I currently see it, applications are a nice concept to group multiple services together and manage them as single unit. In context of service fabric, this is useful if you have multiple nano-services which do not warrant them being completely standalone; instead you can package them together into microservices (SF application).
Disclaimers:
- nano-service would be a REALLY small piece of code running as a stateless SF service for example (e.g. read from queue, couple of lines of code to process, write to another queue).
- in case of "normal" microservices, one could consider packaging them as 1 SF application = 1 SF service
An application is a required top level container for services. You deploy applications, not services. So you cannot really speak about differences between the two since you cannot have services without an application.
From https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-application-model:
An application is a collection of constituent services that perform a certain function or functions. A service performs a complete and standalone function (it can start and run independently of other services) and is composed of code, configuration, and data. For each service, code consists of the executable binaries, configuration consists of service settings that can be loaded at run time, and data consists of arbitrary static data to be consumed by the service. Each component in this hierarchical application model can be versioned and upgraded independently.
Take a look at the link provided and you will see the hierarchical relationship.
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.
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:
Each instance of an application you create gets its own process (or set of processes if you have multiple service types in the application). Service instances of a service type share host processes. Service instances of different service types get their own process per type.
The application is the top level upgrade unit, that is, every upgrade you do is an application upgrade. You can upgrade individual services within an application (you don't always have to upgrade every service within an application), but each time you do an upgrade, the application version changes.
You can create side-by-side instances of different versions of the same application type in your cluster. You cannot create side-by-side instances of different versions of the same service type within an application instance.
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.