Is there a way to get the performance telemetry of an individual service running in a node which has other services running in the same node within a servive fabric cluster?
We are using .net core where there are not performance counters either and we arent using containers at the moment. We want to make sure one microservice doesnt hog all the system resources and choke the other microservices running in the same node. We are using guest executables.
We use application insight. It has support for microservices for service fabric ie correlation id where you can trace a request through multiple services within service fabric
Here is set up instruction and example
https://github.com/Microsoft/ApplicationInsights-ServiceFabric
Related
I have an application running in Service Fabric with multiple nodes. All the running nodes share some cache data using distributed caching available in Service Fabric.
Now, I am looking to move out from Service Fabric due to cost issues.
What would be a good solution for me where I can also maintain caching between multiple instances ( like the distributed cache in Service Fabric).
I need to install it in an Azure environment.
If you're looking for an alternative managed by Microsoft, the best choice would be Azure Redis Cache.
More info:
https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/
We are designing an application which will be hosted on AKS(Azure kubernetes service). The application will consist of a set of services written in asp .net core running in docker containers. I want to monitor the services as well as the containers/nodes and have the observability across the cluster. Azure monitor for containers seems to be a good solution for monitoring containers, nodes and the cluster as a whole however I want the advanced monitoring capabilities of the application insights for the asp .net core services for example application maps, live metrics streams, transaction tracing and such features. Moreover, I don't want to have overlapping solutions. Is the Azure monitor for containers able to provide all or most of these application insights features or do I have to have both solutions in order to get proper cluster monitoring and also the advanced application monitoring?
Azure Monitor for containers provide infrastructure level monitoring and basic application logs with stdout and stderr, Kubernetes events captured out of the box.
It does not provide instrumentation for your apps or distributed tracing capabilities today, which is possible with Application Insights.
If you are looking for application map & instrumentation for events metrics and logs for your app, you can use both together and it's possible to correlate data from both and create dashboards and views.
The long term road map has Azure Monitor for containers & Application insights combined offering
In this (https://learn.microsoft.com/en-us/azure/azure-monitor/insights/container-insights-overview) guide, you can find all the features of AKS monitoring. If these covers all your use cases then you don't need to install any other tool. If not, then you cover only those features which are missing.
I went over this blog Azure SF vs Docker but it didn't answer my doubts completely.
I have Docker Data Center on-prem and i want to push Azure SF into this. But i feel DDC is doing exactly same thing as Service Fabric.
Few things from my mind.
DDC takes care of scaling up, all types of container orchestration, health monitoring etc.
Few items which it doesn't provide :
Service remoting between services, publish subscribe model between services, stateful layer(i've heard about portworx volume rep)
Can someone enlighten me more on when should i go with SF which DDC doesn't provide.
If your application landscape consists of containers and there is no intention to change that then you should probably stick to DDC.
Service Fabric (ASF) has a lot more to offer than support for containers. In fact, in earlier days it did not even had support for containers.
The focus of AFS is to provide a platform for building microservices based applications using stateless services, stateful services and actors.
Things that DDC does not provide:
Stateful Services
Actor model
Stateful Services: The benefit of stateful services is that the data lives where the code lives, so no more separate data stores like a NoSQL or relational database. A great benefit is the reduced latency. So in other words, if you have a frontend running in a container that connects to a container that contains a MySQL server for example, you can replace that using a mix of stateless and stateful services.
Actor model: The actor pattern is a computational model for concurrent or distributed systems in which a large number of these actors can execute simultaneously and independently of each other.
In some scenario's the use of containers in ASF is a temporarily one, to lift and shift existing software and combine that with ASF own service models. In later stages the containers can be replaced by ASF services.
The official docs does list some scenario's as when to run containers on ASF:
IIS lift and shift: If you have existing ASP.NET MVC apps that you want to continue to use, put them in a container instead of migrating them to ASP.NET Core. These ASP.NET MVC apps depend on Internet Information Services (IIS). You can package these applications into container images from the precreated IIS image and deploy them with Service Fabric. See Container Images on Windows Server for information about Windows containers.
Mix containers and Service Fabric microservices: Use an existing container image for part of your application. For example, you might use the NGINX container for the web front end of your application and stateful services for the more intensive back-end computation.
Reduce impact of "noisy neighbors" services: You can use the resource governance ability of containers to restrict the resources that a service uses on a host. If services might consume many resources and affect the performance of others (such as a long-running, query-like operation), consider putting these services into containers that have resource governance.
By the way, in your referenced Q & A the fact that is a Microsoft product is listened as a possible disadvantage. It might still be to some, but Microsoft has announces it will open source ASF.
I see advantages of Kubernetes which include Rolling Deployments, Automatic Health check monitoring, and swinging a new server to action when an existing one fails. I also do understand that Kubernetes is not just for Docker.
So, that brings a couple of questions!
When Azure, and Service Fabric could provide all that I said (and beyond), why would I need Kubernetes?
Would it make sense for one to use Kubernetes along with Service Fabric for large scale deployments on Azure?
Let's look first at the similarities between Kubernetes and Service Fabric.
They are both cloud-agnostic clustering, orchestration, and scheduling software.
They can both be deployed manually, by you, to any set of VMs, anywhere.
There are "managed" offerings for both, meaning a cloud provider like Azure or Google Cloud will host a cluster for you, but generally you still own the VMs.
They both deploy and manage containers.
They both have rich management operations, such as rolling upgrades, health checks, and self-healing capabilities.
That's a fairly high-level view but should give you an idea of what and where you can run with each.
Now let's look where they're different. There are a ton of small differences, but I want to focus on two of the really big conceptual differences:
Application model:
Service Fabric allows you to orchestrate any arbitrary container or EXE (whether that's a small node.js app or a giant legacy application), and in that sense it is similar to Kubernetes. But overall it is more focused on application development specifically, with programming models that are integrated with the platform. In this respect, it is more closely comparable to Cloud Foundry than Kubernetes.
Kubernetes is focused more on orchestrating infrastructure for an application. It doesn't really focus on how you write your application. That's up to you to figure out; Kubernetes just wants a container to run, doesn't matter what's in it.
State management
Kubernetes allows you to deploy stateful software to it, by providing persistent disk storage volumes to containers and assigning unique identifiers to pods. This lets you deploy things like ZooKeeper or MySQL.
Service Fabric is stateful software. Service Fabric is designed as a stateful, data-aware platform. It provides HA state and scale-out primitives. So while Kubernetes allows you to deploy stateful things, Service Fabric allows you to build stateful things. This is one of the key differences that's often overlooked. For example:
On Kubernetes, you can deploy ZooKeeper.
On Service Fabric, you can actually build ZooKeeper yourself using Service Fabric's replication and leader election primitives.
Kubernetes uses etcd for distributed, reliable storage about the state of the cluster.
Service Fabric doesn't need etcd, because Service Fabric itself is a distributed, reliable storage platform. The system services in Service Fabric make use of this to reliably store the state of the cluster. This makes Service Fabric entirely self-contained.
The fact that Service Fabric is a stateful platform is key to understanding it and how it differs from other major orchestrators. Everything it does - scheduling, health checking, rolling upgrades, application versioning, failover, self-healing, etc - are all designed around the fact that it is managing replicated and distributed data that needs to be consistent and highly available at all times.
Please find below a good comparaison article about the difference between ACS and Azure Service Fabric:
https://blogs.msdn.microsoft.com/maheshkshirsagar/2016/11/21/choosing-between-azure-container-service-azure-service-fabric-and-azure-functions/
Could you please clarify what you refer to when you talk mentionne "AWS" ?
From a "developer level" solution could be statefull in both cases but it have a major difference from an Infrastructure point of view:
Docker + Kuberest is a "IaaS" oriented solution
Azure Service Fabric (if you are using Azure service) is a PaaS solution.
IaaS is, in general, more costly and have a more significant maintenance cost.
From a support point of view:
Azure Service Fabric is supported by Microsoft
Docker and Kubernetest are more open source oriented
Hope this help.
Best regards
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.