Architecting SharePoint: Virtualization and Cloud Decisions

When choosing how to design your SharePoint environment, you need to decide whether to virtualize SharePoint. You also need to decide whether to use a hosted environment, such as Microsoft SharePoint Online.

I'll discuss the reasons for and against virtualizing SharePoint, as well as reasons for and against using SharePoint Online.

I'll also cover how to prove your single-farm or multi-farm design with a working model. (If you haven't yet decided whether to use a single-farm or multi-farm architecture, see "Architecting SharePoint: Choosing a Farm Design.")

The Pros and Cons of Virtualizing SharePoint

I've worked with organizations that virtualize by default, unless it can be proven that a dedicated physical environment is required. However, virtualization has some drawbacks. Like any decision you make it, the decision to virtualize must be rooted in factual requirements.

This is why I'm big on doing your homework, collecting the facts, working with stakeholders, documenting what's agreed on, and escalating issues when required for decisions and conflict resolution.

When virtualization technology was first introduced, I recommended it for development environments and functional testing.

I never recommended it for physical environments and load testing because, when you virtualize, you're creating a very dense environment with several virtual machines (VMs) running side by side on several powerful hosts.

Today, VM technology is greatly improved and therefore the only risks you have are host density and capacity management.

On the positive side, a virtualized environment lets you perform backups and restores quickly as well as migrate VMs between hosts to balance workloads. In addition, you can provision VMs without having to wait for hardware to be ordered and delivered.

That often isn't the case with physical environments.

I've worked with organizations in which there was a two-to-three-month wait for hardware, followed by a couple more months of waiting for the Windows OS, SQL Server, and SharePoint to be loaded on the hardware.

Another benefit of using a virtualized environment is that you'll have higher asset utilization. In contrast, physical environments tend to have lower asset utilization, which can make the financial types nervous because you're carrying a cost structure that doesn't appear optimized for the intended workload and operating budget.

On the negative side, a virtualized environment can be problematic because it's dense (i.e., many VMs are running side by side). If not sized properly and proactively managed for capacity needs, this density can lead to overhead. Specifically, when you virtualize, you might need additional servers to match the capacity delivered by a physical environment.

This can be due to the way the VM service offering is modeled and managed. In addition, many virtualized environments are a shared service designed to house many applications and aren't specific to SharePoint.

Therefore, the VM options available might or might not suite SharePoint. However, if you're able to deploy a virtualized environment built specifically for SharePoint and you have full control over it, you shouldn't experience that type of problem.

You might want to use virtualized farms if:

You shouldn't use virtualized farms if:

If you decide to use a virtualized environment, the following criteria need to be met:

To virtualize a SharePoint farm, you can use Microsoft's virtualization products or other company's virtualization products (e.g., VMware products). The TechNet article "Use best practice configurations for the SharePoint 2013 virtual machines and Hyper-V environment" describes the configuration options for Hyper-V and those options' potential impact on the performance of the virtualization host computer, the VMs, and the SharePoint 2013 farm.

Once your virtualization solution is designed, it's crucial that you test it for capacity, performance, and resilience. If you don't, you could end up trying to troubleshoot performance problems in production.

If you need help determining what to monitor during this testing, you can use the free Performance Analysis of Logs (PAL) tool, which you can download from CodePlex. This powerful tool analyzes Performance Monitor log files using known thresholds.

You can also Visual Studio 2013 to load test various aspects of a SharePoint farm, such as its page load and the time it takes to upload documents, download documents, and get search results. The MSDN Create and run a load test web page discusses how to use Visual Studio 2013 to perform load tests.

The Pros and Cons of Using SharePoint Online

SharePoint Online, which is part of Microsoft Office 365, is a hosted service that can help organizations adopt SharePoint when an on-premises solution isn't viable or an externally hosted solution just makes sense.

Once you get past the hype of the "cloud," hosted solutions can make a lot of sense for organizations that don't have the capital budget for SharePoint and its dependent technologies. (Note that SharePoint Online mainly reduces the upfront capital costs. The operational costs for SharePoint Online are often higher than the operational costs for on-premises solutions, although this varies widely based on a lot of variables.)

SharePoint Online can also make sense for organizations that want to establish an offering that enables staff to collaborate on the Internet but can't leverage their existing environment due to capacity, security, costs, or compliance requirements.

With SharePoint Online, you can deploy a SharePoint offering quickly and with minimal effort. Specifically, there are collocated virtualized Active Directory (AD) servers that connect your environment with Microsoft for authentication, profile import, and other services.

You might want to use SharePoint Online if:

You shouldn't use SharePoint Online if:

For more information about SharePoint Online, see the SharePoint Online Service Description web page.

Proving Your Architecture

Now that you have designed your future environment on paper, it's time for you to test concepts and prove the design with a working model.

But first you need to check to see whether your organization has a policy regarding proof of concepts (POCs), pilots, and solution certification. If such a policy exists, you need to research it.

Here's a general approach you can follow to prove your design, align stakeholders, and mitigate risks:

Perform POC testing with a limited and controlled audience. Why perform POC testing? The main reason is that it lets you test functionality and performance, catching problems sooner rather than later. You don't want to release a solution to a broad audience and experience functional or performance problems. POC testing is also beneficial because it:

POC testing needs to be performed in an environment separate from production.

Perform pilot testing. Once a design has proven itself in POC testing, you need to perform pilot testing using a limited and controlled audience. With pilot testing, you're testing a refined solution. You perform pilot testing for the same reasons you perform POC testing. In addition, pilot testing lets you:

For the pilot testing, you need to:

The Final Step

After performing the POC and pilot tests, the next step is full deployment of the solution. If the POC and pilot tests were performed properly and the results were well documented, your build process in production should be much easier than if you hadn't done the testing.

I'm not implying your installation will be hassle free, but there should be fewer surprises related to the solution and its operational readiness. Generally, the final build uncovers environmental problems, such as problems with security (e.g., service accounts, Service Principal Names—SPNs), hardware availability, and data center readiness (e.g., space, power).

Generally, organizations have a checklist for transitioning the architecture (the end solution) to the IT staff members after the build is complete.

This checklist includes transferring project documents (e.g., requirements, designs, test reports), providing training, functional and performance testing, operational toolset testing, and providing administration IDs.

If the architecture design process is well executed, the IT staff will be involved much earlier in the process. In other words, the end solution won't be thrown over the fence to the IT staff members, who must then fend for themselves. I witnessed one case in which a problem-ridden solution was forced on the IT staff. It took three years and millions of dollars to stabilize the solution.

Advice from the Trenches

"Do your homework" is sage advice when you're designing a SharePoint architecture. Here's some more advice from someone who has worked the trenches: