Seeing how much hype there is about cloud computing / hosting / software as a service, I thought it would be good to share some of cloud computing’s dirty little secrets. Few people in the industry talk about these, and customers usually don’t find out until there’s no going back.

Cost

Whether hosting SharePoint costs less than hosting it on premises greatly depends on how you measure cost. Hosting companies measure it in terms of setup costs (your initial investment) and the monthly plan cost (your marginal cost). But you need to measure “cost” in terms of cumulative cost from the day SharePoint is made available. Here’s why…

Making use of hosted services provides a cost-effective way to deploy SharePoint to your organization. However, it’s like renting an apartment vs. buying a house: you don’t need a down payment to rent, but you never stop paying rent. The service fee is a constant monthly expense that never goes away.

Need a second service? There’s another monthly fee. The problem of course is that you never actually get ROI with this model. It’s more like a reverse ROI. You start out ahead of the game, because you had few start up costs. But after a few months, you get further and further behind, because at some point you’ve paid as much in service fees as it would have cost to do the implementation in house. And you keep on paying. Indefinitely.

Want to see how the numbers play out? Check out my post on how you can host SharePoint cheaper than the cloud hosting providers and realize that cost savings in between 5 to 11 months.

Add-on Availability and Customizability

SharePoint is not just a product, SharePoint is a platform. That means that in order to maximize the value you get from SharePoint, you will probably want to customize and extend it with one or more add-ons. The problem is that only a fraction of the SharePoint add-ons will work on shared hosting environments like Microsoft’s Office 365.

The reason that so few add-ons work with Cloud-based SharePoint offerings is that most of the cloud providers use a multi-tenant SharePoint hosting model to keep costs down and increase profits. To extend the apartment rental analogy, in this model multiple renters are sharing the same building (the SharePoint farm). And just like when you rent an apartment, there are lots of restrictions on how much customizations you can apply to your space. These restrictions limit not only which add-ons you can install into your SharePoint cloud but also on what types of customizations you can implement.

You can get hosting plans that offer more support for 3rd party add-ons and customizations, but you will need to use the more expensive dedicated or virtual private hosting options. You may also have to assume a higher management burden with these hosting options thereby further increasing your costs and negating some of the benefits of cloud-based SharePoint hosting.

WAN vs. LAN bandwidth

How much bandwidth do most organizations have on their LANs? Most have 1,000 Mbps. Some even have 10,000 Mbps. How much bandwidth do these organizations have on their WANs? Usually less than 50 Mbps. That means that most organizations have roughly 20 times (2,000%) and 200 times (20,000%) the bandwidth on the LANs as on their WANs.

Cloud computing uses WAN bandwidth like it’s going out of style. That’s important since your users access your hosted SharePoint through the WAN. Working with SharePoint in the cloud is not like accessing other web-based cloud services. With SharePoint, users are not just browsing pages, they will regularly open and save large documents anywhere from 1 MB to 30 MB in size. Users may perceive a well-implemented SharePoint cloud service as being much slower and unresponsive as compared to even a mediocrely implemented in-house SharePoint simply due to WAN network limitations. SharePoint in the cloud is not slower; the problem lies with the users’ perceptions caused by their limited bandwidth in accessing SharePoint in the cloud.

WAN vs. LAN reliability

How often does your LAN go down? How often does your WAN go down? Imagine losing access to all of your organization’s documents in the event of an Internet connection loss? Even worse, how long does it take for the Internet connection to come back up? An hour? A day? Having a highly available SharePoint environment in the cloud does no good when your Internet connection goes down.

Switching Providers

How easy is it to migrate data from one SharePoint farm to another? Not too bad you say, you just need the right tools. Ok, now what about if you only had a 50 Mbps network connection to the source and target farms? Well, it can still be done, you say. It will just take a lot longer to do the data assessment and to actually move over the data. Verifying will also take a long time, but that’s what nights and weekends are for.Ok, now what if you didn’t have administrative access to either the source or target SharePoint farms, so you can’t install those critical migration tools? That could definitely be a problem. How do you move your SharePoint data if you can’t install the migration tools?

And that’s just the start. What about migrating over the user accounts? How about the permissions and version information? What about workflows? The reality is that once you pick a SharePoint hosting provider you should be prepared to stick with that provider for at least 3-5 years. That is a really long commitment, especially in the IT industry where things change so quickly.

Single Sign-on

Single sign-on (SSO) is the concept that a user has to enter his or her credentials into one system, and that the credentials would get propagated into all other systems that the user needs to access. For example, a user would login to his or her desktop computer and would be able to access the organization’s email and portal systems without additional logins. For most organizations running Microsoft software in-house, this is a daily reality because all of the organizations systems including SharePoint are running off of the same user directory service, the organization’s Active Directory. But what happens when the organization makes use of SharePoint in the cloud? That service has its own usernames and passwords. Users now have an additional login for the hosted service. Web browsers can help by caching user credentials on their desktops, but there are other desktop applications that don’t do as good a job with that. The issue multiplies as the organization adds additional services, each service requiring its own username and password.

Some SharePoint hosting providers like Microsoft Office 365 are now starting to make desktop tools available to ease users’ single sign-on woes. If you are shopping around for SharePoint cloud providers, ask what their single sign-on solution is, how it is deployed and managed, what infrastructure it needs to support it, and what additional fees you will incur to use it.

SharePoint 2010 also supports a more standards-based single sign-on capability called Claims Based Authentication. Claims is designed to allow users to access multiple systems from different organizations with a single username / password, but Claims can be very challenging to set up as it does require you to have some infrastructure and configuration on your end.

Systems Integration

Does this sound familiar:

User: “Will I be able to keep all of my data in SharePoint?”

IT: “Sure….except we have this one system that….”

The fact is that most organizations have at least some data that is not in SharePoint and should not go into SharePoint. That’s ok. SharePoint has lots of great tools and APIs that allow users to access data that SharePoint does not manage from external systems.

When SharePoint and the external systems are all on your internal network, and you have the ability to develop or deploy the appropriate connectors, integrating the systems is doable. But when SharePoint is in the cloud (on the Internet) and you your have more restrictions into the types of components you can deploy to SharePoint, things become complex (and potentially expensive) very quickly. Very simple things that used to be easy all of a sudden become hard.

For example, let’s say that you have a network file share with 5 TB of files that you would like to be searchable through SharePoint search, but you don’t want to upload the files into SharePoint (a very common requirement I might add). This is very easy to do when SharePoint and the network file share are on your internal network but becomes much, much harder when SharePoint is in the cloud.

I don’t want to imply that there is no way to deal with systems integration scenarios when one or more systems are hosted in the cloud. There are certainly approaches that can work. But these approaches are very different from what works when all of the systems are inside of your network.

Conclusion

Does this mean that hosting in the cloud is bad? No, not all. There are many potential benefits to subscribing to SharePoint in the cloud. But you do need to keep in mind that when you change your system’s topology (on premises vs. in the cloud) you will have trade offs. You need to be aware both of what you are getting and what you are giving up when you extend your systems into the cloud.