Live from the Ignite 2015 conference floor, 9:39 a.m. Central Time Wednesday, May 6: The process of evangelizing Windows developers to the new style of application development has begun. And it’s clear at the outset that the company has a way to go.
Granted, Wednesday at Ignite is the day after Cinco de Mayo. At an early morning session on managing and deploying hyperscale services on Azure, attendees’ eyes were already glazing over, and a few were dozing off. Some of those eyes – perhaps not all at once – popped open to see a demo of some of the first 2,000-node microservices apps on Azure being deployed through Windows.
The morning session began with Azure product manager Guy Bowerman taking developers and admins on a tour of deploying dependent resources, the way Microsoft originally intended – the way it works today. It’s clearly something less than hyperscale.
Bowerman described how developers writing cloud services for the new model would break down their applications and resources. The tool for deploying cloud resources at scale is Azure Resource Manager. (With Azure Stack now available as an option, Resource Manager will work for deploying applications on-premise as well as on Azure.)
It’s clear from listening to Bowerman that Microsoft had its own concept of scaling within what it calls a resource loop. The model there was apparently the deployment of simple web services. A resource loop declares a main VM and a few handfuls of dependent VMs, maybe up to 40. These VMs were contained within a single virtual net (VNET), and the dependencies between them were declared within a template file.
This was no way to do a microservices application, though it might be a nice way to float a web site. It’s well automated, and the steps to deploy a resource loop were few and straightforward.
But because the VNET was limited to a single region, it was only cloud deployment in a limited sense. VMs in the resource loop placed function calls to services deep within the infrastructure, and with only a few dozen VMs, those calls could bunch up and create bottlenecks. A microservices architecture may require thousands of virtual machines of one form or another (with Azure, they may or may not be Docker containers), so resource loops were, very simply, too small by design.
What Microsoft is announcing now — Virtual Machine Scale Sets — is a more microservices-friendly concept of scalability that plays more nicely with schedulers and application orchestrators, including Mesos. The idea there is to enable the orchestrator to manage processes dynamically, rather than assuming the steady state defined by the resource loop template.
Azure program manager Alan Stephenson showed a graphic demo of Batch, perhaps the temporary name for a future Azure feature that uses API calls (as opposed to a template text file) to spin single-core VMs. He said the VMs were only single-core for purposes of the demo; they could easily have been multithreaded, perhaps 8-core.
He then showed a screenshot of a test of Batch at the Redmond labs, where some 16,000 VMs were spun through a single set of API calls. Attendees were not, admittedly, very astonished; it is not clear yet, from attendees I’ve spoken with and listened to thus far, that they know exactly what microservices are or what the purpose of the architecture actually is.
That observation has candidly been confirmed by Microsoft officials, telling me that the questions they’ve received have been quite elementary.
At this early morning session, one developer who produces cloud-based applications for multiple clients was concerned that the resources being run for one client may not be able to reference resources for another client — groups that were being separated between resource loop VNETs. His fears were allayed — cross-referencing like this will be possible — but the questioner was also concerned about whether services written for the old resource loop model will translate easily to the new Scale Sets model.
Today, the answer is no. But a Microsoft engineer in the audience came forward to say that a transition tool is presently in the works, with the release date for now “coming soon.”
[Author’s Note: I regret having mistyped Guy Bowerman’s name as “Gary” during my initial write-up. My apologies to Guy for this error.]
Feature image via Flickr Creative Commons.