Your clouds don't need to clash

Cloud risk

Increasingly, two models for cloud are emerging -- the public or shared cloud and private cloud. While the definitions of these models might still be fluid, that has not stopped the rise of loud, passionate defenders of each who are willing to fight to the death to defend the idea that their cloud model will ultimately reign supreme. Needless to say, this "clash of clouds" can be intimidating for many enterprise IT professionals seeking to develop a cloud strategy where it might seem the wrong choice could result in the end of their business (or at least their careers).



Despite all the sound and fury, this clash of clouds obscures a larger, more important point. The basic model of the cloud -- delivering IT as a service -- is here to stay. However, one should not look at the cloud as a destination, but as an ongoing journey focused on business results through ease of use, self-service, scalability and agility. It rightfully shifts IT’s focus to applications rather than the underlying infrastructure.

Therefore, as you take your enterprise on a journey to the cloud, how should you evaluate the competing cloud models? Which should you choose? The thing is, the right answer is that you should choose both. Despite what advocates of each might say, there are unique benefits -- and drawbacks -- to both cloud models.

As a result, you should plan on building an on-premise or hosted private cloud infrastructure as well as setting up your organization to use public cloud services. It is important to note, however, that if you hope to build a true private cloud for your organization you will need to transition away from relying on legacy-based data center infrastructure. Many people think private cloud infrastructure just means virtualization -- yet support for virtualization is merely one aspect of a private cloud. True private clouds use software-defined architectures to integrate compute, storage, networking, security, management resources and virtualization into a highly scalable system that automates provisioning while delivering user self-service. Unlike traditional infrastructure, well designed clouds distribute everything, are resilient and self-healing, and feature extensive automation, allowing them to scale without limits. To the user, a private cloud looks, acts and functions like the public cloud. Traditional legacy infrastructure is simply not designed to deliver this type of functionality -- new software-defined “everything” infrastructure is.

In addition to building out both a private cloud for your business and setting up your organization to use the public cloud, you will need to determine which workloads belong where -- on your on-prem or hosted private cloud or public clouds. The best way to make this decision is to determine if, for a specific application or use case, you want to rent or buy your cloud service. For example, if you went on a week-long vacation to London it would not make sense to buy a new car to get around during your visit. You would simply rent a car. On the other hand, at home it would be uneconomical (and a hassle) to rent the car that you use for your daily commute to work, to go shopping, and to pick up your kids at soccer practice. Instead, it would make more sense to buy a car to limit costs over time.

In the same way, public cloud services delivering SaaS are generally better for "rental" workloads, while private clouds are better for "owning" workloads. Unpredictable, highly variable, short-term workloads are well suited for the public cloud. You only pay for what you use. However, for more predictable and established workloads, a private cloud will allow you to own the infrastructure and will deliver better cost savings over the long-term.

This decision leads to another key consideration in your organization’s journey to the cloud -- mobility. Once an unpredictable, short-term workload becomes a more predictable, long-term workload, it often makes sense to shift it to a private cloud. Likewise, you might eventually want to move a previously predictable, long-term workload to a public cloud service. One of the key mistakes many organizations make is to fail to realize that their workloads and cloud services are constantly changing, and they soon find themselves spending significant effort and time moving workloads between clouds. In your journey to the cloud, you need to make sure that your private cloud features an architecture that includes strong support for the public cloud services. This means that when you move a workload between clouds you don’t need to make any application changes, can easily preserve any application state, configuration, and environment requirements, and can translate a workload’s SLAs to its new environment. With this type of mobility, your organization will be positioned to quickly and easily move workloads between clouds as your business, and thus your workloads, change.

In the end, a successful journey to the cloud means moving beyond the storm and fury of the "clash of clouds" to a place where you can use both as needed. With private and public clouds at your disposal, a good plan for determining which to use for various workloads, and an architecture that enables workload mobility between your clouds, you will soon find your IT department has the power to economically deliver end-users the ease-of-use, self-service, scalability and agility they need to succeed in today’s dynamic, digital business environment.

Image Credit: Creativa Images / Shutterstock

Sachin ChhedaSachin Chheda is the senior director of global marketing and verticals at Nutanix. Prior to his current position, he worked in marketing, product management and engineering at some of the most innovative enterprise tech companies. Sachin has both a Bachelor's of Science and Master's of Science in Electrical and Computer Engineering from Carnegie Mellon University. To learn more about Sachin's take on enterprise cloud vs. public cloud, click here.

Comments are closed.

© 1998-2021 BetaNews, Inc. All Rights Reserved. Privacy Policy - Cookie Policy.