Increasingly it’s clear to me that there are two worlds of cloud users, the populations of which often do not realise they are world’s apart. The first is inhabited by traditional enterprise IT users. Extending the analogy, it has more terra firma than clouds.
The second has a population of cloud-first companies who use cloud-era technologies. They largely do not use Windows, SQL Server, WebSphere or similar packaged software, and instead their first choice is a SaaS or Open Source equivalent like Debian, MariaDB, Couchbase, django or a plethora of technologies and languages.
The world of enterprise IT has a density of applications, systems, hardware and processes which create a huge gravitational force towards status quo. Change is costly and risky. Interestingly, the perspective of enterprise IT folk actually distorts how clearly they can see what cloud is, and can offer. More on that later.
New cloud technologists are often fairly crap at risk management and change control until they’ve either hit some kind of scale (which brings the need for change control and rigour) or failed in some way. There’s often a religious rejection of anything that sounds like waterfall method (like planning), and a sprint to the next scrum instead.
I could have expressed this idea as a continuum with enterprise IT represented by banking at the most extreme on one end, and a seed-funded fledging internet startup with a few clients at the other end. One has great traceability and stability, the other has great spontaneity and agility.
James Staten from Forrester used a nice diagram which expressed how enterprise IT guys see cloud differently to cloud-era folk. The essential difference is that enterprise guys see cloud as the next logical evolution of virtualisation, whereas cloud developers see it as a programmable service. He comments on how this leads to private cloud implementations failing because the enterprise guys make it robust and highly change-controlled, whereas the developers just want an API that abstracts all those details away so they can launch a server in 5 minutes.
Google the paper “Rise of the new cloud admin” if you’re not a client, and read it. It’s absolutely spot-on awesome.
Result is, in the real world, that an enterprise decision maker will look at his sunk investment in a VBlock environment and ask me if we can make it into a cloud. Sure. But that question only gets you to first base.
You can run a private cloud on enterprise-grade hardware, but you don’t have to of course. Let’s assume you do though, because you want more HA on the private cloud, because that’s the norm. Then the usual first step is to make it easier for test and dev workloads — so your application teams can launch a base server really easily to test a new version of an application. Making that happen with a self-service portal isn’t hard either.
Here’s the catch though. Enterprise users are then putting traditional packaged applications into a private cloud, managed by ITIL, subject to change control and normal InfoSec policies. So you get a non-agile result in some dimensions. The dimension you have made cloudy is provisioning the hardware and operating system layers of the virtual machine, using a self-service portal.
Often, the installation of that enterprise application is not automated. If it is, it’s not multi-cloud portable, nor version-controlled so it can be elegantly moved through a lifecycle of test, staging and production.
The difference in the cloud world is that the application would have been defined and installed using configuration scripting. The application gets considered first, the hardware and operating system are almost assumed.
The interesting challenge for enterprises is to simultaneously:
- look for enterprise applications they can move to the cloud,
- identify applications they can migrate to cloud-era technologies, particularly considering NoSQL or graph databases, or cloud-friendly horizontally-scaling frameworks like django
- identify applications or systems where configuration-based infrastructure definition is possible (RightScale uses Puppet or Chef), instead of virtual machine images which are managed under change control.