Tag: vendor hosting

Vendor Hosting, SaaS, Cloud Computing: What’s the difference?

When talking with non-IT people, it’s amazing (ok, not really) how much confusion there is about concepts and what these terms mean. While the terms are related, they are far from interchangeable. People soemtimes like to throw around “buzzwords” in order to sound like they’re knowlegable or on the cutting edge. If you deal with this stuff, it’s good to understand the differences.

Vendor Hosted

Vendor hosting is a relationship. Vendor == someone you’re paying to do something for you. Hosting == the something you’re paying them to do. You don’t own the hardware, they do.

This can be wonderful if you won’t want the expense and complexity of deploying and maintaining the hardware, and if the vendor is good at doing those things.

But it can suck if your vendor doesn’t provide good service, or shuts down suddenly, leaving you with no access to your data.

Software as a Service

SaaS is a business model. With software as a service, you’re paying like you pay for a utility, based on your usage, or subscription, based on time. Like utilities, if you stop paying, you can’t use it anymore.

Contrast SaaS with Free software and licensed software models.

Free software is, well, free. Often the software itself is free (cost), but you pay for support or for customization, or by devoting resources to maintaining the codebase.

Licenses are typically perpetual, but limited to a major release version and its patches. When the next major release comes out, you have to pay for the upgrade. Usually the vendor compels their customers to upgrade by dropping support for the old version, offering discounts on upgrades for existing licensees, and so on.

Unlike the licensed software model, with SaaS you’re usually entitled to the latest version, not paying for upgrades. Often, but not necessarily limited to, vendor hosted solutions.

This can be wonderful if:

  • You hate managing licenses.
  • The upgrade treadmill gets you down.
  • You’re cool with fixed costs and realize you can either pay the vendor once a year for the next version or the same amount of money over the course of a year for the SaaS model.
  • You don’t use an expensive solution very much, but would be in the market for a solution you can spend a small amount on for what you do need. Like, you’re not going to spend $25000 for CAD software, but if I could pay $25 to use it for a few hours, you’d be able to design that thing you want to build for your hobby.

But it can suck if you want to pay for something once and own it, or if the SaaS vendor goes out of business or decides to stop providing the service, or if for some reason you prefer to remain on a certain version of a product that meets your needs well enough, such that you have no compelling need to upgrade, or if the SaaS vendor’s upgrades take the product in a direction that doesn’t suit your needs.

Cloud computing

Cloud Computing is an architecture. A distributed cluster of redundant, co-located, and load balanced hardware, typically spanning multiple datacenters, which is used to run virtual machines which are not dedicated to specific hardware. The amorphous nature which decouples virtual machines from any specific node in the cluster is what gives rise to the term “cloud” computing.

“The cloud” may often be used as a generic term for “the internet” because on networking diagrams, the internet is symbolized that way, because the specific architecture of the internet is unknown and not really of concern to you. But just because something is on the internet does not mean it is “cloud computing”.

The cloud computing cluster’s capacity is typically shared among many customers. Due to the nature of the cluster, it is possible to scale a customer’s utilization of the cloud very rapidly, growing a virtual machine from a single node on the cluster to several or many. Conversely, the cloud may idle portions of the cluster when demand is low, resulting in great efficiency and flexibility. If a node in the cluster goes offline or experiences hardware failure, the cloud continues chugging along and only the admins will even notice that anything happened.

Cloud computing is also typically vendor hosted, since it requires specialized professionals to set up and maintain the cluster. Very few entities are in need of owning their own cloud, and will buy cloud computing in the SaaS model from a vendor who hosts it. You can pay for a tiny portion of the cloud, and as you grow you can expand your footprint on the cloud, paying more for it but generally not having to deal with many of the usual headache associated with scaling up a rapidly growing enterprise.

This can be wonderful if you can live with not owning your hardware and are comfortable with the idea that your data and processing could be “anywhere” in the cloud, co-mingling with other virtualized instances running on the same node(s) in the cluster.

But it can suck if your vendor decides they don’t need you or gets a request for your data from the government and just rolls over and complies with the request, rather than fighting it like *your* legal team would.

Bottom line

Any time you put your data or services in the hands of someone else, you really are putting a tremendous amount of trust in them. You need to consider not just the benefits of the relationship, but the risks as well.

Outsourcing is attractive because it’s expensive and difficult to do well, and if it’s not the core competency of your business to do enterprise IT, it may make sense to have someone else do it who has that expertise. But you need to make sure that your vendor actually does have that expertise!

The pre-sales people will promise you the moon, but you need to be able to verify that they can back those promises up. One of the great selling points is that you don’t have to worry about all the complexity of maintaining IT infrastructure anymore. But it’s not like that responsibility disappears into nothing — it’s the vendor’s responsibility, and you now need to worry if they’re doing it right. If you’re paying someone else to do it right because you don’t know how to do it right, and you’re trusting them to do it better, or cheaper, than you could, how do you do so with confidence that they’re really that good?

Usually, outsourcing puts up organizational boundaries which can be barriers to transparency — you can audit internal processes much more readily than external ones. But are you any better at auditing IT than you are at running IT? Probably not. There may be third party auditors who you can outsource to… but how do establish that you can trust them? 

So how do you establish trust? This is something you need to figure out before you move into a vendor hosted solution. One approach is to move gradually. Do a pilot project and see how it works over a period of time before jumping in with both feet. Plan for moving off of the vendor’s services so you can do so with short notice if need be. Utilize redundant vendors if that’s feasible, so all of your eggs aren’t in one basket.

Work at establishing trust continuously — trust is not a “set it and forget it” kind of thing. Trust comes from a relationship based on iterative transactions. It is built with each interaction that you have. Despite sales pitches, outsourcing does not mean that you don’t have to worry about things anymore. It means you need to establish a management relationship with people outside of your organization who are assuming responsibilities and risks which still affect you. It pays to maintain a close relationship with them.

If you’re not engaged with your vendors and don’t have good rapport with them, then chances are very good they’re going to ignore you, take you for granted, and fail to understand what your needs are, and when it comes time to deal with problems, you won’t be familiar with each other. Communicating effectively and working together will be a second-order problem that prevents you from fixing the original problem.

Don’t be lulled into a false sense of security, and don’t make the mistake that because something is the vendor’s responsibility, that you don’t have to worry about it. It’s still your enterprise that’s at risk. When everything’s running smoothly, it’s great, but problems may actually become more complicated, due to the vendor relationship and the fact that you don’t have direct access and full control over the systems they are managing for you.

Risk management is incomplete without an answer to the question, if the vendor goes away tomorrow, what do you do? If maintaining control over your data is critical, it’s a good idea to require that you have a local copy stored on hardware that you own. At the very least, the vendor should make it easy for you to export your data, ideally to a documented format which will be useful for you in the event you need to switch vendors.