Written by:
9/6/2010 

In a previous blog entry, I spoke about how you can add portals to your DotNetNuke website, but one of you pointed out that I didn’t speak to why one might choose to have multiple portals on a single instance of DNN versus having an instance of DNN for each website.  At first, I was shocked, “Why did I not think to speak about that?!”  However, as it sunk in, I am happy that I didn’t speak about it then.  This topic certainly deserves its own post.

What is an Instance?

Before I begin, I want to specify what I mean by instance in this post.  Even though this definition doesn’t really change for me, and instance of DNN can be defined as a single file system and IIS reference to an installation of DotNetNuke.  You can and probably do have a varied definition, but this will serve our needs for this post.

Comparing Multi-Portal vs. Single Portal Instances

Need a new site?  Just add it to the DNN site you already have.  You don’t have to waste time with all of that other stuff.

At first blush, it would seem a logical and efficient thing to do.  After all, you’re saving a ton of time and money by adding your most recent site to an existing DNN portal instance.  All you have to do is add an IIS and DNS reference, and add the site to your existing one.  Easy stuff, right?  Right.

On the surface, having a single instance seems to be the right thing to do.  Just off of the top of my head, you would:

• Save time upgrading and maintaining a single instance
• Save time and money installing extensions on a single instance
• Not have to remember as many sets of login credentials
• Monitor and report on multiple sites from a single portal
• Manage a single set of settings across portals

What one really needs to think about are the immediate and long-term concerns in marrying two or more sites in a single installation of DNN.  In order to efficiently contrast the pros and cons though, one must already be experienced in administrating a handful of DotNetNuke sites.  However, I will attempt to shed some light on it for you now.  Put on your shades!  That was a joke.  You probably can’t read the rest of this post with your shades on.  Take them off, silly!

No matter if you have two or 1000 sites on your instance of DNN, you have to remember that all of these sites have several things in common with each other.  I won’t mention them all, but some of the most important things they will share are:

• Modules
• Widgets
• Skins
• Providers
• Host Settings
• Vendors (sometimes)
• Database
• Application Pool in IIS (sometimes)
• Lists
• and more…

There are a seemingly endless number of examples of potential complications here when you have two or more sites in the same instance.  Keeping in mind that they share all of the above resources, a multi-portal instance of DNN would have the minimum administrative concerns:

• Shared modules/widgets/skins being used by unauthorized or inexperienced site administrators
• A 3rd party module or provider not able to scale to multiple sites
• A provider not being suitable for one or more sites
• Vendors/affiliates/lists not being appropriate for one or more sites
• Performance and size restriction limits in the Application Pool or the database
• Licensing costs and/or restrictions

Probably the first and foremost thing to think about when thinking about shared resources on a single DNN instance with multiple sites on it is that if one site goes down, all of the sites go down.  For some of you, that proposition is scary enough.  You don’t have to read any more.  ;)

Like I said, those are some of the most common concerns.  To put that into context, imagine that you are managing the site for a handful of local pizzerias.  First of all congratulations!  I am sure you have your share of discounted or free pizza now. 

Each of these pizzerias no doubt have a need for modules that provide functionality for menus, feedback, HTML content, map, location locator, and maybe even an online delivery tool.  All of these pizzerias will likely function fine on a single instance.  However, let’s keep going.  I am going to talk about management, or administration of the portal(s).

One of your clients decides that you’re doing a fantastic job, and refers their friend to you, and she owns a book store.  However, she wants to have an online shopping cart and auction tool to allow online customers to buy her books.  Think about that for a second…

This new client will need to have at least two more modules installed on the site – a shopping cart and a CRM module.  It may not be a big deal at first, but you will not only need to install those modules, but you will need to manage the visibility of those modules, so that your pizzeria clients don’t try to use the shopping cart and CRM.  As you add more and more clients, this problem begins to grow, very much like a snowball in your favorite childhood cartoons that gets bigger and bigger as it gets down the mountainside. 

I happen to know a prominent DNN ecosystem member who was managing such an instance for quite a long time.  I won’t disclose their name or the company name, because I am not sure they’d want me to, but they were running over 800 sites on a single instance of DotNetNuke at one time.  I know you might not believe me, but it’s true. 

Yes.  This is possible and it’s done by at least a small number of people that I know personally.  The key to making it work is to make sure you have a VERY beefy web and SQL server and impeccable organizational skills to manage all of those sites on a single instance.

Think about it.  That’s over 800 websites, with at least 50 different use cases and purposes for the websites.  From a management perspective, that’s nothing short of a nightmare.  When asked at a speaking event, the company’s founder was asked if he suggested that others do the same, and he simply replied without missing a beat and a telling smile, “No.”  Having such an instance of DNN eventually requires a full-time site administrator, who just manages extensions and management of portals.

That company has since divided the 800+ sites into common user cases, and now they site on at least 4-5 instances of DNN, but still have around 200 sites per instance.

Cost of Licensing

