Hosting Choices:
Vendor-Hosted or Self-Hosted?

This information originally appeared as a series of weblog posts during Februrary 2008.

Web 2.0 Workgroup Productivity Applications

This document looks at the question of where to host so-called "web 2.0" workgroup productivity applications. These applications have opened a lot of doors for a lot of people and teams, and it's truly fantastic that you no longer need an IT department to take advantage of all the new generation of tools.

There's such a wide variety of tools these days, and there are a lot of things you should consider. Figuring out if you should be hosting things yourself or if you should go with a vendor-hosted solution is one of those things, and is not a trivial decision. This document will touch on many aspects of this decision.

We're not exactly unbiased of course, because ProjectForum is exactly the sort of web 2.0 workgroup productivity application we're talking about. But because we offer both vendor-hosted and self-hosted options, we think we have a useful perspective on this issue.

Who this information is for

We've put this information together to help workgroups who think that some of this "Web 2.0" technology that everyone is talking about may possibly be helpful in getting their work done.

What is a workgroup? Any group of people working together on some common goal or project. Sure, that's a facetious answer, but think about all the different ways you can put people together that fit that description. A small business or SME as a whole might be a workgroup. So might a single department in a larger organization, or the ever-popular cross-functional business team. People from different organizations working on a joint venture certainly can constitute a workgroup. As can so-called "virtual teams" that come together for a specific project. Consultants and their clients often work closely together as a workgroup. And it doesn't just have to be commercial ventures; a group of volunteers at a non-profit or a group of teachers developing a shared learning resource are also examples of workgroups.

In most contexts this would just go without saying, but when we drift into the realm of "Web 2.0", it's worth being explicit. Here, we're talking about tools to help your group work together and share things, not the entire world. Many of the popular Web 2.0 applications are all about sharing with the entire world: think of photo sharing with Flickr, videos on YouTube, social bookmarking with del.icio.us, or a global encyclopedia like Wikipedia. These are all great tools, but not what we're talking about here. We're talking about your work being shared just within your group, not with everyone and their dog.

It's also worth saying that the work or information that your workgroup is thinking about putting into some kind of Web 2.0 tool is pretty important (at least to them), and probably also important that it stays private. Otherwise, why exactly are you worrying so much about what tool you want to use?

We're also not talking about people with a dedicated and always helpful IT team at their beck and call, that will get them anything they want, help to acquire it and keep everything going smoothly. Though if you have that (especially the "always helpful" part), congratulations. You still might not want to burden them, leaving them free for more complex work that demands their skills. These are tools that if you want to use, you and your team are going to have to figure it out on your own.

What exactly do we mean by Web 2.0 Productivity applications?

Simply, these are applications that clients run using only a web browser, just by going to a particular web site. By "productivity" we just mean we're worrying about tools to help get some kind of work done, like we described above, rather than games or pure social networking. Because these applications run in a network environment and many people use them, they often — but not always — take advantage of this by offering some aspects of collaboration or sharing.

A few examples: wikis, weblogs, group calendars, project and task management, CRM, chat rooms, database-like tools, file sharing, workflow, bug and issue tracking, and audio, video or web conferencing.

Applications running in a web browser have been around for a while, but the "2.0" part is newer. While older web apps were nice because users didn't have to install anything, they were in general more clunky to use. Now, using a bunch of technologies, collectively called "AJAX", that are available in newer web browsers, these applications can be a lot smoother and easier to use than they were before, somewhat closer to the interactivity and usability that people have been used to in desktop applications. This is what has generated the recent flood of interest and excitement.

Why It's Important

This section introduces the idea of where to host, and why this is a crucial decision to consider.

While users access these application with only their web browser, its important to remember that, despite the breathless hype and promises of sticking it to the man, at the end of the day there is a substantial chunk of software involved, and its all running on the server that everyone is pointing their browsers at. Our point here is that where that chunk of software is sitting is something you actually might want to spend some time to think about, before you dive head first into this whole Web 2.0 thing.

To greatly simplify, there are two places that software could sit. The first is on servers run by the software vendor, or some other company that buys the software from that vendor and hosts it for a pile of other people. The sexy buzzword for this is "Software as a Service" (SaaS); you're not really buying the software, you're just paying to use it for a certain period of time from their servers, most often for a monthly fee. Let's call this "vendor-hosted".

