- But in what case using Windows Service as Azure Worker role is better that running service inside VM?
There are several benefits for moving a Windows Service to an Azure Worker Role - IMHO, the top three are:
Azure Worker Roles are PaaS (Platform as a Service) - you are provided with a 'platform' on which your code runs (a Windows Server VM, but that is abstracted away from you) - there is no need to manage the underlying infrastructure OS, networking, disks etc. This means that you can focus on your code and how that works / scales / performs etc. without having to worry whether the VM is up and running. Furthermore, the underlying Azure Fabric will manage failures for you, starting a new instance of a worker if the underlying hardware fails.
Azure Worker Roles give you the benefit of scale - Because they run on the Azure PaaS platform, your code 'package' can be scaled to multiple instances through the Azure Portal with a few mouse-clicks. Scaling can be automatic (triggered by the underlying Azure Fabric) on a queue length (if you are receiving messages from a queue) or based on average CPU usage; alternatively, you can scale manually or on a set schedule (e.g. 'we do lots of processing overnight so increase the number of workers to 4 from 1am - 6am and then back to 2 for the rest of the day'). See https://azure.microsoft.com/en-gb/documentation/articles/cloud-services-how-to-scale/ for more information on scaling Worker Roles (aka. 'Cloud Services')
Similar API to Windows Services - the API for an Azure Worker Role is almost exactly the same as that exposed within a Windows Service - you have an OnStart(), OnStop() and Run() methods^ allowing you to easily port an existing Windows Service to a Worker Role with minimum fuss.
^ Ok, these might not quite be right as its a couple of months or so since I last worked with WR's and I can't remember the interface exactly, but you get the idea ;-)
Do i continue with running service in Azure VM?
Let me answer that question in the context of your problem (my emphasis):
I have two application for my client, one is web application where user schedule some action and another one is windows service which runs every 3 min and execute scheduled task and email to client.
I think (IMHO) that you need to think about developing for the cloud, rather than the traditional model of development. What I read from this is that you have a web-application that writes something to a persistent store (probably a database table); you then have a second service (that you are looking to migrate to an Azure Worker Role) that polls the persistent store at a specific interval, detects whether there are any new clients to e-mail and sends out the e-mail.
If we were to re-architecture this for the cloud, I would keep Worker Roles in the mix, but do the following:
Web-app publishes a message to a queue to indicate that a client needs to be e-mailed - this message could contain their first and last names, e-mail address and possibly some data that would go into the e-mail message body (if required).
The Worker Role would poll this queue for messages. For each message received, the Worker Role would send an e-mail based on the content of the message via your preferred e-mail provider (hopefully they have a nice .Net API - no raw SMTP please!). Once the e-mail was successfully sent, the Worker Role would delete the message off the queue.
This approach would be both scale-able and repeatable - a true cloud architecture!
FYI, if your interested in using the queue approach, either Azure Storage Queues or Azure Service Bus Queues could work here. It sounds like you have simple queuing requirements and as such, Storage Queues would be a perfect fit. Take a look at their comparison here: https://azure.microsoft.com/en-gb/documentation/articles/service-bus-azure-and-service-bus-queues-compared-contrasted/.
Hope this helps!
