Blither, Blather, Web Content Management.
Blog » Anyone can design a scalable SharePoint farm.

Anyone can design a scalable SharePoint farm.

I haven’t always been a SharePoint developer.  When I was in college, before I switched to CSE (Computer Science Engineering), I was studying to be a ME (Mechanical Engineer).  I was in my sophomore or junior year taking a statics class and my professor said something that I will always remember.  Statics, if you don’t know, is the the study of forces on an object while it is at rest.  For example if you have a bridge which made up by a bunch of triangular supports and you place a mass (aka a car) at a specific point on that bridge, one can calculate the stress on every member that makes up the bridge.  As we are going through one of these exercises, the professor says:

“Anyone can design a bridge that can carry a car from one river bank to the other.  It’s an engineer’s job to design one that will just barely carry it over.” (loosely quoted)

You can probably see where this is going…

I was hypothetically doing some work for a medium sized client recently who’s SP Farm was designed by a different consulting company.  Their environment is top of the line – 6 front end webs (FEW), failover DBs, indexing servers, multiple representative pre-prod environments. It’s built to scream. In a company 3 times bigger than this one, it would be a near perfect farm.  However, here it’s overkill.  A standard 2 FEW farm would likely have been more than adequate for the next couple years.

So is there such thing as overbuilding your SharePoint farm and is there harm in it?

Yes, and yes, and the harm is monetary.

To start with, let’s talk initial financial costs.  Servers aren’t cheap, and this company purchased 3 times as many as they needed.

Hardware later is always cheaper than hardware now. Had this company started with 2 FEW, they could have added additional hardware as it was needed later at a substantial discount (or better hardware at the same cost).  That’s just considering the FEWs;  let’s not discount (get it?) the potential for reducing other hardware costs, such as the number of servers required in the pre-prod environments to give an adequate representation of the production environment.

Beyond the initial costs, there is also an increased maintenance cost.  Installing patches across these additional servers means increased time and planning efforts.  Statistically, 6 FEW provides better uptime than 2 FEW, but that is from the end user’s perspective.  From a server admin’s perspective, 4 additional FEW means 4 additional points of failure.  Statistically the time spent remediating hardware related issues has increased by a factor of 3 for this team, and that doesn’t account for the extra time needed to isolate issues in this now more complex environment.

Now the problem that I think hits hardest: the increased cost of most third party add-ons.  As you may know, most third party SharePoint products are licensed by the FEW.  This company must now pay 3 times more for any additional products they want to use.  I don’t hide the fact that I like Nintex Workflow and I think it’s probably the smartest additional investment a company can make in their SharePoint farm.  The cost/value of Nintex is outstanding in a properly sized farm.  (For most medium size business, with a two FEW farm, the purchase justification is a no-brainer).  However, having more FEWs doesn’t mean the product adds any more value. The value of the product is fixed.  Instead more FEW simply means the cost goes up which throws off the ratio and makes the purchase justification more difficult.

Conclusion: Don’t just build the fastest SharePoint farm your company can afford.  Do the capacity planning and then design a farm that meets your company’s needs. Reevaluate your capacity plan every 6-12 months to make sure you’re on track.  If your actual growth doesn’t match the plan, then adjust the plan accordingly.

Posted: 8/16/2011 4:48:00 AM by Ryan Miller | with 0 comments
Filed under: SharePoint