The Windows Azure Platform allows an application to be deployed to one or more instances. The fabric controller then balances your application's workload across those instances.
Can the number of instances be scaled up/down based on demand or are the number of instances static? If instances can be dynamically started how much control do I have over how this happens?
How does Azure balance workload amongst my application instances and do I have any control over how this happens?
I just want to add that by commercial launch (November), we'll have an API that lets you programmatically modify the number of instances. (So you can scale based on whatever logic you want.)
This question has lots of good information, including a 3rd party tool (AzureWatch) that I use that can scale up/down based on load.
Azure platform: scalling instances up and down
The number of instances for Azure roles is specified in an xml configuration file. Currently, you must manually change the instance count in this config file. When you do so, the fabric controller will automatically adjust the number of running instances for you.
For web roles, incoming TCP connections are balanced across your instances. For worker roles, the load is generally distributed across all instances picking up work assignments from a message queue. The fabric doesn't really get involved for worker roles.
I know this is an old question, but I just thought that I'd highlight the free Windows Autoscaling Application Block, which was released since the question was first asked.
Related
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.
We have written a high scalable Cloudservice for MS Azure with two roles: "WebsiteRole" and "WebsiteWorkerRole". For better performance we deploy this Cloudservice in multiple regions (2x US, 2x EU, 1x JP). We have different configuration files for each region (EuWestProductive.azurePubxml, ServiceConfiguration.CloudEuWest.cscfg, Web.ReleaseEuWest.config).
Now the Problem: In each Region we have running the "WebsiteRole" and "WebsiteWorkerRole". But the "WebsiteWorkerRole" has only very small tasks, so that one extra small instance in one region is more than enough.
We tried to set the Role instance count to zero (ServiceConfiguration.CloudEuWest.cscfg). But this is not allowed:
Azure Feedback: Allow a Role instance count of 0
Is there an other way to remove a role when deploy the Cloudservice?
No, as you've discovered, a cloud service does not allow for scale to zero. You have to effectively remove the deployment. To have the minimum change to what you already have in place you could separate the two roles into two different deployments. Then have an Azure Automation Script, or set of scripts run elsewhere, that handles deploying the worker role when needed and decommissioning when it's not needed.
Depending on the type of workload that worker is doing you could also look at taking another route of using something like Azure Automation to perform the work. This is especially true if it's a small amount of processing that occurs only a few times a day. You're charged by the minute for the automation script, so just make sure it's going to run less than the actual current instance does.
It really boils down to what that worker is doing, how much processing it really needs to do, how much resources it needs and how often it needs to be running. There are a lot of options, such as Azure Automation, another thread on the web role, a separate cloud service deployment, etc. Each with their own pros and cons. One option might even to look at the new Azure Functions they just announced (in preview and charged by the execution).
The short answer is separate the worker from the WebSiteRole deployment, then decide the best hosting mechanism for that worker role making sure that the option includes the ability to only run when you need it to.
Thanks #MikeWo, your idea to separate the deployments was great!
I have verified this with an small example project and it works just fine. Now it is also possible to change the VM size and other configurations per region.
(Comments do not allow images)
I've deployed web sites and services to the cloud before but it was a while ago and I wanted to revisit my approach to inventorize my skills. During the research, I've been told to use a worker role but I'm not sure in what constellation to apply it.
The image presents my choices. I'll be setting up two things (preferably on the same base URL).
1. A web site (ASP.NET, most likely MVC powered by Razor)
2. A service layer (guessingly WCF, as there's not much else to pick from today)
So, in my naive ignorance, I added ASP.NET Web Role for the former and WCF Service Web Role for the latter. Then, according to the hint, I also added Worker Role. And this is where I got humble and started to suspect that my ignorance was rather an arrogance...
Do I need all the three of them? Or is it perhaps so that Worker Role covers the others? Or are the others sufficient and I need to Worker Role? Or am I totally confusing the concepts here?
I've tried to google those but I realize that I haven't reached the threshold of learning by doing in this area yet. I get more confused and headacheish the more I read. Admittedly, my problem might lie in the wrong choice of search words and/or linguistic misconception. If so, my apologies...
The answer is, it depends...
A web role is essentially a Worker role with IIS installed + configured. You could host a WebApi/MVC, WCF AND process events all from the same web role if you really wanted to, reducing costs.
Remember that each role is a separate VM that you have to pay for, so adding extras roles to keep everything separate may not always be the best idea.
In one of our projects for example, we use a web role to host a WebApi. A Worker role to process internal events, and a worker role to host WCF services (you can also use a web role for this). We split them because they take very different workloads and perform separate functions, so being able to scale them independently made sense.
HTH
There's no right answer to how many roles to use in a cloud service. But it's important to understand exactly what those roles are.
Adding a bit to #Peter's answer: Each role is a definition of a VM (its contents) - think of it as a VM template. And for each role (template), you must have a minimum of one instance (VM) running. If you have one role, your minimum footprint will be one VM (of whichever size you specify for that role). If you have three roles, you'll have minimum 3 VMs running.
Whether you have one role or many depends on how you want to scale your application. Each role defines not only what goes in it, but also the size of the VMs uses by the role instances. By having different roles for different parts of your architecture, you can choose to scale those parts differently. For example, you might only need low-resource instances to handle your web tier, but maybe more CPU power for your service tier. And maybe your web tier scales dynamically based on user traffic, but you're able to handle, say, your service tier with just one or two instances. Of course, you can put everything in one role definition, and scale everything together. It's totally up to you.
Iam relatively new to Cloud Computing and azure. I was wondering whether you can have more than one web and worker role in an Azure application. If so what advantages can I get using multiple roles and where do they apply?
Yes, you can have more than 1 web or worker role in an Azure Cloud Service. You can have up to 25 different roles per deployment I believe in any mix of Web and Worker roles. See the Azure Subscription and Service Limits, Quotas and Constraints link for more information.
The advantage of having the roles within the same cloud service is simply that within that cloud service they can see all the other roles and instances easily (unless you configure them otherwise). They will all be relatively close to each other within a data center because a cloud service is assigned to a stamp of machines and controlled by a Fabric Controller assigned to that stamp. You can watch this video by Mark Russinovich which sheds more light on the inner workings of Azure and talks a bit about stamps I think. A cloud service is a security boundary as well, so you get some benefits from that encapsulation if you need to do a lot of inter machine communication that ISN'T going across a queue for some reason.
The disadvantage of batching a whole bunch of roles together is that they are tied pretty closely together at that point. You can certainly scale them separately, and you can do updates that target only a single role at a time. However, if you want to deploy changes to multiple roles you may end up having to do a full deployment to all roles (even those that haven't changed) or do updates to single roles one at a time until all the ones you need updated are, which can take some time. Of course, it could be argued that having them in separate cloud services would still have you doing updates concurrently depending on your architecture and/or dependencies.
My suggestion is to group only roles that REALLY belong together in the same solution. These are role that have workloads that are interrelated. Even then, there's nothing stopping you from separating these as well into separate deployments (though you may benefit from the security boundaries that being within the same cloud service). Think about how each role will be updated, and if they would generally be updated together or not. There are many factors in thinking about how to package roles together.
I was hoping I'd be able to find Azure billing 'use cases' somewhere on the MS site or on StackOverflow.
Maybe I'm being paranoid but I'm trying to be certain before I tell a customer that it'll cost $XXX.00 to move his app to Azure.
I've got an MVC site running on a server in his office. It's a data-based app using SQL-Server. Data intensive but just about 20-30 users. The purpose of going to "The Cloud" is not scalability but reliability.
Lets just say I need a Cloud Service with 2 medium VMs (2 so that we have fail-over capability) and a 1GB SQL Database. Say $2 worth of Bandwidth (15 gb) would probably be enough. Geo Redundant Storage: all the stuff besides the DB is comprised of Code. Very little in the way of resources, total less than 20 megs.
So, my question: By running a Web and Worker am I using two instances? One for Web and one for Worker? If so, can I run the app in just a Web Role? I don't run a separate service. What if I did run both Web and Worker roles for the same site, would that be an extra instance (4 instances instead of 2)?
So, by running a Web and/or Worker role am I ALSO incuring a Virtual Machine instance? If not, does the scenario change if I occasionally RDP into the Web/Worker instance?
Thanks for any insight into this. Also, does anyone know of a MS site that has billing 'use cases' like this?
Based on your description, I'm not sure why you'd want a Worker role. Worker roles are ideal for handling transactions, processing, etc. but I'm not sure if you need that. For example, worker roles can process submitted orders, resize images, etc. Basically any process that you'd like to abstract from the user interface.
Since you mention that you want fail-over capability, you should probably use at least two of whatever role(s) you choose. For example you will need a Web role for your MVC web site. You'll need two instances of whatever size you choose to qualify for Microsoft's Cloud Services SLA uptime guarantee of 99.5%.
Should you decide you need a Worker role, you'd need two instances of that as well.
It's not required to use a minimum of two instances per role type, but it's certainly recommended for production apps, and is required for SLA coverage.
you get charged for each role you activate, so web and worker role will be separate. as far as combining the worker and web together, not sure progrmatically how the
Ok lets take this one by one.
By running a Web Role and a Worker role while meeting the SLA criteria of having at least 2 instances of each role you are essentially creating 4 billable instances (2 Web Role instances and 2 Worker role instances)
You can definitely run a service within a web role if that suits your purposes and save on the worker instances. In that case you'd only have 2 billable instances.
No the VM role is a completely difference role type and you are not running a VM role by running Web/Workers. You can always safely RDP into the instances irrespective of the role type (However the merit of such an act is questionable once you are in production).