PowerDNN

 
I.    Introduction
DotNetNuke is a rapidly evolving framework developed in the Microsoft .NET programming environment.  It has grown from being a basic ASP.NET website starter kit into an application delivery platform used for solutions such as information workflow and document management.  DotNetNuke allows vertical solution providers to quickly drag-and-drop business-worthy solutions together literally over night.

II.    Purpose
The purpose of this document is to provide a best practices document for vertical solution providers who are either currently utilizing or plan to start utilizing the DotNetNuke platform.  This document will focus on designs that provide the highest level of reliability, scalability, and performance.  Total Cost of Ownership will also be briefly discussed.

III.    Multiple Portals - The Root of Most Evils
When working with solution providers, the most common source of frustration stems from an improper use of DotNetNuke’s multiple-portal capabilities.  DotNetNuke allows for one installation to run multiple websites within the same file system and database.  Although this is a great feature for people running personal websites who want and need bare-bones quality and service, businesses with business customers implementing business solutions should seldom, if ever, use this capability.  Although using multiple portals may save a few pennies in hosting fees and module purchases, your solution will be less reliable, have worse performance, not be scalable, and will not allow you to provide an enterprise level of service to your customers.

IV.    Reliability
Reliability is the most important factor when implementing business solutions.  Although
DotNetNuke is an excellent framework, bad configurations, rogue modules, or user errors can cause fatal errors.  There are two types of crashes that solution providers may encounter.

IV.A.    Portal Crashes
Portal crashes occur when one portal in a DotNetNuke install ceases to function.  Generally these problems occur as a result of a user, data, or configuration error.  They only affect one portal in the install.

Portal crashes cause a very significant problem because single portals cannot be restored from backups – only entire installations can be reliably restored from backups.  In this case, it is not advisable to restore the entire installation because that will undo any content changes on the various other portals.  If an administrator is not able to manually repair the problem, the only option will be to try to delete the portal from the DotNetNuke install and then recreate it.  Deleting corrupted portals leaves orphaned data in the database and will further deteriorate performance.  Additionally, now all of your clients are running on a degraded DotNetNuke installation.


IV.B.    Install Crashes
Install crashes occur when all portals in the entire DotNetNuke installation cease to function.  Generally these problems occur as a result of a failed module installation, failed DotNetNuke upgrade, or host misconfiguration.

The major impact of an install crash stems from the fact that all clients on the installation are not working.  If there were 100 portals in that DotNetNuke installation, you now have 100 angry customers.  When you restore the installation from a backup, you will have to restore all portals from the backup which will result in a loss of work for all clients.  This will have a significant impact in your credibility to your customer.  Additionally, depending on the situation, you may also have to explain how an error in one of your customer’s sites “propagated” to all of your customers.

V.    Performance
Each portal created adds more records into the DotNetNuke database.  Although initially insignificant, each portal will have its own set of pages, modules, users, roles, permissions, and more.  As the numbers of portals grow, the performance of queries against the DotNetNuke database will decline.  For example, if you have 50 portals with 50 tabs each, that is 2,500 tabs in database.  Regardless of which site you visit in that install installation, the database will have to query over all 2,500 tabs to find only the 50 relevant records!

VI.    Scalability
The two limiting factors in any DotNetNuke installation are CPU and RAM.  In a majority of DNN sites, the effect of adding more disk space or more bandwidth is nominal.  It is, therefore, essential that your infrastructure be able to scale these two factors accordingly.

If one DotNetNuke installation houses multiple portals, and one portal begins using excessive amounts of traffic, there is no good way to separate that client from the others.  A shared hosting customer, for example, may eventually need a full blown webfarm.  Implementing multiple sites in one portal drastically limits the ability to effectively scale the solution.

VI.    Privacy and Security
DotNetNuke is a secure application that has undergone extensive third-party evaluations, however, that does not stop an occasional bug from surfacing or prevent custom modules from cross-portal data leakage.  When working with multiple portals in a single DotNetNuke Installation, if a client requests a backup copy of their own private data, you will not be able to provide only their data.  You will have to provide the entire DotNetNuke install which includes all client data.

VII.    Conclusion
DotNetNuke is an enterprise framework that allows providers to quickly develop solutions for vertical markets.  Starting with an infrastructure that promotes reliability, performance, and scalability is paramount.

VII.    General Q & A

Q:    How often should I upgrade my DotNetNuke Sites?
A:    You should only upgrade your DNN site when there is a business justifiable reason to do so.  Do not upgrade simply to have the newest version.  Generally, only upgrade if there is a security hole, a new feature that is required, or a bug that is impacting usage.

Q:    When I need to upgrade my vertical solution to a new version of DNN, should I upgrade one install or all of them?
A:    All of them because it will make support and configuration management easier.  Depending on your hosting provider, this could be very easy or a lot of work.  For example, PowerDNN has the PowerDNN Control Suite that lets vertical solution providers offer a one-click upgrade any number of DotNetNuke websites in a matter of minutes.

Q:    What version of DotNetNuke should I use for my vertical solution?
A:     It does not matter, but choose a version and stick with it for a while.  Generally final minor releases (ie, 4.3.7 or 4.4.1) work very well because they have had time for most of the bugs to get worked out.  Also, not changing versions on every release will allow you to really learn and understand the nuances of your chosen version.