That was management, but what about something that more directly hits your pocket?  Another consideration when mulling over the decision to host multiple sites, you need to think about the cost of licensing.  It’s not uncommon for a company that builds a module to have different pricing options for a multi-portal instance, versus a single instance.  Depending on the vendor and the module, there could be cost benefits either way. 

Between the cost of licensing for the various extensions and plug-ins you might be using, you will need to factor licensing in as one of your main points of consideration.  I doubt you will be building every module in use on that instance.

If you end up having a single instance of DNN per site, simply wrap the cost of the extensions into the costs that you charge your customer – even if your customer is your own company, or an internal department.

Performance

In the probably the best example of a good use case to have a multi-portal instance of DNN, you might have a single installation that’s only meant for catalog-type websites.  By catalog, I mean that the website primarily functions and exists to provide content, nothing more.  It is simply an online landing page for an organization, product, or cause.  In such cases, your primary module in use will be the Text/HTML Module.

What about more complicated websites though? 

If you have a specific use case for a group of sites that all have similar, but complicated features, this might be a different proposition.  Let’s say that this use case is for extranets.  You have an instance that hosts 50 or more different extranet sites for clients. 

Each extranet will have its own required and optional features, but since they’re all extranets, there’s no harm in having every module that an extranet would require now, and in the future.  Right?  Kinda…

One thing to remember about modules, providers, and most other extensions, is that nearly all of them come packaged with a DLL.  It’s not important know what that is, if you don’t already – but it basically allows the module to function.  The more modules you have installed in your instance of DNN, the slower that all of the sites will be - potentially.

Just so you know, it’s very possible to have a ton of extensions installed and in use on your site without performance problems, but it’s still something to worry about if your server resources are not optimized for that kind of load.

This little fact becomes even more relevant and more complicated when we think about the other shared resources too. 

As a database grows, the tables and indexes it has do as well.  While in many cases, this can scale to meet your needs just fine, it is a major concern to always be aware of.  In general, for larger sites a beefy server and decent clean-up routine will do just fine.

If your sites all share the same application pool on IIS, they all will also share the same features or restrictions in the application pool.  While there are cases and ways where the individual sites can have their own application pool, it’s not always possible.  For example, you might be limited by your webhost, or your licensing.  In these cases, all of your sites are sharing resources when they don’t necessarily have to.  For example, if each site has it’s own application pool, it will have access to its own group of resources and performance benefits, especially when considering a multi-core processor on most web servers.  However, you once again need to worry about licensing in some cases.

Backing Yourself into a Corner

When you have a single site on a single instance of DotNetNuke, there’s no problems when a customer comes to you and asks you to switch out the HTML editor to one they like better, as an example.  However, if you have several sites on the same instance of DNN, you might be forced to simply tell the customer that you can’t help them.  What’s more, if you’re a subscriber to the FAWTSY (find a way to say yes) philosophy, you might need to perform additional work to extract their portal to a new instance of their own.  This has multiple implications that I am sure that the customer won’t like, including: potential downtime, extra cost for the portal extraction, additional cost for module licensing, additional hosting costs, and so on.

In my experience, one of the factors to weigh in when deciding on how many sites to have on a single instance, you really need to consider the personality and culture of the client and their company to anticipate use cases like I just mentioned.

I am sure that you are not thinking that you and your business will stop growing today.  Similarly, your clients probably are not thinking that way either.  When you have multiple sites on a single instance of DNN, you are making an assumption that every site in that instance is never going to have a need for a new feature.  They can, and they will.

A prime example can be made of the previous use case I introduced with extranets.  Let’s assume that you were able to get all of your extranets working using a very well-planned set of modules that everyone is happy with.  Hopefully, in order to keep paying you, these companies are all growing their businesses.  Assuming that you have 50 or more extranets, it wouldn’t be far-fetched to imagine that all of a sudden 3 different customers would ask for integration into different products, such as SharePoint, Salesforce, and SmarterTools. 

What now?  Seriously…  You may not be architecturally set-up to handle such a situation, and still keep your price points at a level where your customers will be happy either during or after such a request.

Let’s Summarize this Already!

I am a fan of both types of instances.  However, the instances that favor multi-portal implementations are not the common scenario that you should come to accept.  In fact, it’s quite the contrary.  Such instances should be simple in nature, and have a very small potential for change, or anticipate changes where all of the sites would require the same updates for the same reasons.

Otherwise, it’s my personal opinion that you should have a separate instance of DNN for each company and use case.  If you’re concerned about licensing or other costs, it should be wrapped into your quotes and billing.  Otherwise, you will definitely end up finding yourself in a corner where you’re going to be telling a customer that you either (1) cannot do what they want without significant extra cost; (2) you cannot do what they want you to do.

The best scenarios where I see multi-portal instances working are catalog-type sites.  Anything else that’s more dynamic is just asking for a headache in the future.

I hope this deep-dive has helped you.

Trackback Print

Tags:

Categories: DotNetNuke

Location: Blogs The Mighty Blog

Your name:
Your email:
	(Optional) Email used only to show Gravatar.
Your website:
Title:
Comment:
Add Comment   Cancel