As Halloween fast approaches, the Silk team decided to give a spin to our usual weekly post by sharing a scary story about cloud data infrastructure gone wrong. Grab some candy corn and buckle up… because this is going to be a spooky ride!


Not so long ago, at a company just like yours, there was a DBA named John. John was a firm believer that the company’s mission-critical applications should be stored in an on-prem datacenter. He liked knowing that he had complete control over the apps. But John’s new boss had a strict “cloud first” policy, forcing John to evaluate various public cloud vendors.

After multiple POCs, John finally chose a well-known cloud vendor to host the company’s mission-critical apps. At first, they seemed like a good choice. They had great customer references and seemed to meet all of John’s stringent requirements. Everything seemed to be going well…

But then, on a cold, rainy night, John’s phone rang.

It was his colleague, Michelle. “John, I just got a call from one of our biggest customers. They tried to log onto the system but said they got an error message.” Michelle sounded stressed. “John, this customer is up for renewal of their contract. If we don’t get them their data soon, this could be a major problem!”

John tried to reassure Michelle that everything would be fine, but he was already feeling cold sweat break out on his forehead. He quickly tried to log onto the system but also got an error message. He quickly logged a case with the cloud vendor and waited for a response…

And waited…

And waited…

After what felt like hours, the vendor finally reached back out to John. They explained that they had had an outage but that the system was back to running as normal. John was furious but decided to give the vendor the benefit of the doubt. Surely this was a one-time issue.

Unfortunately for John, this was only just the beginning.

Days later, more customer complaints starting rolling in. In addition to frequent outages, customers were noticing lagging performance on the system. To remedy the situation, John tried scaling up the solution to kickstart performance.

This move might have quieted the concern of customers but turned out to be a major financial misstep. The budget that had been set to build and maintain the cloud infrastructure was very small. By scaling up, John had managed to completely blow through that budget, and then some.

By this point, John was seriously dissatisfied with the cloud vendor. He started doing research on other cloud vendors, believing that he had made the wrong choice. After careful evaluation, John thought he had found the perfect replacement vendor: they had infrequent outages; they had consistently fast performance; and their transparent pricing meant that John would be able to ensure they never went over budget. Finally, John felt that he had escaped the clutches of that terrible cloud vendor.

But there would be no escape!

Because John had configured the application for the vendor’s platform, he found that he would have to reconfigure the application again in order to move it to another vendor. John’s boss was so frustrated by the whole situation, he told John to forget about migrating to a new vendor and to just make do with the vendor they have.

To this day, the company is a (mildly dissatisfied) customer of the cloud vendor. Meanwhile, John retired and moved to Florida where he doesn’t have to worry about cloud vendors at all. But employees claim that his ghost haunts the halls of the company’s now defunct on-prem datacenter. They say they hear him crying out in frustration – lamenting the fact that he ever moved the company’s mission-critical applications to the public cloud.


Today’s story might be a worst-case scenario into what happens when enterprises move their mission-critical apps to the cloud. But the process doesn’t need to be that scary at all! If you’re a regular reader of our blog, keep an eye out in November for posts on how to make migrating to – and between – cloud platforms as smooth and painless as possible.