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.
Prepare for the challenge
You can technically get all of this running on a single host if you want, but having a minimum of two nodes so that you can use high availability is typically the starting point for a production environment. In my experience, this is harder than we would all like it to be, but it is ultimately worth it.
It took me 12 tries to get the whole stack of software alive and kicking back when it was code-named Katal. I still have that setup running and it is robust, capable and resilient.
VMworld consumed my life for several months and Microsoft marched closer to release. I was asked to write a series of articles on Cloud OS, got cocky and figured I could crush the install in a week.
I was wrong.
To put all this in context for those who have experience of Microsoft technologies, to get this to run properly is a challenge in the order of your very first time setting up Office Communications Server 2007, Exchange 2007 or the complete and unabridged System Center 2012 using the unified installer before the patches, and having skimmed all the gotchas in the documentation.
Read the documentation several times, make sure your DNS is absolutely perfectly configured and that you are accounting for the fact that everything in Microsoft's universe now prefers IPv6 over IPv4. Build it in a testlab several times until you are sure you have it down, and only then deploy.
If you are lazy (or poor) like me, and you don't want to set aside a couple of hosts to try this on, you can just light it all up (including your Hyper-V hypervisors) on top of your VMware infrastructure. For your first go at it, I can't stress this enough: you will want to take a lot of snapshots until you have the install sequence down to a science.
Let there be light
Once you get this stuff going it is fantastic. The Windows Azure Services for Windows Server (WASWS) customer portal to your shiny new private cloud is one of the only things defaced by The Interface Design Principles Formerly Known As Metro that I actually like.
The integration of System Center into the operating system and the infrastructure-level applications is excellent and it fits my views on what a cloud should be far better than anything else I have had a chance to work with so far.
If it had complete Puppet integration and a single-pane-of-glass user interface that I could tolerate using for 10 hours a day I wouldn't even look at another provider's software.
Setting aside any value-add that might come from the service provider and public cloud sides of the Cloud OS exercise, Microsoft has a compelling private cloud solution here.
Taken as a whole, and set up properly, Microsoft's offering really does abstract away the infrastructure portion of the IT exercise so you don't have to worry about it (beyond swapping out dead bits, naturally).
There is monitoring of the infrastructure, the operating systems, applications and a whole slew of best-practice analysers, reporting and analytics. The orchestration is decent – not quite vCAC, but good enough – and the customer portal is way better than the competition.
I won't lie to you and say Microsoft is crushing everyone on all fronts. There are gaps, features where Microsoft has a lot of catching up to do and ease of use issues that make transitioning to Microsoft frustrating.
I would probably get a sadistic thrill out of a reality television show involving the people who wrote the installers being in a gulag until the end of time.
The flip side of that particular coin, however, is that on every single front associated with virtualisation and private-cloud computing Microsoft has advanced significantly in the past five years.
With Server 2012 R2, System Center 2012 R2 and now WASWS, Microsoft has the chops to go toe to toe with the best VMware has to offer. It will win some categories and it will lose some, but they are on equal footing now.
With the Cloud OS concept, Microsoft's server folks finally have their heads screwed on straight and when it comes to standing up an on-premise private cloud, Microsoft mostly delivers.
The next two articles in the series will examine how well the service provider and the public-cloud versions hold up to the promise illustrated in the grand vision. ®