What you need to know about moving to the Azure public cloud
Report from the frontline
Cloud service providers, the focus of part two, are important to Microsoft's plans as well. But Microsoft's plans do not end there: the company has gone and built itself one of the largest clouds on the planet.
It really, really want you to migrate your workloads there and, most importantly, pay it that delicious monthly subscription.
Technology-wise, what it has is pretty good. Even if Gartner is a little angsty about the concept of public cloud, Microsoft dogfoods its cloudy offerings by running Office 365, Bing, Xbox Live and pretty much everything else on top of the same infrastructure it is peddling as its public cloud.
There is no dark magic to Microsoft's public cloud. Indeed, for Microsoft's Azure-Server development feedback loop scheme to succeed, there can't be. What goes into Azure ends up in the server applications and vice versa.
If you want to build your own Azure to see what makes Microsoft's cloudy offering tick, it has the tools for you do just that.
In the first article of the series I talked about how – in my opinion at least – a proper cloud has to be more than just infrastructure as a service. While moving beyond this at the on-premises or servicer-provider level requires a lot of work from cloud herders running the thing, Microsoft's app farmers raise good server cattle.
Want to light up a web server? Microsoft will create an IIS-based web server that allows you to code in .Net, Node.js, PHP or Python. LAMP-based web servers are still second-class citizens requiring sysadmin TLC to instantiate and maintain.
The default database is, naturally, MS SQL, which now offers NoSQL and Blob storage to 200TB just in case you need room to manoeuvre.
Microsoft puts Mobile app development in a marketing category separate from standard websites, offering a messaging bus for things like push notifications and inter-app communication and notification hubs to make some of that messaging more manageable.
The Big Data button will take you to a page extolling Microsoft's Hadoop offering, HDinsight, with the big hint that you really should just do all that in MS SQL. (Because it does Big Data now too, dontchaknow?)
If you are in love with Active Directory and want it to be the centre of your single-sign-on universe you can do that in Azure too and they will even throw in a side of multi-factor authentication if that is on your list.
Also worth mentioning is Media Services, a nice wrapper around a combination of automated transcoding, third-party CDN hooks and the APIs that bind them.
Pack your bags
In the second article of this series I talked about how a test environment accidentally turned into a live environment when customers started provisioning real-world workloads on it.
This was a less than optimal situation for me and the quick way out was to move the workloads to Microsoft's Azure public cloud while I get my Azure service provider cloud lit up.
Simply picking up your virtual machines and moving them to Azure is actually really easy. Doing so without breaking everything is hard.
The first rule of virtual infrastructure on Windows Azure is pay attention to virtual networking. Little things like "are the virtual machines you are uploading trying to run DHCP servers?" or "are you sure they don't have static IPs?" are compounded by bigger issues like "how do you access the things once they are up there?"
Make sure you have RDP, Webmin or another form of access set up and that any non-standard ports you might be using are accounted for in your firewall config changes.
The virtual machines that get uploaded had better be rock solid
VMconnect-based console access is not an option, so the virtual machines that get uploaded had better be rock solid. In the end I resorted to Teamviewer and lots of post-setup tinkering.
Once you have this sort of thing down to a science you can even automate moving your virtual machines from your local cloud to Microsoft's public cloud.
If you are doing something along these lines – joining your on-premises network to your Azure-hosted one – then you are into the hybrid cloud concept and need to start caring about VPNs.
I would also strongly recommend this MVA course on the topic.
As much fun as it is to upload VHDs to Azure storage, realise you screwed something up, then upload another copy, I can't say I am a fan of this when trying to get 30-odd virtual machines set up and running.
The hybrid cloud thing starts to become a good friend here, as you can do a lot with PowerShell.
I have nothing nice to say about licensing. But if you plan to use Azure you need to learn about it.
The right mix
I have been – and probably will be for some time – a critic of cloud computing. I have issues with many of the vendors. There are legal unknowns surrounding the use of US public clouds that are beyond my risk tolerance, and quite frankly I am voting with my wallet on this one.
The sojourn of these workloads into Microsoft's public cloud will be brief. There are no local Azure service providers yet, so necessity dictated a distasteful choice.
Despite my misgivings, I learned a lot. I have a great deal of respect for the technology Microsoft has on the table. I am a trenchant critic of much of what Microsoft does but I am pretty much sold on this Cloud OS idea.
Microsoft's server tech is good. The Azure public cloud is good. The Azure service provider and Azure on-premises stack of technologies is a decent installer away from excellent.
Like it or not, some combination of local and public cloud is the future of computing. With the on-premises, service provider and public cloud triad, I think Microsoft currently has a better chance of winning this than anyone else.
Pay the price
Using a public cloud – and Microsoft is no exception here – is expensive. I am sure that someone will be along in the comments to explain in abstracts with some unverified assertions or irrelevant case studies why the TCO is lower in the public cloud and the ROI is higher. After years of consistent research and testing I remain unconvinced.
According to the Azure calculator a single medium virtual machine with a pair of anemic 1.6GHz cores and 3.5GB of RAM will cost me $134 per month for Windows Server and $89 for Linux. That is $1,607 per year for Windows and $1,071 for Linux, not counting bandwidth or storage.
For the past year I have dropped in Supermicro 2U Twin2 with a VMware Essentials Plus kit systems and three years of business-class ADSL for $20,000 to customer locations. Bump that up to $30,000 if I want Windows Server instances on the three active nodes.
This gives me three nodes (with one cold spare) that each have 128GB of RAM, eight cores total usable storage in the 12TB range. Assuming no memory overcommit is used, that is about 100 of those "3.5GB of RAM" virtual machines in one of my standard clusters.
Azure pricing over three years would have cost $321,408 for 100 Linux instances or $482,112 for 100 instances of Windows, again not factoring in storage or bandwidth.
Clearly, I need to charge a great deal more to manage and maintain a small business cluster. Those prices are enough to dedicate a sysadmin to that one wee cluster for the entire three-year stretch, at the local labour rates.
We are not even touching on the fact that most businesses I work with will run that cluster for 10 years before a refresh.
My own experience makes me biased when I examine all these technologies. I am not talking here about the baggage that comes from decades of dealing with various vendors or beating one technology or other into shape.
By bias I am talking about the limits on how I can even conceive of computing. Workloads, data flows, authentication systems – my conceptualisation of these is coloured by the client-server model I grew up with.
I still think, cost and otherwise operate on infrastructure units that are based on my experience. I think in virtual machines, not workloads. I spec more RAM than absolutely needed, I assign more storage to things "just in case" and I don't refresh everything every three years.
If I take a completely different approach to costing – the aforementioned per-workload model – then the workloads that I am actually running on those clusters, as opposed to the workloads I have provisioned, more or less come out even on cost.
Getting there requires not doing everything as a virtual machine that I then manage. If I start to do most things as web workloads, databases and so forth, supplementing with virtual machines only where they don't have an appropriate pre-canned offering, then the costs go way down.
Start adding up the numbers and Microsoft is charging about 10 per cent more for the labour than I do to deploy and maintain the same workloads. Considering that it will most likely make a better job of it, with resources an order of magnitude more than I could ever dream of bringing to bear, that is a scarily acceptable mark up.
What I perceive to be the atomic elements of computing infrastructure changes how I view simple things like pricing. Inevitably, it also influences how I view the design of these workloads and how I engineer their interactions.
And the winner is ...
Given the explosive growth of cloud computing, my reluctance is obviously not shared by all. It is clear that so many people feel this way that Amazon, Google and all the rest of the public-only cloud providers are not guaranteed victory.
Microsoft's Azure public cloud is there for those who wish to adopt it. For those who don't, there are the service provider and on-premises offerings.
This is Microsoft's Cloud OS strategy. It is backed by good technology and it stands an honest chance of winning in a newly competitive IT environment.
What will you choose? ®