Windows Azure Architecture Guide – Part 2 – Tenant & Public site (and some notes on geo-location)

As you might recall from my the introduction post, Tailspin has essentially 3 sites: the ISV (#1) , the tenants (#2) and the public (3):

The usage patterns of these are all very different: #1 would probably have 10’s of users, #2 (hopefully for TailSpin) will have 1000’s of users (maybe 10,000s), but #3 can potentially have 100,000’s or even 1,000,000’s of users. Moreover, #3 might have burst demands as surveys are most probably rather short lived.

In Tailspin Surveys the Public site will be hosted separately from the tenants site, precisely to provide the flexibility of managing each in a different way.

A few observations:

• If we use the same Hosted Service, but different web roles, then each on is differentiated by a port. for example: https://tailspin.cloudapp.net:80 and https://tailspin.cloudapp.net:81 for each web role.
• In Tailspin specifics, the tenant site is under SSL, but not the public site, so this differentiation is “automatic”  as HTTPS uses port 443 and HTTP port 80. However, this might not be true for all applications.
• If you need a different name altogether, you might want to consider using a different “hosted service”
• Taispin is a “geo aware” service. This means that tenants can chose to subscribe to a geo-specific Tailspin instance. For example, a US company, will probably choose a US based service, European companies will subscribe to the Europe based service, etc. However, there might be a situation where a say US based company targets a specific survey to a different location. This is a subtle, but important difference. Keeping the site to host tenants pages and surveys separate might help, but it doesn’t automatically solve the synching issue:

 

Depending how the red line is implemented there might be little benefits of European users going to a European datacenter. The best results would probably be achieved if everything that needs to happen “online” is kept on the same place. Here’s an example of what you’d probably want to avoid: having the repository classes in the European site call the US based storage to render the survey. You’d probably want to push the definitions of a survey to the European datacenter (that happens once) and then collect all surveys there. Then, when you are done (or using a worker process), you would synch the results back to the US. More or less like this:

Steps 2 and 4 would happen only once. Step 3 is all local, minimizing response time for those users.