By David Smith
Myths continue to plague cloud computing. These misconceptions can slow enterprises down, impede innovation and stoke fear. Although cloud computing has become much more mainstream in the last five years, some of the myths that circulated during its advent still persist today. New myths have entered as well.
Cloud computing is about capabilities delivered as a service, with a clear boundary between the service provider and the consumer. Cloud should be thought of as a means to an end. The end must be specified first
For most people, this creates a scenario where ‘in the cloud’ means ‘where the magic happens.’ It should be no surprise that such an environment is rife with myths and misunderstandings.
Here are some of the most dangerous and misleading myths that CIOs should be aware of about cloud computing.
No. 1: Cloud is always about money
The prevalent myth about the cloud is that it always saves money. This is sometimes the case, but there are many other reasons for migrating to the cloud, the most common of which is for agility.
All business decisions, including those about cloud, are ultimately about money. Even if agility is the ultimate goal, cost is still a concern. Don’t assume you will save money unless you have done the hard work of honestly analyzing your situation.
Utilize total cost of ownership and other models on a case-by-case basis. Segment cloud into use cases. Look beyond cost issues. It is important to ensure that the business does not have unrealistic cost saving expectations that aren’t delivered upon.
No. 2: You have to be cloud to be good
Are you “cloud-washing?” Cloud-washing, or the tendency to call things cloud that are not, may be accidental and a result of legitimate confusion. But IT organizations and vendors call many things cloud as part of their efforts to gain funding, make sales, and meet ill-defined cloud demands and strategies. This results in the myth that an IT product or service must be cloud to be good.
No. 3: Cloud should be used for everything
Cloud is a great fit for some use cases, such as highly variable or unpredictable workloads or for where self-service provisioning is key. However, not all applications and workloads are a fit for cloud. For example, unless clear cost savings can be realized, moving a legacy application is generally not a good use case.
The cloud may not benefit all workloads equally. Don’t be afraid to propose noncloud solutions when appropriate.
No. 4: “The CEO said so” is a cloud strategy
“The CIO,” “the board” or some other elusive source can take the place of the CEO in this myth. Many companies still don’t have a cloud strategy. That cloud strategy needs to be based on sound business goals and realistic expectations.
A cloud strategy should be more than a mandate — it should identify business goals and map potential benefits of the cloud back to them. Cloud should be thought of as a means to an end. The end must be specified first.
Read more: 6 Steps for Planning a Cloud Strategy
No. 5: We need one cloud strategy or vendor
Even with more interest in multicloud today, many businesses still desire simplicity. However, cloud computing is just not one thing, and a cloud strategy has to be based on this reality. Cloud services are broad and span multiple levels, models, scope and applications.
A cloud strategy must be able to accommodate the use of more and more cloud services. The organization needs to realize that it will be relatively impossible to get everything from one vendor. A single cloud strategy makes sense only if it uses a decision framework that allows for and expects multiple answers.
No. 6: Cloud is always more secure than on-premises capabilities
In the past, cloud computing was perceived as less secure than on-premises capabilities. However, there have been very few security breaches in the public cloud, and most breaches continue to involve misconfiguration of the cloud service. Today, the majority of cloud providers invest significantly in security, realizing that their business would be at risk without doing so.
Yet this doesn’t mean that security is guaranteed in the cloud. Cloud security is a shared responsibility between the provider and the consumer. CIOs should not assume that cloud providers are not secure, but should also not assume that they are. As security levels of cloud providers vary, assess your actual capabilities and your potential provider’s capabilities and hold both to reasonable standards.
Read more: Is the Cloud Secure?
No. 7: Multicloud will prevent lock-in
Most organizations typically start with one cloud provider, but eventually become concerned about being too dependent on the one vendor and start entertaining the use of another. This is known as multicloud. Multicloud can also take a functionality-based approach. For example, an organization may use Amazon Web Services as its primary cloud infrastructure provider, but decide to use Google for analytics and big data.
IT leaders should not assume that just having multicloud as part of the cloud strategy addresses all issues around lock-in. If lock-in is identified as a potential issue, then it warrants a more focused effort on addressing real solutions.
No. 8: Once I have moved to the cloud I am done
There are many different paths to the cloud, ranging from simple rehosting (or “lift and shift”), typically via infrastructure as a service, to a complete changeover to an application implemented by a software as a service (SaaS) provider. Cloud is as much an operating model as it is a technology. Organizations that find success with cloud adapt their operating process to fully leverage cloud principles.
To take advantage of cloud capabilities, it is essential to understand the model and have realistic expectations. You can’t just move things to the cloud and expect that you’re done.
Once a workload has been moved, the work is, in many ways, just beginning.
Further refactoring or rewriting will be needed to take advantage of the cloud. Ongoing cost and performance management will also be key for success. Make sure to include post-migration activities as part of the cloud implementation plan.
No. 9: Enterprises are moving back from public cloud
The idea that workloads are being repatriated from the cloud is primarily wishful thinking on the part of legacy vendors who would benefit from this myth being true. The reality is that most enterprises have not moved cloud workloads back. Of those that have moved, most are not coming from cloud infrastructure as a service (IaaS), but rather from SaaS, colocation and outsourcers.
That is not to say every cloud migration is successful. However, organizations are more likely to address problems as they arise rather than abandon their cloud strategy and move applications back to their original location.
No. 10: We have a cloud implementation/adoption/migration strategy
There are three levels to strategizing. The first is a long-term business strategy, which comes from the CEO or the board of directors and is intended for everyone to understand the organization’s mission.
The next level is strategic plans. They’re more midterm, and there can be many of them. Cloud strategy fits here. Lastly, there are operating plans. In the cloud world, this is a cloud adoption plan, a cloud implementation plan or a cloud migration plan. These plans are often mistakenly referred to as the cloud strategy.
A plan to shut down the data center is not a cloud strategy
The cloud strategy should be the foundation for the implementation plans. Stating “we’re all in” is not a strategy. Likewise, a plan to shut down the data center is not a cloud strategy. The cloud strategy needs to be comprehensive, explicitly stated and separate from implementation plans.
As CIOs and other IT leaders plan for their cloud usage in 2020, having a strong understanding of what’s myth and what’s reality will help form realistic expectations around cloud computing.
Debunking these myths will be critical for organizations to successfully take advantage of the many benefits that cloud can offer.
(The author is Distinguished VP Analyst and Gartner Fellow Emeritus and the views expressed here need not be in sync with those of the publication)