We are currently in this inbetween stage of hosting services on a VM in IIS and migrating some of them to Azure.
I have two services, Service A - which inserts items into an Azure Queue Storage and Service B - which is a Console app which uses the Web Job libraries and consumes messages from the Queue.
As far as I understand the Service B (consumer) must be hosted in Azure and be given access to the Azure Queue, but can Service A (producer) that inserts messages into the Queue be hosted in IIS? Is that possible?
I can currently use the local storage emulator to reproduce this behaviour locally, but it's not really something we can use in production. Ideally I'd like the means to connect to the Queue storage remotely, I'm just not sure if it is possible.
The reason why I want to host the Service A in IIS is that it communicates with other IIS hosted services and uses logging to a file, which Azure doesn't support very well and Azure logging would be very different to how we currently monitor/log events.
Any app using the Azure Storage SDK can connect to and work with Storage Queues. The app could be hosted anywhere; in Azure App Service, in Azure VM, On-premises VM, in AWS VM, anywhere.
can Service A (producer) that inserts messages into the Queue be hosted in IIS?
Like Chris said, any app on the internet can insert messages into the Queue if it knows the Storage value and key, if you do not want to let app knows the Azure Storage key but also want to insert messages, please consider use SAS, this is another story. Anyway, please do not worry about this.
Related
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, both works independent of each others.
Previously both application hosted in Azure VM
Recently i have converted my application into Azure Web Role to achieve Scalability.
Now i am working on implementing worker role for Windows service. but i have few confusion that client web project need scalability so i converted web project into azure web role
But in what case using Windows Service as Azure Worker role is better that running service inside VM?
Do i continue with running service in Azure VM?
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!
I have a console app that calls a WCF service. This WCF service is on a Azure Cloud Service VM, and the WCF service is only accessible internally (using Windows creds). The Cloud Services VM has been added to our domain.
I have deployed this console app as an Azure webjob. It is living in an Azure App Services Web App by itself - there is no related web app.
When I run the webjob, I get a "System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at..." exception. Which seems to be expected since the Azure App Services Web App is not on the domain or talking to internal DNS.
My question, can/how can I add the VM that is backing the Azure App Services Wep App to our domain? And if not, what options are there for getting this webjob to talk to internal DNS?
In general when trying to connect with on-premise resources or other private networks from within Azure, there are a few options that you can check out:
Option #1: App Service Environents: https://azure.microsoft.com/en-us/documentation/articles/app-service-app-service-environment-intro/
App Service Environments are isolated to running only a single customer's applications, and are always deployed into a virtual network. Customers have fine-grained control over both inbound and outbound application network traffic, and applications can establish high-speed secure connections over virtual networks to on-premises corporate resources.
This will give you the most flexibility because of the virtual network, but at the highest cost as it is a premium offering.
Option #2: App Service Hybrid Connections: https://azure.microsoft.com/en-us/documentation/articles/integration-hybrid-connection-overview/
Hybrid Connections are a feature of Azure BizTalk Services. Hybrid Connections provide an easy and convenient way to connect the Web Apps feature in Azure App Service (formerly Websites) and the Mobile Apps feature in Azure App Service (formerly Mobile Services) to on-premises resources behind your firewall.
I'm less familiar with this option, but it's design to work with App Service for these types of scenarios. It may be difficult to use if you require access to an internal DNS or domain controller, however.
Option #3: Service Bus Relay: https://azure.microsoft.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-relay/
The Service Bus relay service enables you to build hybrid applications that run in both an Azure datacenter and your own on-premises enterprise environment. The Service Bus relay facilitates this by enabling you to securely expose Windows Communication Foundation (WCF) services that reside within a corporate enterprise network to the public cloud, without having to open a firewall connection, or require intrusive changes to a corporate network infrastructure.
This option has been around for a while and is especially designed for connecting to WCF services. It's not specific to Azure App Service (as you can probably tell from the article) but it might still be a good, fairly light-weight fit for your scenario. However, it also will not help you with DNS and on-premise domain controller.
I'm running an Azure webjob alongside an Azure webapp. The job runs periodically and the result of the job is needed in the webapp. How do I get the result there?
I tried with a WCF netNamedPipeBinding but since there are no startup tasks for Azure webapps I cannot add a net.pipe binding to the IIS website nor can I enable the net.pipe protocol.
I have it working now with a basicHttpBinding but this binding is exposed to the entire internet which I absolutely do not want. I simply want machine-local communication between a webjob and webapp running on the same machine.
CORRECTION: I thought I had it working on Azure but that is not the case. When running on Azure I get an error from the webjob: An attempt was made to access a socket in a way forbidden by its access permissions 127.0.0.1:80 (using basicHttpBinding). Probably the webapp has an internal port number I don't know.
You have a few options:
Use the file system to pass messages
Use Azure Storage Queues to pass messages between the two
Use Azure Service Bus Queue to pass messages
Use any shared storage (database, Azure Storage, etc) to pass messages
The benefit of all these approaches is that it makes your message passing async and thus more resilient to one of the two services (web app or web job) going down for some time.
You can use the file-system to communicate between the WebJob and the Websites.
It is shared between them and between all of your instances.
Simply write a file from the WebJob and use a file system watcher in your webapp to recognize when a file is created or changed.
Note you cannot communicate through localhost in Azure Websites (or WebJobs) and cannot listen on a port that is not 80/443.
You can use azure service bus queue, then point your service (web app) to consume messages from queue.
The closest answer is to set WEBSITE_DISABLE_SCM_SEPARATION=true in App Settings. This will enable WebApp and SCM processes work in same sandbox. Unfortunately this option is deprecated by Azure and no longer supported. Thanks all for attempting the answer. More information can be found here.
I'm writting a mobile application which should receive a notification if a JSON file on an external server is changed.
I would love to do this in Azure by checking every 20 seconds if the file has changed (and if it's the case I send a push-notification).
What's the best way to do this in Azure?
Scheduling options in Azure
Azure Cloud Service
Azure Scheduler - for heavier workloads invoked on other services
Azure Websites WebJobs - for lightweight workloads
Azure Mobile Services Scheduled Job
For your situation probably use Azure Mobile Services to periodically schedule a job and use Mobile Services to send push notifications
I know this question is ambigus but I could find anything relevant.
Is there any software, nuggget, role in SQL, role in Windows Server, or whatever that works like the Azure Queues?
I have a cloud web site running on azure that store some message in an Azure queue. A background service (Azure Web Job) is monitoring the queue, and when there is a new message it is processed on background. I would like to do something like this on premise.
What should I do for create a queue and monitor it from a Windows Service, like in Azure?
If you are looking for feature parity and want to switch between Azure and on-premise; Service Bus for Windows Server does exactly what you are looking for. This is an on-premise installation of the same features offered in the Azure cloud.
Service Bus for Windows Server
The purpose of Service Bus for Windows Server is to provide similar capabilities across Windows Azure and Windows Server, and to enable flexibility in developing and deploying applications. It is built on the same architecture as the Service Bus cloud service and provides scale and resiliency capabilities. The programming model, Visual Studio support, and APIs exposed for developing applications are symmetric to that for the cloud service making it easier to develop applications for either, and switch between the two.
Service Bus for Windows Server 1.1 Overview
If it's just queue's you are looking for you could also work with MSMQ, which can be installed as a Windows feature.
Installing Message Queuing (MSMQ)
Message Queuing (MSMQ) technology enables applications running at different times to communicate across heterogeneous networks and systems that may be temporarily offline. Applications send messages to queues and read messages from queues. Message Queuing (MSMQ)
There are more alternatives for message queue's but these are either already available on your Windows environment or have feature parity with Azure.