Concerning Microsoft's Azure pitch to cloud service providers
Trevor Pott on MS's Amazon-seeking torpedoes
Feature Microsoft is advancing non-Microsoft service providers as a core part of its Cloud OS strategy. In part one of this series I looked at what Cloud OS was and why you might care about using it on your own premises.
This article will examine how those service providers fit into the equation.
To be clear, "service providers" in the Microsoft context means companies running the Microsoft stack of software and providing services to customers over the internet. Previously we might have called these hosting providers, while the new industry generic term is cloud service providers, or CSPs.
Get used to that one because CSPs are the new black and everyone is courting them. The software and hardware markets used to be broken down roughly into SMB, enterprise and government.
Now it is CSP, enterprise and government. SMBs who choose not to buy into cloud computing are unlikely to get much love from anyone.
Little and large
CSPs are a diverse category of businesses. They range from the small IT consultant offering some basic off-site backups to their clients over the internet to full-bore managed service providers such as Metacloud.
Basically, a CSP does "something involving computers on the internet". The definition does not encompass the tier-1 providers such as Amazon, Google or Microsoft. Those are in a league of their own and are typically what is meant when people talk about the public cloud.
This all gets rather taxonomically messy, like anything involving cloud, because some people consider CSPs to be those that host their own infrastructure, while others don't care whose infrastructure CSPs use so long as they buy software licences at scale.
The Microsoft terminology behind "service provider", however, is important to our poor, beleaguered SMB admins. As the industry shifts, their jobs are drying up and many of them are transitioning to other roles, for example going from being a sysadmin running one company to one running many companies.
These sysadmins usually stand up their own infrastructure at the local co-lo and provide services to their stable of customers. Here, then, is the entry to the Microsoft service provider, scaling up all the way to the kinds of businesses that do VDI for governments.
Follow the brand
Building your own Microsoft-based IaaS cloud is easy enough; you can even automate that portion of the exercise, if you wish. System Center even offers you the basics required to create a platform-as-a-service setup.
Where it really comes together is with Windows Azure Services for Windows Server (WASWS). (Microsoft, please find the committee members responsible for this product name and banish them to an office in Siberia.)
This gives you an Azure portal for your developers and end users. It takes a fair amount of effort to get set up, but once you have some orchestration bits done, your templates ready and so forth, you have created a service that provides an end-user experience indistinguishable from Microsoft's publicly hosted Azure cloud.
The whole branding exercise around this is a crime against tech marketing. So let's wrap it all up for better ease of understanding and (much to Microsoft Marketing's dismay whenever I use the term} call this combo "Azure on premises" and "Azure service provider."
Service providers are Microsoft's not-so-secret Amazon-seeking torpedoes. Service providers allow Microsoft to monetise something Amazon will never be able to: trust.
Not everyone is comfortable with American public cloud providers – least of all with big, fat, tempting targets such as Microsoft, Amazon or Google.
Suing the government for permission to talk about secret court orders and secret laws reviewed only by secret courts is a marketing exercise doomed to failure. Nobody is going to trust what any American cloud provider has to say while anything resembling "national security letters" still exist.
Even if the laws change, it could take years for trust to be rebuilt, assuming that is possible. Amazon and Google are out of luck. There is a significant market consisting of people whose risk tolerance doesn't extend to trusting American cloud providers. Amazon and Google will simply never be able to address it.
Enter Microsoft's service providers. It may be that you don't give a fig if the NSA reads your customers' email, but if you are a regulated industry then in many nations your hands are tied all the same.
Perhaps your concerns are more pragmatic: bandwidth costs can kill off the idea of cloudy anything pretty quickly, but you can usually negotiate a much lower rate if the bulk of your traffic is restricted to the same network as your ISP.
Ultimately you want a neck to wring when something goes wrong
Maybe your personal vendor selection metrics mean that ultimately you want a neck to wring when things go wrong – something not possible with the larger cloud providers.
There are lots of arguments for and against off-premises cloud computing, but many of the "against" simply disappear when your providers get more local.
Restoring 100TB of data from the cloud provider is a lot easier if you can drive across the city and pick up a bag of drives than if you try to do your restore across the internet.
An important part of Microsoft's strategy is that the customer-facing interface is very similar across all three tiers of Azure. If you can use Azure on-premise then the Azure service provider will look and act the same as the Microsoft public cloud version. As a service provider this gives me some mixed feelings, but on the whole I think it is a good plan.
It has been pretty bluntly stated to me that the rationale behind the unified interface is to get end-users so comfortable with it that they migrate to Microsoft's public Azure offering.
As a CSP I find the concept a little cold blooded, but it works both ways: those using private clouds will be more likely to move to a local CSP if they are familiar with the interface.
I am less sanguine about the limited customisability of the interface. The means by which I can differentiate my business seem to boil down to location, reputation (a function of marketing and internal business processes) and some minor differentiation in the templates I provide as my virtual machine offerings.
Buying into Microsoft's grand vision is essentially making that segment of your business a Microsoft franchise.
You can make good money owning a few Tim Hortons coffee-shop franchises, but your moderate collection will never threaten the larger corporate body. No Amazons will emerge from the Microsoft service provider stable.
As with any franchise, you pay the corporate fees – and you have zero say in what those are. With Microsoft's service providers they keep going With Microsoft's service providers they keep going up and up and up while the rewards go down.
At the end of the day, you will buy it and you will like it. To attempt to explain why, I will stretch some comparisons to breaking point.
As discussed in the previous article in this series, the cloud is the new operating system and Microsoft already owns the commercial off-the-shelf (COTS) version of this technology.
PistonCloud is probably the closest real competitor (now that it has added support for automation) but we are still talking about how Linux was competing with Microsoft for the COTS installable desktop.
Amazon and Google will only let you play on their infrastructure and thus are the Apple of this new cloudy era.
VMware will sell you the computer portion of the exercise but it ends at the virtual machine and VMware doesn't seem all that interested in what is inside it. That pretty much makes it the Supermicro of cloud vendors.
It is early days yet – and there are plenty of competitors jostling for position – but Microsoft's Azure service provider offering is your chance to be the next Dell
Yes, Dell is in enough trouble that Big Mike has to take it private, but it had a decade or two of glory and made its shareholders filthy rich. It became what it is by selling computers with Microsoft Windows installed, slapping some apps on top and supporting the stack.
Today, you can stand up a cloud with Microsoft Azure service provider installed, slap some apps on it and support the stack. Just as with Windows, once your customers are hooked, they are yours for life.
I ran into this face first. While testing an early Azure service provider setup I made the mistake of showing a few clients how it worked. I forgot to revoke their users after the initial demo and several of them decided to start spinning up virtual machines.
Now they are in the middle of a production season, running production workloads on this infrastructure and have become utterly dependent on it being operational.
I am not tooled up for this – it's a testlab, Jim, not a full data centre! – but I am down the rabbit hole on this one anyway.
For now, we are moving their workloads off to Microsoft's Azure public cloud so that I can buy some servers and co-lo space for my first commercial Azure service provider cloud. (More importantly so that I can stop hosting their virtual machines on the Azure virtual machines that are sitting on top of my VMware testlab.)
Ultimately, those workloads will be coming back; for various reasons, the public cloud is a bad fit.
The next article will touch on that migration and explore what the Microsoft's public Azure cloud has to offer. ®