What lies beneath Microsoft's Cloud OS?
Trevor Pott compares and contrasts with VMware cloud view
Analysis Microsoft has a new branding exercise for you called Cloud OS, and for the first time in a while I am on board with the idea.
The concepts behind Cloud OS are relatively easy to grasp, but as ever the devil is in the details. This is the first in a three-part series exploring Microsoft's vision and how it stitches together in the real world.
Azure all around
The basic idea behind Cloud OS is simple: Microsoft's infrastructure, everywhere. You can create a private cloud with Microsoft's various server technologies on your own premises, you can rent resources from a local service provider or you can use Microsoft's Azure public cloud.
The technologies underpinning all three are more or less the same: Windows Server, Hyper-V, MS SQL, IIS and so forth. There is even a unified end-user interface to this infrastructure in the form of the Azure self-service portal, installed on-premise, at the service provider or (naturally) on the Azure public cloud.
I am not normally one to buy into marketing malarkey: I get paid to take the piss out of everything I possibly can. "Cloud OS" seemed to me to be the worst kind of marketing mumbo-jumbo until someone took the time to explain how the name was arrived at. From there, what Microsoft is trying to achieve makes a lot more sense.
Traditionally speaking, an operating system is a layer of software that sits between the applications you want to run and the hardware. It controls the hardware and presents a set of APIs to developers that abstract away a lot of the more complicated bits of working with that hardware so they can get on with making their applications do what you want.
This is not too dissimilar from the difference between bit banging, a serial interface and letting the hardware SPI handle that for you.
Microsoft sees what it is building as a similar concept, but on a scale that previously was nearly impossible to achieve. Microsoft's view is that it has achieved a collection of hypervisor, operating systems and applications that when combined provide multiple individual systems in multiple data centres working seamlessly together as one logical entity.
This is an operating system that gives you a single point of management and a single layer of APIs, storage interface and what-have-you stretching from your server closet to the local service provider to Microsoft's Azure data centres around the world.
When looked at from that angle, I can't help but agree that it deserves to be called a Cloud OS.
Give me more
This year, I applied for and was awarded the designation of vExpert by VMware. I went through the evangelism track and was accepted largely because I am a huge advocate of VMware and its excellent technologies.
Despite this, I have a take on the proper definition of cloud that puts me at odds with many of my peers in the VMware community. My take on cloud is – oddly enough – much closer to Microsoft's approach.
In a VMware world – at least in the light of its latest acquisitions – a cloud is essentially infrastructure as a service. This includes a hypervisor, virtual machine orchestration, load balancers, firewalls, virtual networking (including virtual network bridging) and intrusion detection systems. Fair enough; not too long ago that was a Microsoft private cloud marketing pitch, too.
I don't buy it. To use a rough analogy, this is like presenting me with an x86 PC that is fully assembled and has a working BIOS, then telling me to write applications for it.
Many of us buy our systems that way and spend way too much time beating the things into submission
That is fine for the nerdorati; many of us buy our systems that way, install our own operating systems and spend way too much time beating the things into submission.
Others – usually large enterprises – have complicated systems whose only purpose is to take these bare-metal systems and provision all the bits necessary to make them actually useful. You wouldn't hand such a bare-metal system to end-users and ask them to use it, nor would you hand one to a developer and tell them to code on it.
To my mind a proper cloud needs something inside those virtual machines: an operating system – or at the very least the tools to manage and maintain the one you load in there.
It needs a way to store information, an API to code to and a way to present what you have written to end-users. This comes in the form of "infrastructure applications": typically a file server, an object storage server, an SQL server, a web server and so forth.
It is only here that you have replicated a modern operating system in a manner that can scale from a cloud of two systems to a megalith stretching across dozens of time zones. Yes, I am aware I just said platform as a service is where cloud starts to become usable. It is where we can actually do something with our infrastructure that we have a Cloud OS.
Run this idea up a VMware flagpole and you will notice a dearth of saluting. VMware – and, frankly, most VMware admins – are strictly infrastructure folks. They don't particularly care what is in the virtual machines they manage, so long as the VMware tools say the virtual machine is healthy. Dealing with operating systems, apps, end-users – that is Someone Else's Problem.
I would love to live in that world – you can't imagine how much I would love to have a job that easy – but users, managers and so forth see Gmail, Amazon Web Services and other such things "just work" as fully managed services and have come to expect the same from internal IT. Adapt or die.