Clearing the Air Around Cloud Computing

The term “cloud computing” was first used in 1996 in the offices of Compaq. They were plotting out a revenue model that would generate $2 billion a year in hardware sales to Internet providers.

Fast forward a decade to 2006, when Google CEO Eric Schmidt used the term to describe “a new model … It starts with the premise that services and architecture should be on servers.” It didn’t take long for the big players (Amazon, Microsoft, etc.) to begin using the term.

Today, it’s believed corporate IT people started using the term because it was a simple way to explain these new services that ran outside of the corporate network. As we built the software-as-a-service (SaaS) businesses in the late 90s and early 2000s, we also built the spinoffs: infrastructure-as-a-service, platforms-as-a-service, databases-as-a-service, etc. Still, a lot of confusion grew around what these were, where they ran, and how they integrated into a business infrastructure. Calling something “cloud” was an easy way to explain new proposals to management. Conversations often would go like this: “Is this a custom app from one of our vendors?” “No it’s a cloud application.”

Traditionally, cloud computing is broken into three categories:

• Software-as-a-service (SaaS), such as SuccessFactors, Concur, and Zendesk
• Infrastructure-as-a-service (IaaS), such as IBM’s SoftLayer, Amazon Web Services, MS Azure, and Rackspace Open Cloud
• Platform-as-a-service (PaaS), such as IBM’s Bluemix, Force.com, and Google App Engine.

What do they have in common? Multi-tenancy. SaaS vendors run a single binary delivered on a common shared infrastructure. IaaS vendors typically provide a virtual instance(s) that customers can use to offload compute requirements, and PaaS vendors provide the tools and infrastructure on which customers could develop their own solutions.

Cloud Washing

What about companies that give you a version of their software and run it in their own data center on your behalf? That is what’s always been called “hosted.” Once the term “cloud” became popular, it didn’t take long for legacy software vendors to jump on the bandwagon. They simply pointed to the fluffy white shapes that sat at the edge of any corporate network diagram and said, “See, we are here, in the cloud.” It was their way of trying to remain relevant in a fast-developing world of upstart companies that continued to rapidly unseat entrenched vendors.

In the end, they did get their own term: cloud washing. This term was used to describe companies that were taking old products and jumping on the cloud bandwagon, repackaging legacy software to be accessed over the Internet.

What About Hybrid Cloud?

“Hybrid cloud” is a term that most approach backwards. I hear software vendors say, “You need to have the benefits of cloud without the cloud,” and “Customers should get the cloud on-premise.” That’s like saying you should get the benefits of travel without leaving your house! A hybrid approach to cloud makes sense for any enterprise, as not everything needs to be cloud and not everything needs to be on-premise.

3 Requirements for True Cloud

So where I’m going with all this? Clarity. Until we sort out the snake oil from the beneficial, we are going to continue to see unsatisfied customers due to mismatched expectations or, worse, we are going to see data breaches as software vendors hack legacy applications and try to sell them as cloud apps. So how do we get to clarity? First let’s set some ground rules.

Multi-tenant environments must have the following:

• Multiple “tenants” who use the same application/set of applications
• A shared architecture across all tenants
• Distinct separation between the instances run for each tenant.

True cloud software benefits from multi-tenancy in the areas of change management, insights, and economies of scale. By building a single installation and sharing the infrastructure (web, app, database, etc.), it lowers the cost for everyone. In a multi-tenant environment, customers benefit from insights learned by the vendor through its diverse customer base. Finally, a single delivery versus hundreds or thousands of individual installations is a simpler and easier-to-manage environment. Patching a single binary is faster and less prone to change-management issues than attempting to patch different versions of your software running on thousands of virtual machines in your data center and ensuring your on-premise versions also are patched.

Twenty years ago, a handful of software vendors owned the market for enterprise software. True cloud software is multi-tenant in order to provide economies of scale and, to do so, it must run on a single binary. Running a single binary means that all customers get the same software. This doesn’t mean the software does only one thing; it means that the entire environment is built to run one codebase. Cloud vendors that take their legacy software and run it in multiple virtual machines are not delivering cloud applications. They are hosted applications cloud washing their services. The sneaky term that has been coming up is “multi-tenanted.” This is yet another way to cloud wash hosted offerings.

Be the Best at What You Do, in the Cloud or Outside of It

I am not saying there is anything wrong with hosted or on-premise software. Just don’t try to pass them off as something they are not. If you have built an environment that hosts hundreds of virtual machines that each have a copy of your software, then be up front about it. Don’t call it “multi-tenanted” to make it sound like multi-tenant software. It’s hosted software, plain and simple. If something runs on a customer network, it’s on-premise. Period.

If you negotiated a hosted contract with a hosting provider, you should know exactly what you are getting. Dedicated hardware, software, support, and SLAs. If you need to add more capacity, the vendor will give you a Statement of Work (SoW), and you either pay it or find another way to do what you want. That SoW would include hardware costs, installation, maintenance, licensing, and support. Or you can control the patching and happily run on an antiquated version until it can’t be supported anymore. And you accept all the risks that go with that.

If you negotiate a contract with a cloud vendor, you are going to be in a common, multi-tenant environment in which patches and upgrades happen on a regularly scheduled basis. If the code is written well, you won’t have to accept new features and functions until you are ready, but all the fixes and security patches will be applied, regardless. Because it runs on a single binary, the entire DevOpsSec group is focused on a single codebase, and all the customers benefit from the features and fixes to that one codebase. You are able to scale exactly as you need – not based on how the vendor packages licenses or sells appliances.

If you choose to buy software and hardware and have your IT department install and run it, you, again, know exactly what you are getting and have all the control, as well as all the risk and costs.

Each of these is a viable solution, and mixing them is a “hybrid approach.” Let’s not allow vendors to take legacy-style software, install it in their data centers, and try to claim true multi-tenant cloud software.

As software vendors, we need to be accountable, up front, and honest with our customers, especially in the cloud world, where we share responsibilities and liabilities. Trying to be something you are not isn’t a path to success. It doesn’t matter what is trending or hip: Be the best at what you do, and you’ll find a place in world. I never thought I would be giving software companies the same advice I give my 14-year-old son, but there you go!