The second model is where the software is put on some server (or often, just any old computer, as long as its always on and has a network connection) that you or your workgroup have somewhere. Same deal as before for your users, they still use their web browser and point it a web site, but this time it's a web site under your control, and probably not shared with hundreds or thousands of others. Often this machine is placed inside a company firewall, but it need not be. Rather than a monthly fee, the software is often (again, not always) purchased up front for a larger amount, usually with some annual maintenance fees. We'll call this "self-hosted".

Which way do you choose? Sometimes the choice is made for you. For a couple of consultants whose entire IT infrastructure consists of a couple of hand-me-down laptops and the wireless connection at their local coffee shop, using that Web 2.0 app on the vendor's servers is the only way to go. For the corporate wage-slave with the "assertive" IT policies around his neck (if any data leaves our firewall, you will be drawn and quartered — in triplicate!) a self-hosted solution would be a prudent choice. Most people though, are somewhere in between, and if you're one of them, read on.

How this information can help you

You're thinking about a Web 2.0 productivity application for your workgroup, and could probably go with either a vendor-hosted or self-hosted one. Now what? Keep reading, and you'll get help with these four scenarios.

1. You've luckily found an application that could either be self-hosted, or vendor-hosted — which should you choose?
2. Two similar applications meet your needs, one self-hosted and one-vendor hosted — how exactly should that factor into your decision making process?
3. You're just starting to look for a solution, and want to narrow down your search — would self-hosted or vendor-hosted be the smarter place to start looking?
4. You're developing criterion to evaluate several applications — what are the important trouble-spots with respect to each hosting alternative to pay careful attention to?

Installation and Startup

This section looks at the first issue to consider when making the decision between self-hosted and vendor-hosted, installation and startup.

Installation and startup considers how long it takes from the time you decide to use a web application until its software is up and running, along with what expertise, hardware, software and other resources you need to get it running. Even though this is a one-time cost, and usually paid only by one person for support across the whole organization, it's a very important one. If you're at the stage of evaluating ten different tools, and each one takes two weeks and an army of consultants to get installed, well, you're not off to a great start.

When it comes to self-hosted applications, all generalizations fly out the window. Some applications are in fact very easy to install and get going, requiring no special skills, and can be up and running in minutes. Others, not so much. This is definitely an area where if you're considering self-hosted applications, you need to pay close attention. And needless to say, a vendor's claim of "easy to install" should be taken with a rather large grain of salt.

We'll use our ProjectForum wiki as an example of an application that really does make installation easy (we just told you not to trust vendors, so you may want to try it for yourself). When you download ProjectForum from our website (a fairly small 1-2 MB file) onto the machine you'd like to run it on, you get a single application, no DLL's, configuration files, or anything else. Run that application (e.g. double-click) and it starts up its own built-in webserver. Open your web browser and connect to that webserver, and you're up and running, ready to create your first wiki. It doesn't need to have anything else installed — no web server like Apache or IIS, no database like MySQL, no version control system, no particular system libraries, no editing configuration files, nothing.

On the other side of the coin are applications that have, let's just say, a few more prerequisites. While not pointing fingers, many open source applications suffer from this; some of them actually do a great job here, but in the vast majority of cases, it's almost like the programmer's behind them are demonstrating how amazingly cool their software is by how many other pieces it uses — more is better!

So what kinds of things might be needed before and during the install of an application? Code may need to be compiled. You may need to set up a particular database management system, and perhaps create some initial database tables. You may need other software, such as a version control system, or an entire virtual machine, that the application needs available. You may need to ensure you have a particular scripting language interpreter, and perhaps particular plugins, libraries or extensions that add features to the scripting language. All of which you'll need to find, download and install, if they're not already there, being careful that you get the right versions. And then of course there is the hand editing of application configuration files in your text editor before you can get it running.

The above list isn't at all contrived; you'll find many applications that will require you to do that — if you have the expertise, or are able to lean on expertise from your IT department or elsewhere. Luckily, most applications probably only require a few of the pieces noted above. And increasingly, some operating systems (e.g. Linux, recent versions of Mac OS X) come bundled with many of the prerequisites, although getting the right version may still sometimes be tricky.

Some vendors will instead ship you an "appliance", a preconfigured computer that you plug into your network, set an IP address, and that's all it takes to have their application up and running. It probably speaks to how complex their software is and how many dependencies and prerequisites it has that they need to do it this way rather than just shipping you the software, but purchasing such a dedicated box may well make sense in some situations.

