To “Cloud” or Not to “Cloud:” Taking Baby Steps In Your AWS Journey

I see you standing over there, pondering a move to the cloud. You’ve heard the “c-word,” you look around and see many of your peers and competitors talking about it – but you’re not sold on moving your production applications there just yet.

Certainly, at this point in the cloud revolution, you understand that it represents a serious business decision that you cannot defer much longer – that if you don’t start leveraging the cloud somehow, you may miss out on some significant opportunities.

Some of you might even be at the “tinkering” phase – thinking that you might be able to “build your own,” and subscribing to free accounts to get the lay of the land. You quickly find out that the cloud can be quite complex, and though you see the similarities to your on-prem environment, you can’t quite put your fingers on how to take advantage of the benefits.

You’re also realizing that there is a somewhat steep technology learning curve — not only for you, but for your team; and while that, in itself, is a challenge, you know the greater challenge is in adopting all of the current and future initiatives, organizational approaches, business compliance, and still emerging on the other side feeling like you are in control.

Of course, this is all overshadowed by concerns that, if you or your team makes one misstep or miscue, you can lose much of the equity you have built by solidifying and securing your existing machine virtualization platforms. This is enough to give anyone pause, and to really wonder: “Why should I even consider a change?”

Finally, there’s the investment you’ve made in all that hardware – a double-edged sword, since you know that you can gain some cost efficiencies by moving to the cloud, but you are still amortizing your investment in on-prem components – and, as we’ve established, you’re firmly on the fence.

So, perhaps the question is not, “to cloud or not to cloud,” but in fact, is, “can I mix what I have with the cloud?”

Thankfully, the answer is a resounding “yes.” The fact is, a cloud migration journey is quite different for each enterprise, but the mandate that the evolution must be “all or nothing” is not only misleading, but wholly untrue. While it has become a common approach, it’s not the ONLY approach.

For someone with your level of concern, the most likely approach to initial cloud adoption for your organization may be centered on getting your organizational feet wet, using what has been coined a “hybrid” model. The hybrid approach in today’s cloud adoption terms represents a “compromise,” where you maintain business as usual for your current technology stack, but leverage cloud for additional initiatives such as disaster recovery, application development, or both.

While this is not a new approach (Amazon Web Services, for example, endorsed this approach about five years ago, and it has been picked up by many vendors since), it is gaining momentum of late – as evidenced by the recent announcement of an AWS/VMWare partnership. Organizations pressured both enterprises to adopt this approach because they are not ready to “throw out” what they have, instead favoring a philosophy whereby they can gain the flexibility of leasing, rather than purchasing, hardware; while leveraging the cloud to pay only for the compute resources they consume.

This hybrid approach, in particular, represents a dream scenario when it comes to development and disaster recovery.

While I plan on going into deeper detail in future posts, let’s capture some highlights regarding the benefits for each of these use cases.

Development: For those who use an on-prem infrastructure in the development process, you know it can be a constant struggle to allocate the necessary components for proper experimentation. That’s because it’s difficult to justify the costs of an environment that is not always in use, and while it is considered necessary, it is not considered critical to the operations of the organization.

To compensate, developers tend to use production platforms for development – a slippery slope that can lead to potential errors, skewed data, and potential impacts to the production environment. The challenge with all of these scenarios is that typically, development is done to validate what we already know, not to experiment with things we don’t necessarily know — which, in turn, would create a higher level of innovation.

In this vain, why wouldn’t you indulge in an environment that provides you the ability to create separate platforms, providing your organization the ability to completely simulate your working environment? If given the opportunity to simulate your working environment, you could completely prove your answers, as well as conduct a higher degree of experimentation, all while paying only for what you consume, while you’re consuming it.

Disaster Recovery: Traditionally, this has been a hard pill to swallow, since the technology method is “like for like.” In a traditional DR scenario, you are essentially duplicating the technology you have deployed in production at a protected physical site. Everything — from power, to cooling, to rack space, to the technology platforms themselves – is just sitting there in an idle state, waiting for something bad to happen.

Here, as in the development example, cloud represents great strides in cost efficiency. Depending on your adopted strategy, DR in the cloud gives you all of the benefits that come with minimizing your downtime, without the care and feeding of a dormant physical location.

Again these are not new concepts, but instead represent a way to make this step on your cloud journey a little more palatable, if you’re not ready to dive in, head first. For those struggling with the decision of “to cloud or not to cloud,” I would suggest that you start your journey with a more measured step – a “toe-in-the-water” approach that is designed to help you continue to fulfill new more complex business requirement, while at the same time introducing you, in a less aggressive way, to the cloud.