What is established best practice in porting a Windows Service to Azure? Should it be changed into a Worker Role or moved into a VM Role? Are there other options? Assume that my services write to external persistence sources (MSMQ, databases, WCF) rather than to the file system directly.
You are far better off converting your Windows Services to Worker-Roles than VM roles. VM roles are meant to house applications that require complex un-automatable installation procedures. They are also a bigger pain to manage and you want to stay away from VM roles as much as possible. If you can find a way to automate deployment of your existing Windows Services via Worker-Roles, it is definitely the way to go.
You can also looking into HPC roles and depending on the on-prem/off-prem and load/compute requirements, adding Azure machines to your HPC cluster maybe of benefit.
All types of Roles (Web/Worker/VM/HPC) are stateless and require to be able to spin-up or tear-down from scratch on demand. All types of Roles are meant to run more than one VM instance at a time.
HTH
I wrote a blog post about this a while back. It is here:
http://blogs.msdn.com/b/golive/archive/2011/02/11/installing-a-windows-service-in-a-worker-role.aspx
Note that a Windows Service won't communicate directly with the fabric controller, so you need to ping it periodically to check health, then take remediative actions as needed.
Putting a Windows Service into a worker or web role is accepted practice. The main reason to go with VM Role is if there is significant (>10 minutes) setup required. My blog post details how to install your service.
Of course, if you want to move the code into a worker role, that's also fine. In this case you don't need any special steps to ensure the fabric controller is aware of its health.
If cost is an issue, combining functions into web/worker is also accepted practice. And you can save by not working over your code to get it into a web/worker.
Azure has a special type of Web Role called "WCF Service Web Role" which corresponds to a Windows WCF Service. This is a good point for migrating existing services.
Ideally the migration should be followed by taking advantage of Azure specific features, for instance using queues and work roles to maximise perfromance and scalability.
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.
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.
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.
We currently have a window service which send some notification emails to users after doing some processing on database(SQL database). Runs once in day.
We want to move this on azure cloud. One alternate is to put it on Azure VM as is. but I am finding some other best possible solution for that.
I study about recurring and on demand Web jobs but I am not sure is this is best solution.
Also is there any possibility to update configuration of service code in App.config without re-deploy the code of service on cloud. I means we can manage configuration from Azure portal.
Thanks in advance.
Update 11/4/2016
Since this was written, there are 2 additional features available in Azure that are both excellent choices depending on what functionality you need:
Azure Functions (which was based on the WebJobs described below): Serverless code that can be trigger/invoked in various ways, and has scaling support.
Azure Service Fabric: Microservice platform, with support for actor model, stateful and stateless services.
You've got 3 basic options:
Windows service running on VM
WebJob
Cloud service
There's a lot of information out there on the tradeoffs between these choices, but here's a brief summary.
VM - Advantages: you can move your service basically as it is without having to change much or any of your code. They also have the easiest connectivity with other resources in Azure (blob storage, virtual networks, etc). The disadvantage is you're giving up all the of PaaS advantages and are still stuck managing your own VM infrastructure
WebJob - Advantages: Multiple invocation options (queues, blobs, manually, queue receive loops, continuous while-loop style, etc), scheduled (would cover your case). Easy to deploy (can go with website, as a console app, automatically through Kudu), has some built in logging in Azure portal - and yes, to answer your question, you can alter the configuration in the portal itself for connection strings and app settings.
Disadvantages - you'll need to update code, you don't have access to underlying resources (if you need that), and more of something to keep in mind than a disadvantage - it uses the same resources as the webapp it's deployed with.
Web Jobs are the newest of the options, but at the same time appear to have active development going on to increase the functionality and usefulness.
Cloud Service - like a managed VM, has some deployment options, access to underlying VM if needed. Would require some code changes from your existing service.
There's nothing you've mentioned in your use case that makes me think a Web Job shouldn't be first thing you try.
(Edit: Troy Hunt has a great and relatively recent blog post illustrating most of the points I've mentioned about Web Jobs above: http://www.troyhunt.com/2015/01/azure-webjobs-are-awesome-and-you.html)
Is it possible to deploy multiple roles in the same instance?
I have three web roles (website in asp.net mvc3, and two WCF services instances) and two worker roles (windows services).
The load for this application is very small, so I don't want to create so many instances in Windows Azure and pay for all of the instances now. Instead I want to deploy all my application in the same instance and change it later if I will get some income from my applications.
I Googled and found some forum posts than it's possible and some than it's not possible... but I can't find information how to do it...
So two questions:
Is it possible?
How can I do it?
A slightly different answer than #Simon's... A Role is actually a template for a Windows Server 2008 VM (see my answer on this SO question as well). Each role has one or more instances, and you can run whatever you want on any role.
You can absolutely run your website and all your WCF services in a single role. You'll now scale your application up/down (VM size) and out/in (# of instances) as a single scale unit. If, say, your WCF services are CPU-intensive, causing the VM instances to slow down for your web visitors, you'll need to scale out enough to handle those visitors.
Once you reach a significant traffic load, it's worth considering separate roles. That way, you can decide on VM size and quantity per role. Maybe you have 2 or 3 Small instances of a Web role to handle your user traffic on the website, and maybe 2 Medium instances of a Worker role to handle WCF services (just as an example). The more roles you have, the finer-grain scaling you have, but you must run at least one instance of each role, which elevates your "system at rest" baseline cost.
No, roles are instances and each one takes up an entire VM. You can however deploy a number of websites into a single role, which will allow you to deploy all your MVC and WCF apps into a single web role. You need to add websites to the sites element in the ServiceDefinition. There seem to be a few blog posts on how this is done - here and here.
For worker roles, I suggest you create a single worker role and combine the work done in those roles, such as starting a separate thread for each queue being monitored. This StackOverflow answer by Eugenio Pace.
I wouldn't recommend trying to combine worker role functionality into the web role. Apart from it not making architectural sense, sense to the physical infrastructure (IIS vs not IIS), there are potential issues such as the with termination of running threads when worker roles recycle (a thread not started by IIS may terminate abruptly)
Check this episode of cloud cover.
you can put couple of web role in the same instance.
worker role you can always put multiple thread to work the data.
http://channel9.msdn.com/Shows/Cloud+Cover/Cloud-Cover-Episode-37-Multiple-Websites-in-a-Web-Role.
Note that each time you upload a new version to azure you need to upload all the web roles/ worker roles to azure again
Check out this blog post 'Combining Multiple Azure Worker Roles into an Azure Web Role'
http://www.31a2ba2a-b718-11dc-8314-0800200c9a66.com/2012/02/combining-multiple-azure-worker-roles.html
I think this is what you need to do...
Also Wayne has variations of this on his blog: http://www.31a2ba2a-b718-11dc-8314-0800200c9a66.com/2010/12/how-to-combine-worker-and-web-role-in.html
HTH