Be the Cloud You Want to Use

#devops #linerate #cloud

"Stop thinking...let things happen...and be...the ball."

Some of you will remember Caddyshack - that campy 80s movie in which Chevy Chase often offered crazy advice, like "be the ball." For those of you who don't (because you're too young or were living under a rock), the premise of this particular piece of advice was along the lines of Obi-Wan's "Use the force, Luke" encouragement. To put it more simply (and without a metaphor) become a part of that which is important to what you're trying to achieve. Understand your goals from the perspective of the thing that achieves it.

In the case of many operator today that means you must "be the cloud you want to use."

The reality is that shadow IT (or whatever you want to call it) exists because current infrastructure is not as flexible, easy to use or as fast to provision as that in the cloud. Neither does existing licensing and billing for on-premise solutions meet the current, just-in-time attitude associated with cloud and agile business models.

Ultimately, what DevOps seeks to achieve is accelerated application deployment. That's why cloud in all its forms - public, private and hybrid - continue to gain mindshare, traction and customers.

The public cloud model serves as the archetypal rapid deployment model. With APIs that encourage automation and orchestration and a billing model that favors the transient nature of demand for resources, the cloud model presents the penultimate experience for operators and developers with respect to getting applications to market. Fast.

Seamless Transitions

But notice it's only the penultimate experience. That's because there are still aspects of cloud which frustrate both business and operations alike after deployment. Concerns with performance and migration between environments continues to give many enterprises enough pause that while they are embracing public cloud, it's a tentative embrace based more on the understanding that the relationship is born out of necessity, not necessarily love. It's an arranged marriage with political and financial benefits, not the product of true love that simply cannot be kept apart.

Because of this, hybrid cloud is inevitable. There will be applications deployed in both public and on-premise models, and eventually the expectation of a seamless transition between the two will become more than expectation - it will become a demand. A requirement. A must have.

That's more problematic for operations (and thus DevOps) than it is app dev. Virtualization, containers, and other technology has enabled a much simpler path forward (and outward) for applications than for its critical infrastructure. And while for some the simplest answer is to simply virtualize that infrastructure, too, there remain obstacles peculiar to the network that prevents Occam's Razor from cutting through that technical red tape.

Thus, it remains critical for infrastructure of all kinds to adjust to better fit within this abstracted, API-driven, software-defined world of cloud - both on and off-premise.  APIs must be provided. It must be cloud-ready. Billing models require adjustment. And rapid provisioning will be enabled, or else.

It is these requirements that are necessary to enable operations to be the cloud they want to use. Modern APIs enable automation through scripting and integration with cloud management platforms (OpenStack, VMware, CA).  New acquisition, licensing and billing models enable the "sometimes on, sometimes off" usage patterns common to many existing (maintenance windows still exist in the enterprise, after all) and new (adoption is always erratic in the beginning) applications.

Thus it's important for critical infrastructure - the pieces of "the network" that are considered imperative to an application deployment - are able to be deployed both on-premise and in the cloud with equal alacrity and, one hopes, with the same capabilities.