Deploy WCF Service with WebRole to non-Azure Hoster

Question

I have a WCF Service with one WebRole and one WorkerRole for the communication with the Azure database. This service is deployed into a Windows Azure Cloud. Everything works fine.

But now, I have a (more or less academic) question: Is it possible to deploy this service to another hoster, means not to the Azure Cloud. If yes, which parts of the program have to be changed and which software (ie IIS) is need in the other hosting environment.

Background of this question is: My customer wants to know, whether he is independant of the Azure Cloud or not.

Thanks a lot for your answers!

Answer 1

Simple Answer

What happens when you run your code directly in Visual Studio (ie not in the emulator)?

Long Answer

When you create a Role in Azure, Visual Studio adds a class to your project which inherits RoleEntryPoint. This class contains functions for OnStart, OnStop and Run.

For the WebRole, this class is not necessary, in fact the object that is created is in a separate process to your ASP.NET application. If you have any code in here, you need to put it somewhere else when you run it on premises (or other cloud). Perhaps a Windows Service, perhaps Global.asax?

As for the WorkerRole, it also has a RoleEntryPoint, but this is the main entry point for your application. In this case you could probably create a new Windows Service project in Visual Studio, and re-use the same logic. Whatever code you've put in your 'Run' function, you could probably just move to a shared DLL, which can be accessed from either the WorkerRole or Windows Service.

As for other Azure features (blobs, queues, tables, SQL Database, Access Control Service, Service Bus etc. etc...), these can still be used from outside Azure, or you could seek an alternative for each. For illustrative purposes you could do this:

Queues -> MSMQ

Blobs -> File System

SQL Database -> SQL Server

If you use the Inversion of Control pattern, you could abstract away the implementation of these technologies, to make your application agnostic of which underlying technology is being used. This makes it really easy to switch implementations (and cloud vendors).