TL;DR Like many others, I used to believe Cloud was just a computer somewhere else. I've since come to the realization that Cloud is an application that abstracts and virtualizes the operational details of the servers, software, networks and storage required to deploy modern Internet-based applications. If Enterprise IT is to survive the onslaught of Cloud, they must adopt the same operational efficiencies as AWS and other public cloud providers. This includes exposing IT as a Self-Service Application or Portal. Only then will they be able to stave off Shadow IT and offer their customers the ability to develop, deploy, and manage applications without the day-to-day involvement of IT Operations.
I freely admit it took me a while to come to terms with the term "Cloud". For years I used the infamous Visio cloud shape in my network diagrams. Still, it was difficult to buy into "cloud" as a revolutionary new place where data could be stored centrally and transferred locally over high-speed Internet. "Cloud" became a term that I viewed as spin on the old: mainframe, client/server, web hosting, ASP, MSP, CSP. In short, "cloud" was a new term for the same thing – my "stuff" is stored and running elsewhere. And yes, I admit to getting a kick out of watching Larry Ellison poke fun at Cloud Computing back in 2008. With his usual flair, Ellison pointed out that "Cloud Computing" covers everything we were already doing. In the late 2000’s, everything and anything in the computing industry was described as Cloud, Cloud-ready, or Cloud-enabled.
For years I wholeheartedly agreed with anyone that claimed that “cloud” was just a marketing buzzword. With time, though, my attitude slowly shifted. Cloud isn't necessarily a set of servers that live on a faraway network. A true cloud is a software application, complete with its own UI, API, user management, and a suite of opaque services. Virtualization at the server, network, and storage levels allow users to interact with abstractions that look and feel like physical systems. Cloud architecture is yet another example of Marc Andreessen's declaration that "Software is eating the World", only this time it's enterprise IT being served up for breakfast, lunch, and dinner.
With the right amount of vision and execution, enterprise IT stands to benefit from cloud computing. But it will require them to provide users the ability to utilize resources on their own terms. This is a delicate balancing act:
- Too many restrictions from IT will drive users into the arms of public cloud providers while fueling shadow IT.
- Running a wide-open environment will come at the expense of security, reliability, and maintainability.
If enterprise IT is going to survive and thrive in the face of public cloud, they need to balance corporate governance needs against user self-service and operational agility that encompasses what the leading public cloud providers are already doing – certainly no easy task.
First this requires embracing the fact that service desks and request tickets are relics of IT past. Users (specifically developers) want fast, easy, and reliable access to IT resources and the freedom to experiment and innovate without the overhead of passing everything through IT operations (ITOps). With the new enterprise Cloud, developers and product teams become responsible for the deployment and management their own applications. ITOps provides the platform for enterprise cloud applications (web-based or otherwise) which manages all the backing networks, systems, and storage. Unless a problem percolates up to the application level, users have little-to-no visibility into what's happening behind the scenes.
As a test of this model, think of AWS. Do you frequently file trouble tickets with AWS? Do you constantly hear about day-to-day operational difficulties at AWS? Do you find yourself waiting until some AWS team returns from lunch to get the servers or services you requested? If your enterprise IT team is embracing what I feel is the true meaning of "Cloud", then asking these same answers of your enterprise cloud should yield the same resounding "NO!"