This project is read-only.

Azure Web Role Load Balancing Implications

Topics: Installing Orchard
May 23, 2013 at 2:06 PM
Hi Folks,

I just want to ask/confirm a few things about Orchard when running in an Azure web role (not website)

Caching: Orchard has a caching interface which we have been using quite happily during development. What does this use when in Azure? Does it use Azure's ApplicationServer DataCache framework ( If not, does it cache/invalidate cache across all instances in a role/cloud service?

SessionState: I've already had a previous answer saying that Orchard does not use session, so it is not implemented for Azure situations. We already have a machine key in our web.config. Are there any gotcha's in enabling the Azure Cache based SessionState provider with Orchard that people are aware of? (It is possible that we might amend our current work to try and remain "session-less", but it might be hard to change our breadcrumb manager.


May 23, 2013 at 4:20 PM
As a further thought: Is it possible to Identify whether you are in Azure from within a module? In a normal Application you can use RoleEnvironment.IsAvailable, but that needs Azure packages in the project. I'm not really keen on adding that to modules if at all possible.
May 30, 2013 at 4:04 PM
No one has ever had Orchard with more than one instance running in a web role?
May 30, 2013 at 4:19 PM
LordSaul wrote:
No one has ever had Orchard with more than one instance running in a web role?
Many people have, just none of them have answered your question.
May 30, 2013 at 4:22 PM
Why do you want to check if you are in Azure from within a module? Shouldn't you abstract that away, the same way the file system stuff is done (you don't ever write code to check if you are running under Azure when you want to read/write files, but the correct file storage provider implementation is used under the Orchard Azure project. Can you do something similar for what you are doing?
May 30, 2013 at 4:28 PM
Edited May 30, 2013 at 4:31 PM
yes - I guess that that is my point. I want to switch Implementations of a provider I have written (yes - everything is interfaced), depending on whether I am in Azure or not. To do that, I need to be able to identify it from the module that does the Autofac registration. I can't see how I can make that switch in my composition root, without amending the Orchard.Azure project itself. I was hoping that it had abstracted "RoleEnvironment" to an interface that could be used from within Modules, but I don't think it does.

How does orchard switch its file system stuff currently when going to azure?

Eidt: Looks like it is using an Autofac xml configuration in Host.Config. While I could add my registrations here, it would not be very modular any more...
May 30, 2013 at 5:25 PM
Look at the orchard azure solution, i think the container for the entire web app, the Orchard Shell, is constructed differently for the Azure solution. I believe that's where the registration is done.

If I were doing what you are doing, I might just modify this shell setup to set up the different dependency for Azure. There might be a better hook that you can take advantage of to do the registration, but I don't know of it. Maybe one of the more core devs can shed some light.
May 30, 2013 at 5:43 PM
If you need to switch implementations, it's configuration based. For azure we still need a dedicated solution/project as the Web Role needs one, then the services are just defined in the config/Sites.config file.
May 30, 2013 at 7:08 PM
Edited May 30, 2013 at 7:11 PM
So in this instance we need to Modify Orchard.Azure.Web, and keep track for Orchard 1.7? We have a few things that modify core orchard stuff (mostly configs fortunately). I've just always tried to strongly assess the need first, as each one is a barrier to upgrade.

Still, at least I've had the idea sanity checked - thanks.

Sebastian - if I wanted to dig further, would extending the shell interface to understand the concept of "Environment" be something that sounds viable/acceptable to core devs? Or maybe providing some form of IEnvironmentProvider type thing?
May 30, 2013 at 7:27 PM
LordSaul, the way I handle this kind of thing is to make my project's repo a private fork of the orchard repo. When I want to upgrade it's very easy, just pull changes from the main orchard repo. My changes to core orchard code are pretty minimal (+ config changes). So far never any merge conflicts.

My modules and theme(s) exist as part of the private repo, and that's not a problem when upgrading orchard versions because there is zero chance the changes in the main orchard repo would try to overwrite my modules or themes.

In the rare case when you have a conflict, you should be able to resolve by hand. So far after a year of doing this, the upgrades have always gone smoothly. I started writing a blog about it, but got sidetracked. I'll finish it soon and post it because this seems to come up every now and then.
May 30, 2013 at 7:30 PM
Glad to hear you say this - we were discussing this very idea earlier today and wondering if it was feasible. Would really love to see that blog post for the inside track ;)