Bottom line: particularly with self-hosted applications, you'll need to be very careful about installation and startup, factoring in the time, expertise and other resources needed, which may be either trivial or quite substantial. With vendor-hosted applications, you're almost guaranteed that this area will go smoothly.

Backups

As with any of your important data, backups need to be managed. If you're self-hosting your application, this is your responsibility and yours alone. If you're running other applications or otherwise holding your group's own data (e.g. on a file server you manage), you're probably already quite familiar with what's involved with doing regular backups. If you have someone else (e.g. your IT guys) doing backups of your data for you already, hopefully they can be encouraged/persuaded to add your application's data to their existing backup routine. You will also of course have to check to see if the application vendor has any specific requirements or procedures that need to be followed when performing backups.

If you're not already doing existing backups of other data, or not able to convince someone else to do it for you, its something you're going to have to figure out on your own. If this seems like a daunting task (which, given the tools available today, it normally shouldn't be) you may need to rethink running a self-hosted application, or at least that particular one.

On the other hand, if you're running a vendor-hosted application, there's a very good chance that the vendor is doing regular backups, and you'll have absolutely nothing to worry about. Right?

Not so fast. You should check the vendor's terms of service to ensure that backups are in fact done, and get the necessary answers about how often they are done, how long they are stored, the procedure you and they will follow if data is lost and needs to be restored from backup, and more. If those all work for you, great.

But even if everything they're doing meets your needs, do you really want to trust your important data to the vendor without doing your own backups as well?

Yes, even if a vendor-hosted application has a solid backup strategy in place that fits your needs, and certainly if it doesn't, you should be doing your own backups if your data is at all important to you. Remember, backups help you both in the case of data being lost because of some sort of system corruption, but also in the case where some of your data is inadvertently deleted by a user in the regular course of using the application. Your vendor may well be prepared for the first case, but are their backups going to be helpful in the second case, when you realize several weeks down the road something has gone missing that needs to be restored?

There are a number of things you need to determine from your vendor, beyond simply how often backups are done and how long they are stored for. Can you download all your data at anytime from the vendor's servers? Can this be automatically done? If data needs to be restored from your own backups (e.g. because of accidental deletion), is there a way that this can be handled? Finally, is the data that you can retrieve from the server helpful to you outside the context of the vendor-hosted application? We'll touch on this more in the next section.

Security

Security is without a doubt a huge area, but here we're mainly concerned with what would happen if your company or workgroup's information was inadvertently made available to people who shouldn't have it, whether a result of a security bug in the application, a hacker attack, network sniffing, deliberate theft, or whatever. How will where your application is located (vendor-hosted or self-hosted) affect this?

This obviously depends on how important your data is to you and the consequences of it getting out. Some things you'd never want under any circumstances to escape your own network (or this may be mandated for whatever reason), in which case a vendor-hosted application is completely out of the question from the start. Normally though, its a balancing act. How well do you trust the vendor? If using a vendor-hosted application, would mandatory SSL use be required, and if so, is it an option? While you can expect a vendor-hosted setup would take certain precautions, its wise to check into their procedures, and if possible do some research into how they've done in the past. A large vendor-hosted site known to contain proprietary information may be a more compelling hacker target than a private site. Is the only access you plan to have from people inside a corporate firewall (or via a secure VPN), or will people need to access the application from a variety of locations? At the same time, for a self-hosted application, you need to consider your own security needs, knowledge, and ability to provide for them.

Managing security can be an extremely complex and difficult task. The more important your data, and the more important it stays private, the more attention you'll need to pay to this area. Where your application (and data) resides is a key piece of your overall security solution.

Availability and Access

Availability and access are two related and important considerations.

Availability

As with any web application, if the server hosting the application isn't available, you can't use the application. This can be as a result of server downtime (planned, unplanned, hacker attack, corruption, etc.) or any of a number of issues between your web browser and the server.

If you're running the application self-hosted inside your own network, there are probably less points of failure than if you're running it outside, or running it vendor-hosted. As you control more of the pieces, you'll certainly have more control of getting things back up and running rather than waiting for the vendor to get things straightened out. On the other hand, its more likely that only you or a small number of people may be able to get things running in your group. If a vendor-hosted application goes down, it's highly likely that they will both be aware of it very quickly, and have the expertise (and hopefully redundant hardware if needed) on hand to address any problems quickly.

As always, you have to determine what the costs of not having the application available for a period of time would be, how likely downtimes are, and how possible downtimes can be managed. For vendor-hosted applications, look for service-level agreements, check out their past history, and see what their policy is for scheduled maintenance (is this something you will know about it ahead of time?). You probably can't influence their scheduled maintenance times (avoiding a particular hotspot where you need the service), but at least you want to know if it will be an issue.

For self-hosted applications, understand the limitations of your own resources and expertise, and know that for times where availability is critical, you can plan to ensure that staff are available who can correct any problems that arise. Unless there is a drastic change in how you're using the application, past experiences can be a fairly strong predictor. A possible area of concern for vendor-hosted applications, particularly those developed and maintained by startup companies, is the growth pains that can come from unpredictable use of their application. Because you're sharing their infrastructure with many others, this can very much affect how available (and responsive) their system is for you.

Access

An obvious consideration when it comes to where you should host is who will need access to the application server, and where they will need access from. Other things being equal, there's little advantage to a vendor-hosted application when access will strictly be from people within your own local network, hidden behind a firewall.

If access from "outside" is desireable, you again have to consider your own needs, resources and expertise. If remote access is needed, but will be used sparingly, and you already have solutions in place for similar circumstances (e.g. VPN to access mail and files), then you may want to use the same mechanisms for the application. If the predominant use of the application will be from people who are widely distributed, you'll need to consider if you already have the expertise and facilities to provide that in a self-hosted environment. A vendor-hosted application will by necessity be designed to operate with people using it from all over the world.

Access is obviously very strongly related to the security issued raised above. If there are particular security needs (e.g. logging all accesses) that a vendor-hosted application does not provide, this may trump the fact that a vendor-hosted solution could provide more robust access for your users.

Software Updates

Like all software, Web 2.0 applications designed to support workgroup productivity will usually be regularly upgraded by the software vendor. How those upgrades affect you will likely be quite different depending on whether you are self-hosted or vendor-hosted.

In a self-hosted environment, you will be responsible for keeping track of software updates from the vendor, deciding when to upgrade the system, installing the upgrade, and so on. Is this a difficult process? As we saw with the installation, upgrades can vary greatly between applications, with some involving just the push of a button, and others a potentially complex and arcane process. Make sure you know which you're dealing with.

In a vendor-hosted environment on the other hand, it's almost universally the case that upgrades are automatically take care of, without any intervention on your part. Bugs will be fixed, features will be added, and the software will be improved, sometimes without you noticing. That the vendor manages this process is a big advantage of vendor-hosted applications.

But is there a downside to these automatic updates? Again, it depends on your usage of the system and how critical it can be. The last thing you need before a big customer demo is to find out the application has jumped to version 2.0 (codename "Lemon Penguin") with the entirely "new and improved" interface, rendering your carefully planned demo script worthless. If not having control of the timing of updates is a serious concern, you'll have to be careful with vendor-hosted applications. On the plus side, though vendor-hosted applications tend to have more updates, they tend to be much more incremental. Still, you may want to find out if the vendor's practice is to give advanced notice of any significant upgrades and when they will occur.

Disruption of Vendor's Business

You've been happily using your Web 2.0 productivity application for months, and your workgroup has come to greatly depend on it. All of a sudden, there's some major disruption in the application vendor's business. Now what?

What do we mean by major disruption? The company may have simply run out of money, and can't afford to keep the lights (or their website) on anymore. They may have been forced for some other reason, such as legal action, to cease operations. The company's investors or management, seeing it not meeting their expectations, may simply decide to cut their losses. If you're using an application from a larger company, where that application is just one part of their entire business, they may for various reasons decide to abandon it and focus their energies elsewhere.

The company may get acquired; remember, for most startups, which are the main vendors of Web 2.0 applications, this is in fact their primary goal and focus, as opposed to old-fashioned notions such as profitability or building a sustainable business. This may be a good news scenario, where the new owner really helps to push things forward. Or, despite the glowing press release, the acquirer may have purchased the vendor to take its product in a different direction, to kill off the application but leverage the underlying technology for another product, to acquire the vendor's staff, or to shut down a competitor.

For self-hosted Web 2.0 productivity applications, this is pretty much the same risk that you have to weigh with any software purchase. In the short-term, your concern is whether or not you can continue using the application. Generally this will be the case, but there may be some applications that "phone home", either for some critical piece of frequently-updated data, or to check licenses. What happens to them if the vendor's server that they're trying to reach isn't there? Over the medium term, is there a specific deadline you'll need to be aware of, after which the application will cease to function? An application sold via subscription may be programmed to automatically "drop dead" if not updated at the end of the subscription term. And longer term, if you need to transition to another solution, will this be possible? If you can get by not taking your data with you (it may be important, but is out of date and replaced quickly) this may be less difficult. Otherwise, you'll need to consider the same issues raised by backups, of getting access to all your data. As well, you'll need to know if you can do anything with the data after you have it, for example whether it is stored in a closed proprietary format, or one that is more open or can at least be converted for use by other tools.

All of these issues equally apply to vendor-hosted applications. The main difference is that you may have significantly less control of the timetable. If the vendor's web site completely shuts down on the spot, you're obviously out of luck then and there. What would the consequences of that be on your group's work? If notice is given that the site will be shut down in for example one month, there's increased pressure to accelerate a transition, that may greatly impact existing projects.

Pricing and more

In this final section, we'll touch on the issue of pricing and more.

Pricing

Pricing will obviously depend a lot on the particular application or applications you are looking at, regardless of how they are hosted, such as how the pricing model works, when payments are made, what rights you have for use of the application, how support is handled, and so on. But there are some particular areas that you'll want to pay particular attention to.

Many vendor-hosted applications will be priced in terms of a "subscription", for example a monthly fee paid for use of the system, sometimes with a one-time setup fee, but no other fees for things like upgrades. Often there are several different "plans" that you can choose from, offering different features of usage limits, and you can often move up or down between different plans. Make sure that you understand the limits each particular plan offers; is it based on registered users, amount of access, number of documents? Pay careful attention to any limits on disk storage and bandwidth. Because these are shared between many users, it's often in the vendor's interest to put a cap on these; ensure that any limits will accommodate your group's needs.

You'll need to understand if there are any termination charges, minimum subscription lengths, conditions under which the vendor can change their pricing or the plans they offer, etc. While most subscription terms for vendor-hosted applications are not nearly as horrific as those for your local cellphone provider, with the relative youth of "software as a service", there can be considerable volatility in terms of business models.

For a self-hosted application, again the pricing model may vary, but most commonly you will purchase the software via one large upfront license payment, with recurring annual payments for future upgrades. Again, knowing how license fees are calculated is important, but restrictions on document storage, bandwidth etc. are less likely to be a factor, since you're the one providing them, not the vendor.

Changing needs

Finally, keep in mind that with respect to all of the above areas, your needs will almost certainly change over time.

Will the application you choose handle these changing needs? Will a vendor-hosted application be able to scale to fit your increased needs, or are there either capacity limits or drastic price increases? What if you find later on that remote access is more important than you thought when you initially went for the self-hosted system?

In an ideal world, the Web 2.0 workgroup productivity application that you choose will be available in a wide variety of configurations, and has the option of being run either self-hosted or vendor-hosted, with the ability to easily migrate between the two. There are a large number of applications that do allow this, and certainly any popular self-hosted application will inspire the creation of third party hosting services. For applications designed from the start to be vendor-hosted, the transition to self-hosted can be much more difficult, and so is less common.

Summary

We've touched on the fact that there are a lot of things to consider when evaluating Web 2.0 applications for your workgroup. Obviously, we've omitted the most important, and that is will the application suit your needs and help you get whatever you need to do accomplished. An ideal hosting environment, matched closely to your security, access and pricing requirements, is useless if the application is rubbish.

Our intent of course has not been to overwhelm you with additional considerations, nor to turn every technology decision into a six month evaluation process. What we do hope is that we've made it clear that there are choices when it comes to self-hosting or vendor-hosting, there are a number of implications of those different choices, and these should be factored into your decision making processes. At the very least, we've provided a range of issues that you may want to consider with respect to your planned use of the application, and highlighted a number of common pitfalls associated with each hosting option.

As should be obvious, there's no universally "right way" to do things, despite any frenzy to the contrary about how "SaaS will render the idea of buying software obsolete" or "web applications can never be as good as desktop applications", or any of the other hyperboles that the computing world regularly pronounces. It's in your own interest to put pressure on the Web 2.0 workgroup productivity application vendors to deliver both self-hosted and vendor-hosted versions of their applications, so that you have the flexibility to choose which suits your own needs best.