Advanced setup of sites

Vote:
 

I am planning a new setup for a little more advanced site where the demands are a litte more complex.

The key setup is like this:

www.customer.com  (the public site)
www.customer.com/VisitorsLogedIn (a subsite to the public when a visistor is logged in)
www.customer.com/b2b (a subsite for b2b)

This setup would be pretty simple in normal case, but I want to do these three to be able to live there own life, meaning they have their own database and codebase.

The reason I want that is that they have their own schedule for updates and their own developer teams and so on.

Anyone knowing if this is a possible senario?

#118260
Mar 03, 2015 14:55
Vote:
 

Hi,

No, I'm not multisites expert but my thought is you can set up three separated sites, each point to an url as you listed.

If an user logs in on public site, then redirect them to the second site.

The only issue I see is to sync users between databases, looks like a custom membership provider sharing a database is possible (if you use OpenId or AD account then it'll be much easier).

/Q

#118266
Mar 03, 2015 15:59
Ted
Vote:
 

We've done similar setups in the past with virtual directories as apps in IIS. However, I do seem to remember it not being entirely supported by EPiServer at the time (this was EPiServer 5 and 6 websites).

#118270
Mar 03, 2015 16:30
Vote:
 

Thanks for your feedback

I forgot to mention that all these sites are going to be Azure websites.

Quan, all authentications are done with federated security so that is no problem

#118277
Edited, Mar 03, 2015 19:15
Vote:
 

As far as I know Azure Websites has to have 1 codebase. You could of course then setup 3 different Azure Websites with 3 different codebases - but I'm not sure you can do that on the same domain. Maybe some redirects are in order?

I would probably opt for 1 codebase - Updating Azure websites is pretty smooth - especially if you use multiple deployment slots.

#118379
Mar 05, 2015 10:27
Vote:
 

Thanks Allan

I am right now trying out the virtual directory function in Azure, like they do in this article, will get back and report on the progress

http://blogs.msdn.com/b/tomholl/archive/2014/09/22/deploying-multiple-virtual-directories-to-a-single-azure-website.aspx

#118380
Mar 05, 2015 10:31
Vote:
 

It all looked good first, but then it complained over dublicated keys and so on in web.config.
It was the same thing if I did it as a virtual directory on my IIS

Got it to work with the beautiful clear tag :)

#118399
Edited, Mar 05, 2015 14:16
Vote:
 

The other approach you could take is Application Request Routing. This would mean you would have to drop another IaaS server in front of your Azure sites, which could all be set up entirely seperately. The ARR module, whigh is part of IIS allows you to act as a reverse proxy to route requests to particular servers / sites. This is obviously more expensive as you have another box (or more of you need some resilience), however you can scale out rather easily. It's a pretty common technique in the enterprise Apache world.

https://brentdacodemonkey.wordpress.com/2014/02/06/arr-as-a-highly-available-reverse-proxy-in-windows-azure/

Disclaimer I've never tried it on Azure, but the above (which is a more complex scenario) seem to work well. 

#118478
Mar 06, 2015 20:50
Vote:
 

Thanks Mark, will check it out

#118503
Mar 09, 2015 8:05
Vote:
 

I would also set the "dir"-sites up running sub domain names and put a reverse-proxy-something in front of them as Mark suggests. I recall a client of ours had that setup for an application we were integrating with. They were using Squid.

#118506
Mar 09, 2015 8:17
Vote:
 

Have you considerd the licensing issues also?
/K

#118514
Mar 09, 2015 10:49
Vote:
 

Khan, yes that is a part of it, I am trying to figure out the license model for Azure now, but right now it looks like it will be three license instead of one, and that is a thing to consider in the choise for solution

#118515
Mar 09, 2015 10:54