Myths About Migrating to the Cloud
Myth 1: Cloud Bursting
One of the original highly publicized use-cases for public cloud was bursting. The story made sense: as your demand for compute
increased, you would use the public cloud to increase the capacity of your private infrastructure. Like so many good stories, bursting didn’t really happen. In fact, bursting is one of the least common public cloud use cases.
Why did bursting not become more widespread? Enterprises are either keeping applications on-premises in newly designed IaaS private clouds or they are moving them to the public cloud. It’s an OR function, not an AND one. Furthermore, it almost always happens per-application. You evaluate your future application needs and decide where it makes more sense to run the application for those needs. Bursting across environments is just too complex.
Myth 2: Multi-Cloud
Most enterprises have neither a comprehensive hybrid cloud nor an end-to-end multi-cloud strategy that covers entire IT 
environments. Frequently there is a general desire for multi-cloud strategy to minimize the dependency on a single cloud provider. But that strategy turns out again to be a per-application choice rather than a centralized plan.
Organizations choose to run some applications in the private cloud and some in different public clouds. Every cloud has very different functionality, interfaces, and cost optimizations. And each time an application developer chooses an environment, it’s because that cloud was the optimal choice for that application. As a result, application mobility becomes a myth; it’s something desired, but very few are willing to settle for the smallest common denominator between different choices just to enable application mobility.
Even if customers wanted to and could move the application, it’s unlikely to happen. Moving large amounts of data between environments is challenging, inefficient, and costly. So, once the choice of a cloud provider is made, the application stays where it is, at least until the next tech refresh cycle when per-application considerations can be re-evaluated.
Cloud Adoption for Legacy Applications
While so much of the focus has been on creating new applications, enterprises are also migrating traditional workloads. So what are the stages of cloud adoption?
- Step 1: Infrastructure as a Service. Treat the cloud like a typical infrastructure; in other words, think of servers and storage as you currently think of them. Applications are installed on top of the infrastructure. Because everything is relatively generic, the choice of a cloud provider is not too critical.
But as applications start to move, a new way of thinking evolves; you start looking at the infrastructure as services instead of servers. - Step 2: Software as a Service. Some legacy applications are swapped for new ones that run as a service. In this case, you don’t care where your SaaS service runs as long as it’s reliable. The choice of a cloud provider is even less relevant; it’s about choice of the SaaS solution itself.
- Step 3: Rewrite the Application. Some applications are redesigned to be cloud-native. In some cases, the cloud is an excuse to rewrite decades of old COBOL code that nobody understands. In other cases, features of the cloud enable an application to scale more, run faster, and deliver better services. Not all applications should be rewritten.
The Core Issue: Data. When thinking about moving the applications, what’s left is the actual data, and that is where company value truly resides. Some data moves with applications where it resides, but not all data is application structured. And that is the last challenge of cloud adoption—looking how data services can enable global, timely, and secure access to all data, whether it resides inside an application or outside of it.
The Role of IT
Just what is the role of the central IT organization, and is there a single strategy for IT? Not really.
The word “strategy” comes not from having a single plan that covers all applications, but from a comprehensive evaluation that should be done before choices are made and from having a unified set of services that ensure security, availability, and reliability of all those different environments.
Consider how IT organizations are evolving to become service brokers. For example, sometimes:
- It makes sense to build a private cloud based on new converged (or hyper-converged) infrastructure.
- It may go with the software-defined data center (SDDC), but that is more the case of when they have to deal with unknown external consumers instead of explicit requirements
- IT organizations will broker services from public cloud providers such as AWS, Azure, GCE, or VirtuStreamThe alternative is so-called “shadow IT” where each application team attempts to manage their own applications without understanding the global impacts of their choices. In such scenarios, security is typically first to go and data protection follows closely.
I’ve written before how with move to public cloud, the responsibility of infrastructure availability shifts to the cloud provider. But that does not negate the need for a comprehensive data protection strategy.
You still need to protect your data on-premises or in the cloud from external threats such as ransomware or internally caused data corruption events (as the application is frequently the cause of corruption, not just infrastructure failures), or from the common (and sometimes embarrassing) “threat” of “I deleted the wrong data and I need it back.”
Companies weigh the costs and benefits of any investment. There are places where different types of infrastructure deliver the right answer. For IT to remain relevant, it needs to support different types of environments. IT’s future is in delivering better on-premises services, becoming a service broker, and ensuring that data is securely stored and protected.
Conclusion
The cloud is real and it is part of every IT team’s life. IT can be instrumental in the successful adoption of the cloud, as long as they approach it with calmness and reason—and an open mind. The goal isn’t to design the world’s greatest hybrid cloud architecture. It’s about choice and designing for application services instead of looking at servers and storage separately from the applications. There will be well-designed private clouds and public clouds that are better fits for specific applications. But the applications will dictate what works best for them; they will not accept a least-common denominator hybrid cloud.
In the end, hybrid cloud is not a goal in itself; it is a result of a well-executed strategy for applications and data.