Despite the public cloud’s popularity across all industries, there is a recent phenomenon of organizations moving their mission-critical workloads and applications back from public clouds to in-house or private cloud deployments.
A recent survey from Enterprise Strategy Group found that more than half of the respondents had already pulled something back from the cloud, and 68 percent said their applications are still supported by on premises storage. IDG and Datalink also found that nearly 40 percent of organizations with public cloud experience have made the reverse leap, migrating applications from the cloud back to the data center.
So, what’s spurring this movement away from the cloud, and what will the next generation of applications look like if not cloud-based?
The Move to Cloud
The initial move to public cloud was all about perceived cost savings and business agility. It can partially be attributed to the immense complexity of modern day data centers. With hundreds of applications running on hundreds of servers, and scores of management and monitoring tools, it’s no surprise that many organizations came to the conclusion that they could minimize complexity, costs and risk by outsourcing their business applications to public cloud providers.
Cloud providers touted the lower IT costs of moving to the cloud, as well as increased agility, enabling them to rapidly react to business changes. “Cloud first” became the mantra for mid- to large-sized companies, and while some struggled in the beginning to make the transition, ultimately, they were successful in migrating many of their apps to the cloud.
Taking A Step Back
When Dropbox famously pulled back from Amazon in mid-2016, it made sense because the hyperscale company had the internal resources needed to integrate cloud capabilities into its own operations. But most companies with limited internal resources don’t have the ability to “DIY” for their own cloud environments; so why are we seeing smaller, non-hyperscale organizations also “unclouding” and bringing their applications back in-house?
Security and the regulatory environment are clearly factors, but most companies cite surprisingly higher costs of ongoing deployment and maintenance and the inability to get a guaranteed performance service level agreement (SLA). After being deployed in the public cloud for a year or two, IT leaders began conducting detailed cost and performance analysis and comparisons between their public cloud workloads and those they kept on premises.
As more organizations began to see that their cloud deployments were costing them the same or, in many cases, even more than their on premises environments, combined with unpredictable response times, the justification for public cloud deployments switched from focusing on cost savings to highlighting the business agility message.
Other companies cite the many public outages as the primary reason behind their “cloud break-ups.” As several high visibility outages hit the leading cloud providers, businesses felt the impact and began to think twice about putting business-critical apps in the public cloud. Performance issues also arose, as it became clear that most cloud providers could deliver on SLA guarantees when it came to availability, but were not able to offer user response time SLAs. Even within the same cloud provider, response times varied significantly depending upon where you were geographically.
Others note inflated expectations and industry pressure as factors that led them into the cloud too early in the first place. Those who moved all of their company’s IT assets to the cloud before they were ready soon found themselves overwhelmed and underprepared for the kind of support the public cloud demanded.
These notable public cloud outages coupled with the need to be “cloud first” left IT leaders feeling conflicted. They wanted to maintain control over their applications and ensure their security, but didn’t want to be labeled as laggards when it came to cloud adoption.
Business leaders are becoming more selective when deciding which applications they want deployed in the cloud, and which they want to keep on premises. Business-critical applications that require heightened performance, tighter security, and better cost control are prime candidates to “un-cloud” and bring back to the data center. Having a comprehensive monitoring platform deployed to measure real-time performance, health, and utilization of the on premises infrastructure can help enable application owners to control costs, assure performance, and respond more rapidly to changing business conditions.
While some organizations feel burnt by their previous cloud experience and have pulled back fully, most still see its value and continue to incorporate it into their application strategies. The public cloud is simply evolving into one of the many deployment options for business-savvy IT organizations.
Because of this, we’re seeing a new generation of companies that are taking a hybrid approach to their application deployments. Applications where the business-critical back-end systems are kept on premises, and work cooperatively with front-end (user-facing) public cloud deployments are becoming more popular. Such applications encompass the benefits of both public cloud and on premises infrastructure.
Some may see the “un-clouding” phenomenon as being detrimental to cloud providers and their customers, but the truth is that the cloud isn’t an end-all solution for application deployments. Organizations who are new to the cloud need to take into consideration what the workload placement requirements are for all of the key application workloads when it comes to performance, availability, scalability, security, and cost. A “best of both worlds” approach proves the value of having a cloud environment available for applications that require guaranteed availability and flexibility; as well as an on-premises infrastructure with real-time application-centric monitoring capabilities that ensures performance and security.
The cloud is no longer an “all or nothing” solution, so business leaders shouldn’t make their deployment decisions as if it were.