Fake Cloud Vendors are on a Catastrophic Course — and their Customers are Riding Shotgun

In outlining the 4 warning signs of fake cloud solutions in my last blog, I left out one key point: The catastrophic course that the fake cloud plots for both the vendors, and their customers.

Over the last 10 years, I’ve seen vendor after vendor, take the eerily similar, ill-advised, three-step path to fake cloud catastrophe – and their customers are ultimately the losers. Once they embark on the path to the fake cloud, these vendors are on a direct path to failure.

So what is the path that every fake cloud vendor (and their customers) almost invariably follows?

Step 1: “Our customers and partners are begging us for a cloud solution!? No biggie, we’ll host it.”

Seeing their traditional businesses in precipitous decline while true cloud providers grow in customer base, revenue, and market share, legacy vendors spin-up an ops team to host the solution. The ops team – typically specialists in hosted software operations – say, “No problem!” Most on-premise vendors are far into this step already.

The company starts spinning-up hosted software instances. Marketing knocks out a subscription-based price list and creates the requisite collateral littered with calming images of fluffy clouds. All done, right? Wrong.

After a few initial sales, the ops team realizes that hosting is much more than a question of hosting infrastructure.

  • “Customer are complaining about performance – how do we tune the actual application anyway? Adding more memory to the server didn’t help.”
  • “We have to individually upgrade hundreds of customer instances? What are the application level considerations for each customer?”
  • “How do we manage SLAs across our 100 instances, and how are we going to do it when we reach 1,000 and beyond? We need to hire 100 more people to keep these plates spinning!”
  • “Customers are asking us to make changes because it’s too difficult to do it themselves?! This wasn’t meant to be a managed services agreement!”
  • “Engineering, you have to help us. We can’t successfully scale this system AND feed each customer instance – do something!”
  • “Hey engineering, those patches and fixes you delivered to customers without worrying about applying them – guess what? We have to do it now – and it sucks.”

The business guys look across at the real-cloud providers and say, “We need to put the pedal to the metal on this cloud thing!” However, operations has already raised the red flag. Costs are outrageously high, customer satisfaction is shockingly low. Something has to change. So…

Step 2: “No problem, we can make our old solution more ‘cloudy’.”

This step is almost inevitable once a vendor has sold the fake cloud. Some bright spark develops a multi-year roadmap to the cloud, which includes a few “optimizations” to make the existing product run more cost effectively, more reliably, and more user-friendly as a service. Salvation!

  • “We’ll make it multi-tenant, so it’s easier for ops to deliver.”
  • “We’ll provide tools to help ops run it more effectively.”
  • “We’ll make the app more intuitive for business users to take the pressure off of our own team.”

It’s just not that easy. No vendor has successfully turned an on-premise application into a real, multi-tenant, self-service cloud app, and scaled up to thousands of customers. Old applications are innately complex because they’re running on several code bases – Java, C++, client server, N-tier – each of which is decades old and never meant to run in a multi-tenant environment.

This is the point at which the vendor starts their great “cloud experiment”; trying to service the airplane while it’s in flight and their customers are on-board.

Can you really blame the engineering team; a group of on-premise software developers trying to build a cloud solution for the first time? Turning their solution into a self-service, cloud application requires multiple UI’s just to hide the complexity, but those UI’s create more complexity on their own.

Throughout this process, innovation comes to a grinding halt. Adding features that customers really want takes a backseat to getting the Frankenstein-like “cloud” solution off the ground. Overall complexity increases, while customer satisfaction decreases around a solution littered with patches, fixes, and bolt-ons.

Finally, the number of customers that the vendor is supporting rises to precipitous levels. Step 2 isn’t working out. Customers are asking for free-trials like the real-cloud vendors offer. They’re looking for real features that solve their problems, not endless cloud fixes and kludges. So it’s on to step 3.

Step 3: “Hmm, this didn’t pan out. We need to build a new solution from the ground up.”

Just when you thought it couldn’t get any uglier, the vendor reaches the inevitable dead end 2-3 years after first launching the fake cloud solution. Business leaders are panicking, realizing they’ve performed a failed surgery on their antiquated application. Their product is a monster of complexity, and it’s practically impossible to support on-premise and hosted customers while delivering a reliable, cost-effective, self-service solution. Customer satisfaction continues declining, and it has become clear that the future is 100% cloud.

It’s time for Project Re-do: Build a brand new, cloud-based solution.

This is going to take at least another 2-3 years to complete. Additionally, the vendor can’t simply retire the old solution because there are hundreds of customers using it and still paying maintenance fees. Those customers won’t see any new features while the vendor dedicates all resources to creating a new cloud-based solution, at which point they’ll have to re-implement that new cloud app.

No innovation + re-implementation + a fledgling cloud app = No fun for years to come.

Then the pain for the vendor really begins. They have two solutions – a highly functional and mature old app – runs great on-premise and badly in the cloud. And a brand new app that runs better in the cloud, but with far less functionality.

In the meantime, true cloud vendors – using one code-base and years of SaaS experience – continue to build a worldwide customer base. They’ve steadily innovated and improved their solutions, adding new features that meet customers’ needs. By the time legacy vendors are ready to launch a cloud app, it’s too late to get in the game. And that’s why, one legacy vendors embark on the fake cloud, they are destined to crash. There’s only one question left to answer: Will you join them on that ride?

Guenther Kreuzpaintner

Infrastructure Operations Excellence

6y

I am enthusiastic for Cloud however running thousands of systems in colocation or on premise CAN be done in a professional manner.

Ricardo Casanovas

Entrepreneur. Tech Investor. Interested in Cloud and B2B SaaS software.

6y

Great article! A must read also for SAP Business Suite traditional customers running on-premise or with a managed service provider and looking to add real cloud features to their SAP Systems. The article describes a very familiar story as the one SAP customers are being exposed.

Ahmed Azmi

IT Advisor at Brightwork Research

6y

Paul, it's all come true. Some decommissioned their hosting facilities and partnered with AWS, Google, and MSFT. Others abandoned hosting altogether by way of "private cloud" where customers buy, host, and manage their own infrastructure (on-premise with a cloud logo). The rest either shut down or sold (Verizon, HP, Cisco, Rackspace, and VMware).

Russell Stuart

Optimising the Data to Value Chain & Digital Transformation

8y

Agreed David Merchant - but don't worry I won't ask you to name them!

Like
Reply
David Merchant

Travelling and observing life

8y

So true, and we are seeing many of the "big" vendors in the BI and analytics space taking just the approach described above. I can think of several that are clearly in Step 2.

Like
Reply

To view or add a comment, sign in

Insights from the community

Explore topics