A few weeks back I seem to have mystified a few readers with my apparent volte-face on the topic of private cloud, when I pointed out that any public cloud provider has to run a private cloud to operate its own service or platform. To help explain my thinking, I thought it might be useful to share with you today the ancient fable of the three little clouds and the big bad world.
One day, three little clouds decided to leave the safety of the familiar enterprise network where they’d grown up and set off to make their fortune in the outside world. Their guardian was proud of their ambition, but like any parent-figure wanted to be sure they really understood all the risks they’d be facing. “Whatever you do,” she warned them, “watch out for the big bad world out there.”
The first little cloud decided to minimize its risk by reducing its exposure to the outside world. It had a website with an e-commerce capability, some mobile users and a handful of servers at remote sites, but it avoided adding any new SaaS applications or public cloud resources. It bought some reassuringly expensive firewalls, load balancers and fancy routers from a friendly travelling salesman and configured them as best as it could. What could possibly go wrong? But this little cloud was built of straw. It didn’t have the expertise or resources to keep its infrastructure up-to-date with all the threats it faced at various touch points with the public Internet. Very soon a storm blew up and the big bad world came huffing and puffing, stealing away the little cloud’s customer database and leaving all their credit card details fluttering in the wind.
The second little cloud saw all this, shook its head in dismay, and hired a chief security officer to make sure its infrastructure was proof against even the most determined attack. It built out enough server capacity to meet its needs for the foreseeable future and settled down in its comfortable new citadel. But this little cloud was wooden to the core. It hadn’t foreseen just how busy it would become. One day, the big bad world came knocking on all its doors and windows until the little cloud ran out of capacity. All its servers splintered under the load, collapsing in a terrifying outage that drove its customers far and wide, never to return.
Much further down the road, the third little cloud had built its infrastructure out of magical elastic virtual bricks that would never fall over and were perfectly engineered to resist attacks, even from within. When it saw its two little brothers running down the road, it opened its doors and let them host their operations on its own infrastructure. Hot on their heels came the big bad world, but the more it huffed and it puffed, the more elastic and resilient the magical bricks became.
Soon the little cloud and its brothers had swallowed up everything the big bad world could throw at it and still they asked for more. Before long, all the animals of the forest and the business people from the nearby town were clamoring to come inside so that they, too, could prosper from the elastic cloud’s insatiable capacity. And so the little private cloud grew up to become a world-leading public cloud provider and everyone lived happily ever after — even the big, bad world.
The moral of the story? It’s probably best summed up in a response to Ben Kepes that I posted in a comment on my prior blog post:
Public cloud services have to be built on private cloud infrastructure (sometimes it’s virtual private, sometimes its physical private) but the result is still a cloud-scale, highly connected public resource.
The same term, private cloud, is used to describe enterprise-centric architectures that shy away from connection and are populated with application stacks incapable of operating at cloud scale.
These two forms of private cloud are completely different animals from one another and it is the second category with which I have a problem.
For a happy ending, be sure to build a cloud-scale, highly connected public resource. And if you can’t afford to, run on someone else’s.
