Running Azure emulators locally for production

Question

I have a project (actually several) that I eventually like to deploy to Azure, so my VS solution contains both web and worker roles and is running successfully on my local emulators. (I also use Table and Blob storage).

I have a Windows 2012 server with port 80 exposed to the www and would like to test the waters without using an Azure account or spending money on that (yet).

When I deploy the Azure emulators on my W2012 server and basically run Azure locally, can this even be done in a production-like environment (with very light traffic)? would performance be impacted seriously by that? Are the emulators intended to be used like that at all or do they decline much in performance in favor of logging and debugging?

I am of course aware that this is not recommended as a whole. Emulators are not for production and all that. I understand that. But I am very curious if someone tried something simular.

Update: I think I was not specific enough with my question. My bad, sorry. So more concrete:

1. In what way is are the emulators burdened by non-performance focused, like logging and debugging?

2. Are the emulators stable? Does anyone have experience with them crashing or slowing down?

3. Do the emulators always, under any circumstance, return the same result as the cloud version of Azure?

Answer 1

There are fundamental differences between Compute and Compute emulator, as well as differences between Storage and Storage emulator. While the links I provided may be a bit outdated (I can't find more recent ones), there are a few immediate things that you should see:

Compute:

• Load balancer behaves differently (for instance: you can still access instances taken out of rotation)
• Instances run in processes vs full virtual machines (meaning you can't test startup scripts that install software, without first uninstalling software locally)
• No SLA whatsoever
• Your environment is only as secure as your local computer
• IP address management is different
• No support for virtual networks (you won't be able to interoperate with Virtual Machines, for example, via internal ports)

Storage:

• No scaling (Azure Storage is a massive multi-tentant system, scaling easily as request traffic rises)
• No durability (Azure Storage is triple-replicated and optionally geo-replicated; local storage sits in a SQL database)
• Blobs are limited to 2GB (vs 200GB / 1TB in Azure Storage)
  • Several other differences across Table and Queue storage)

Also: You'll have no command-line control of your emulated deployment (no PowerShell, no CLI), and you won't be able to view/set anything via the portal.

There are services you can run locally on Windows Server, such as Service Bus and Cache, and you can even install the Azure Pack for Windows Server.

Bottom line: You're not running in Azure with the emulator; your code is executed in local processes with a local standalone database process. You'll have 0 SLA, non-redundant storage, absolutely no visibility into overall system health... It's simply not a production environment.