IF you are developing a brand new site for a new project or perhaps for your brand new startup, it is probably wise to go ahead and host it in the cloud
rather trying to host yourself. But that’s where complexities actually begin. Let’s for the sake of argument say that you are not building static html and
you need some level of dynamic content on your website. The way I see it today on the internet there are four popular front-end engines for building
dynamic web sites PHP, ASP.NET,JSP and perhaps we can throw inColdFusion into the mix as well. There are many large cloud service providers such asAmazon EC2, Rackspace, Windows Azure,
Google App Engine
(not exactly designed to run legacy applications). There are also a ton of small ISPs and Domain Registrar that use their own co-location space to provide
you with slightly more affordable pricing structure but course their SLA comes nowhere
close to the big players.
I will focus on ASP.NET and IIS which are within the realm of my expertise. But some of these points can really apply to LAMP as well.
Let’s assume that your Web Property will contain three distinct services that utilize third-party frameworks Blog, Store, Support. That’s
great because it does not make sense to reinvent the wheel. Chances are that your store could utilize an existing e-commerce engine, your blog can be
created using a CMS like umbraco or
perhaps a pure blog engine, and your Support Section can use Q/A Search Framework that is already developed by a third-party.
The Old Bad Choice:
It used to be that folks would simply create a folder and drop that those “apps”/Websites under a specific folder at the root of their Parent website.
Let’s say your company website is called www.GreatestCompanyOnMars.com
Then if you decided to build your website using IIS the root directory could look something like this.
Then some of your IIS folder layout would like this:
But simply copying and pasting code from a third-party provider into a subfolder after a while was proven to be not a viable option for variety of reasons.
One obvious issue might be that your Main Website is running on say .Net Framework version 3.5 but your Blog
Engine Requires .Net Version 4.5 and then to top it all your Store and Support
Engine each run .Net 1.1 and .Net 2.0. Different Versions of .Net and different applications could rely on
different Version of IIS. For instance if for some odd reason you decided to deploy your website on Windows Server 2003 which runs IIS6 then you would be
rudely awakened by the fact that .Net 4.5 is not supported on IIS6. So then you
have this issue where part of your website could have been running just fine under that platform but because of this thirdparty component you are forced to
move the entire site to a new server configuration.
Another Problem that this might cause is that one of these engines might be depending on a binary library that conflicts with another one. For instance one
might be relying Newtonsoft.json.dll Version 1.0 while another relies on version 2.0 and
since both Assemblies have the same name you will be then forced to tweak that third-party component which was supposed to be plug-and-play so that it
would reference it’s third-party dependency with a different name.
Another issue associated with running all of this code under your Main Website’s App Pool would be Error Handling. You would have go out of your way to
make sure that each section (entity) of the website would handle global uncaught errors in their own especial way. This is very error prone process it is
not unlikely that somehow your parent website ends up catching an error that the blog framework was supposed to catch.
Yet other issues would be related to URL Re-Writing, Redirections, Optimizations, Compression. That is let’s your team decided to use ASP.NET MVC URL
Routing or URL Rewriter to redirect a certain url based on an aggressive regex pattern.
Suddenly you find yourself in situation that some of the pages on your Store or Support Section are resulting in 404 or 302 because they are being redirected by parent website to a different .aspx or
.cshtml template. It is also possible that your configuration based modules and handlers on your parent website kick in when they are not supposed for your
Blog, Store, or Support Sections.
But perhaps the most prevalent issue with this approach is that eventually as a team we lose our discipline. We decide we want something to act a certain
achieve our objective. Pretty soon you find that you have modified their code beyond recognition and when the time comes to upgrade that engine to the new
version you are faced with a ton problems and tough choices to upgrade a component that was boringly designed to make your life simpler.
The Slightly Better Choice:
So the better choice has been for a while that you create a .net App Pool per each Section that we talked about. That is One App Pool for Support, One App
Pool for Blog and One App Pool for the store.
This undoubtedly is a better approach because at least you have a Chinese wall between .NET framework runtime that runs each App Pool (Support, Blog,
Store) the main website. This ensures that an error that occurs in one App does not affect the other. There is also the added benefit that binary
dependencies of one app Pool does not interfere with binary dependencies of the other App Pool or the parent website. It is also conceivable that you can
upgrade an AppPool to use a different IIS PipeLine than the
other App Pool.
Figure below: See that Each the Parent Website would have an App per Blog, Store, Support provisioned under it.
But some issues with this approach remain. Mainly the problem is all of these components need to live on the any server that hosts an instance of this
website. Let’s say you decide to upgrade your Store and it requires Windows Server 2012 or perhaps .Net 5.0 (does not Exists yet) you are required to take
all the servers that are running your app throw them away and upgrade a perfectly stable environment just because one of these third-party components in
your website requires a new Windows or new .Net version.
One More issue with this approach is that if you decided to scale one part of your website (let’s assume it is the blog), you are forced to scale all parts
of website. It is conceivable that you will have thousands of readers on your blog everyday but it may not be as likely for you to have thousands of orders
every day. So using this approach you have just forced yourself to scale all parts of the website up or down all together.
The best choice for Hosting on the cloud:
When you host in the cloud it is always possible to get a Custom Virtual Machine to host your customized virtual machine.
But don’t take it from me look at Windows Azure, Amazon or RackSpace Price Calculators. It’s always more expensive to have a Custom VM that belongs all to
you in the cloud than simply hosting it as a website or Http File Server or SQL Database Or Worker Role in a multi-tenant environment.
It is actually more beneficial for you to host your server on multi-tenant environment since you are not responsible to maintain any of the software on it.
The Cloud Provider would seamlessly switch you to a different host(s) perform all the necessary upgrades for you without you ever doing anything. You don’t
have to worry about vulnerabilities or anyone stealing your SSH or RDP credentials. Oh and multi-tenant environments are much cheaper for you to operate.
If you decided you need a site to run a different version of .net with a click of a button on Management Console you can Upgrade or relegate all instances
of that application to be run on the new desired version.
But one issue with Today’s cloud offering in a multi-tenant environment is that they are far less customizable. For one thing Even Microsoft’s Windows
Azure does not support a Website that has sub-app Pools. What I mean is that you cannot have a website called www.GreatestCompanyOnMars.com that has blog, Store, Support app-pools that run under it.
So we get to what’s the best way to run this this fictitious website called www.greatestCompanyOnMars.com. The best way is to have each one of those sections run under their
sub-domain of the parent domain. For instance when you navigate to “BLOG” and “Store”, “Support” links on your website’s Navigation menu, They would each
point to http://blog.greatestcompanyonmars.comhttp://store.greatestcompanyonmars.com http://support.greatestcompanyonmars.com.
Why would you architect it that way? There are a number of advantages.
· You can Scale each Application (Main Website, sub-domain websites) as its traffic grows or decreases.
· Your entire website does not have to go down if one of these websites go down. For instance if you decided that you need to upgrade your BLOG, but that
requires you to upgrade the SQL tables which take a long time. You could very easily by a few DNS configurations redirect http://blog.greatestcompanyonmars.com to a temporary website hosted by your cloud provider that would
tell customer to check back soon.
· But most importantly this arrangement would make sure that all parts of this product remain completely separate entities.
· It makes it easier for you to geographically expand just part of your offering. So suppose you have large pdf files on your support site. Sincehttp://support.greatestcompanyonmars.com has its own DNS configuration you can easily take advantage of CDN’s only for that static website without ever
touching the rest of your web properties.
· Another Example for selective geographic expansion would be a Bank. Let’s say www.SomeBank.com is hosted on
hundreds of CDN Edge Servers in the U.S. That’s because they want their front page or informational pages such location lookup to be highly available with
minimal lag-time. But when you click on myAccount link and it takes you myaccount.somebank.com which is hosted only at one data center location across the
U.S. That’s because they fill the website having low latency access to the database is more important than the user being able to download the minimal
amount of html in optimized fashion.
This approach to be sure is slightly harder to build. Because Sharing the Navigation Menu and seamless switching between one website to next might not be
always trivial. There is also the slight issue that some of SEO folks in your organization might be resistant to this idea. Because some people in SEO
believe that it is better to bundle all your content under fewer domain and thus raise the relevance or authority of that domain. Well since major
companies such as yahoo, Microsoft, google amazon all run their websites based subdomains, I think it is safe to assume that it does not have a major
impact on domain authority. That’s because they all run under your main domain name anyway which in this example was greatestcompanyonmars.com.
This is approach is definitely easier to maintain for the long run. It also gives you better flexibility to overhaul the technology stack on any given
section of this website rather than the entire website. You could suddenly decide that you want your blog.greatestcompanyonmars.com to be redeveloped using
JavaServer Pages and it would not cause you any major architectural challenges.