I have two app services(service A and Service B) developed in .net core 3.1 and hosted as two independent app service in azure. Service A is heavily dependent on service B. Is there is way (Azure offering) to make them communicate faster? Is hosting them in same container will improve inter service communication performance? Any suggestion on kubernetes?
If you are not using Azure Kubernetes Offering yet, (AKS) I would recommend spinning up a cluster. (note that it supports windows nodes in case you need them)
You should keep your services separated into two pods (https://learn.microsoft.com/en-us/azure/aks/concepts-clusters-workloads#pods)
and create a matching kubernetes service.
Now if you would like to have your POD run on the same node to increase the communication speed, you should look at using pod affinity, which will allow to have pod pods run on the same node, without having to tie them to a particular node (node affinity)
https://learn.microsoft.com/en-us/azure/aks/operator-best-practices-advanced-scheduler#inter-pod-affinity-and-anti-affinity
Related
I am trying to understand the advantages of using Service Fabric over a cloud service worker role.
Currently, I am using a cloud service for hosting (web role and worker role).
Will there be any advantage if I change the cloud service to an App Service Web app for hosting the web role and a Service Fabric stateless service for hosting the worker role? If so, what are the advantages?
Service Fabric itself is an application platform layer that runs on Windows or Linux, whereas Cloud Services is a system for deploying Azure-managed VMs with workloads attached. The Service Fabric application model has a number of advantages:
Fast deployment times. Creating VM instances can be time consuming. In Service Fabric, VMs are only deployed once to form a cluster that hosts the Service Fabric application platform. From that point on, application packages can be deployed to the cluster very quickly.
High-density hosting. In Cloud Services, a Worker Role VM hosts one workload. In Service Fabric, applications are separate from the VMs that run them, meaning you can deploy a large number of applications to a small number of VMs, which can lower overall cost for larger deployments.
The Service Fabric platform can run anywhere that has Windows Server or Linux machines, whether it's Azure or on-premises. The platform provides an abstraction layer over the underlying infrastructure so your application can run on different environments.
Distributed application management. Service Fabric is a platform that not only hosts distributed applications, but also helps manage their lifecycle independently of the hosting VM or machine lifecycle.
For more details, refer "Learn about the differences between Cloud Services and Service Fabric before migrating applications".
This article helps you understand the options and make the right choice for your web application.
As #PRADEEP CHEEKATLA said,Service Fabric itself is an application platform layer that runs on Windows or Linux, whereas Cloud Services is a system for deploying Azure-managed VMs with workloads attached.
In Cloud Services, a Worker Role VM hosts one workload. In Service Fabric, applications are separate from the VMs that run them, meaning you can deploy a large number of applications to a small number of VMs, which can lower overall cost for larger deployments.
And the key difference between Service Fabric and Cloud Services is that in Cloud Services you connect to a VM, whereas in Service Fabric you connect to a service.
This is an important distinction for a couple reasons:
1.Services in Service Fabric are not bound to the VMs that host them; services may move around in the cluster, and in fact, are expected to move around for various reasons: Resource balancing, failover, application and infrastructure upgrades, and placement or load constraints. This means a service instance's address can change at any time.
2.A VM in Service Fabric can host multiple services, each with unique endpoints.
Here is a comparing Cloud Services with Service Fabric：
Also, you could refer to this article to converting Web and Worker Roles to Service Fabric stateless services.
What is the difference between Azure Container Service and Web App for Containers?
They both seem to offer a fully managed platform on which we can deploy containers. I feel that Web App for Containers must be offering something more, but I don't see it. I've read the Azure Container Service FAQ and the Web App for Containers intro page, but the difference is not obvious to me.
Web App for Containers lets you run your custom Docker container which hosts your Web Application. By default the Web App Service with Linux OS provides built-in Docker images like PHP 7.0 and Node.js 4.5. But by following the instructions from this webpage you can also host your custom docker images which allows you to define your own SW-Stack. The limitation is that you can only deploy one docker image to an App Service. You can scale the App Service to use multiple instances, but each instance will have the same docker image deployed. So this allows you to use Docker as a Service, but isn't intended for deploying Microservices.
Container Services (ACS), Kubernetes Service (AKS) and Service Fabric allow you to deploy and manage multiple (different) Docker containers which might also need to communicate with each other. Let's say you implement a shopping website and want to build your web application based on a Microservices architecture. You end up having one Service (= container) which is used for registration & login of users and another Service which is used for the visitors' shopping carts and purchasing items. Additionally you have many further small services for all the other needed tasks. Because the purchasing service is used more frequently than the sign-up/sign-in service, you will need, for example, 6 instances of the sign-up/sign-in service and 12 instances of the cart service. Basically, ACS, AKS and Service Fabric let you deploy and manage all those different Microservices.
If you want to know the difference between ACS/AKS and Service Fabric you might want to have a look here.
I'm using Azure for the first time to deploy a web app. More specifically, I'm using the Docker Container Service to do this. I already have one instance of it deployed. But, I want to also deploy 2 more instances of the same web app. I want each instance to have a different URL. What is the best way of doing this? Do I have to add a new container service for each new instance and repeat the steps I did for deploying the first instance?
As in case of Azure Container Service (ACS),
You choose a container orchestrator i.e. Swarm, DC\OS and Kubernetes (Because creating replicas works differently in each of them).
In case of Swarm then either create a separate application container for the same application with a different end point and use automatic discovery feature for different URL(s) or choose a reverse-proxy load-balancer such as Nginx which will work on the same URL but on a different port (My blog here might help you).
Creating replicas across a cluster are used for Load Balancing, Routing Mesh, Scaling and Rolling updates etc.
I have a application that can be broken down into multiple communicating services. My current implementation is monolithic and I want to reorganize it so that individual components can be deployed,iterated upon, scaled independently. I see two ways to do this with Azure:
Service Fabric service composed of set of communicating micro-services (stateless, web-api etc.)
A collection of individual Azure Web Apps/ Cloud Services that call each other at the http end points.
Are there any obvious advantages of 1 over 2? Any rule of thumb to chose one over the other would also be very helpful.
I think this page compares it well: https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cloud-services-migration-differences/
I can't tell it better than this.
There is not really a rule of thumb. Service Fabric might seem more complex but offers some things that Cloud Services / Web Apps don't.
A quick summary (taken from the link provided):
Service Fabric itself is an application platform layer that runs on Windows or Linux, whereas Cloud Services is a system for deploying Azure-managed VMs with workloads attached. The Service Fabric application model has a number of advantages:
Fast deployment times. Creating VM instances can be time consuming. In Service Fabric, VMs are only deployed once to form a cluster that hosts the Service Fabric application platform. From that point on, application packages can be deployed to the cluster very quickly.
High-density hosting. In Cloud Services, a Worker Role VM hosts one workload. In Service Fabric, applications are separate from the VMs that run them, meaning you can deploy a large number of applications to a small number of VMs, which can lower overall cost for larger deployments.
The Service Fabric platform can run anywhere that has Windows Server or Linux machines, whether it's Azure or on-premises. The platform provides an abstraction layer over the underlying infrastructure so your application can run on different environments.
Distributed application management. Service Fabric is a platform that not only hosts distributed applications, but also helps manage their lifecycle independently of the hosting VM or machine lifecycle.
Peter has done a great summary. And here are my additional points:
Cloud Service is not designed for micro service pattern, while Service Fabric is. If you want to enjoy the benefits brought by micros service, Service Fabric is your best choice.
With Cloud Service, if you want separate your application into autonomous services, you either
Create multiple cloud services. Which is difficult to monitor and manage since there is not a unified interface for a group of cloud services, Cloud Service is just not designed for this pattern.
Or add multiple roles into a single cloud service, this will lead to a) bloat of your cloud service configuration file, because all service configurations are in a single config file; and b) to upgrade a single role, you end up redeploy the whole cloud service!
Cloud Service doesn't support cross region/DC deployment, while Service Fabric does. That means you can turn a DC level disaster recovery into a normal failover, which automatically handled by Service Fabric, see this.
Recently came to know about Azure Service Fabric and seems a good way to develop scaling applications as bunch of micro services. Everywhere it is telling that we need to have stateless front end web services and stateful partitioned internal services. The internal services scale by partitioning the data.
But what happens to the front end services in load? .The chances are very less as they are doing nothing but relying to internal stateful services. Still should we use load balancer before front end services? If so, can we host the same too via Service Fabric's Stateless model using OWIN or any other web host?
The question is asked already in SO but as comment. It didnt get reply as the original question was different.
Azure Service Fabric usage
Yes, you'll definitely want to distribute load across your stateless services as well. The key difference is that since they are stateless, they can handle requests in a round-robin fashion.
Whereas stateful services have partitions, which map to individual chunks of the service's state, stateless services simply have instances, which are identical clones of each other, just on different nodes. You can set the number of instances in on the default service definition in the application manifest. For instance, this declaration will ensure that there are always 5 instances of your stateless service running in the cluster:
<Service Name="Stateless1">
<StatelessService ServiceTypeName="Stateless1Type" InstanceCount="5">
<SingletonPartition />
</StatelessService>
</Service>
You can also set the InstanceCount to -1, in which case Service Fabric will create an instance of your stateless service on each node.
The Azure load-balancer will round-robin your incoming traffic across each of your instances. Unfortunately, there isn't a good way to simulate this in a one-box environment right now.