The true measure of whether a vendor technology conference is successful in its goals is to gauge attendees’ attitudes past the halfway point.  Today at Microsoft’s Ignite conference in Chicago, the overflow seating areas for folks who could not get seats in the session rooms are still stacked full of developers.

Developers. When Ignite was launched, it was supposed to be mainly an implementers’ conference with development sessions added. 

But in the real world, developers and implementers are merging, especially with respect to the new disciplines that are evolving in the quest to build applications native to cloud platforms.

The 3 Keys Revisited

In last week’s conference preview, I brought up the three big concerns that Microsoft, as a company must address at this conference, in order for it to be considered successful in the long term. In keeping with my own history of covering these events, let’s go back over them at the midway point to see how the company is faring so far.

Can the new Windows popularize cloud applications?

When I ask the wrong question, I admit it. (Each time it happens, all eight times, I’ve confessed.)

The new Windows does not have to popularize cloud applications. If part of me wasn’t stuck in the 1990s, I would have refrained from my old role of casting Windows as the technology that leads people anywhere in particular.

Nothing more clearly drove that point home for me than attending a handful of sessions at the same venue — the Arie Crown Theater in McCormick Place. One was devoted to the added benefits of Windows 10, the others to deploying cloud applications and microservices on cloud and virtualization platforms. The Windows 10 event had the better scheduling, in terms of its ability to attract an audience.

Guess whose audience appears in the title photo in this story?

At the Windows 10 event, the presenter encouraged audience members to shout “Windows 10” at the given cues, in order to become eligible for prizes such as T-shirts and bags of gummy bears, there were still people in my immediate vicinity falling asleep. But while Jeffrey Snover demonstrated Nano Server – a technology inspired by what’s been happening on the Linux side of the pond for several weeks now – the on-topic whispers I overheard between attendees sharing facts let me know, the question I should have asked was whether cloud applications might have long enough coattails to pull Windows along for the ride.

Will Windows Server “embrace and extend” Docker or will Docker “slice and dice” Windows Server?

We’ve seen some evidence here at Ignite of Microsoft taking its classic stand. Let’s be honest: Over its long history, it is not known as an innovator but rather an aggressive implementer.

There are two types of Windows Server containers, one of which is based entirely on the standard created by and for Docker, and the other has been given Microsoft’s long-standing Hyper-V brand. And if you’ve followed Microsoft for a while, especially with the history of Internet Explorer, the pattern at first appears familiar: “Support” the standard to a limited extent, but push the alternative.

That is not what is happening here. Microsoft’s representatives don’t put too fine a point on this for obvious reasons, but the existing architecture of Windows applications is incompatible with Docker’s basic premise of running processes in isolation. You cannot containerize, for example, Exchange Server, nor will it ever be possible to do so.

The reason is a technical one, not a political one: Windows has always been a set of resources upon which applications depend. That’s the key word: depend. So Hyper-V containers were created as a way for the hypervisor to supply Windows processes running within containers, with some semblance of the dependencies they’re accustomed to.

Thumbnail image for 2015-May-Jeffrey Snover & attendee- Microsoft.jpg

Microsoft pushed this feature as a benefit: When you upgrade the underlying operating system, the dependencies are upgraded as well. No kidding: When you plant trees in the ground, and there’s an earthquake, the trees shake as well. What we do not know yet (because the technologies are still being baked as we speak) is whether both classes of container will co-exist peacefully.

This is not a question whose answer Microsoft is withholding from us. Even its engineers who work with Docker containers every day, and those who are building Nano Server, don’t know the answer yet.

Why does this matter? Because Microsoft has no choice now but to enable the new world of microservices into its ecosystem. It must embrace containerization, and this time without the quotation marks.

Just what is Microsoft’s communications plan this year?

There are two huge topics of conversation at Ignite this year, and they’re taking place on opposite sides of the convention center. Strangely, it’s a universal disdain for the quality of the food service here that has drawn developers from the Docker camp together with those in the SharePoint camp.

That’s where I caught up Thursday with Larry Somers, a principal SharePoint architect at Broadcom. Somers’ work is to integrate SharePoint functionality into the billions of communications devices endowed with Broadcom chips, or employing intellectual property from Broadcom. It’s a safe bet that every single one of the set-top boxes in service today from multi-channel video providers.

Somers told me a story about working with Microsoft in an effort to realize some of the speed gains in service calls for SharePoint hosted services. If browsers could keep track of security tokens in their local caches, Somers says, Microsoft could eliminate (using my own math) 75 percent of what he called the “chattiness” between clients and SharePoint hosts.

That chattiness is a result, he tells me, of round trips between the client and server. The way SharePoint communication works, the way an app on the browser side gets to security data stored to its local cache is by placing an API call to the server first, retrieving the 401 error, and then defaulting to the cache later.

As Somers told me, he opened up a service ticket on this issue on behalf of Broadcom, one of the world’s largest communications service providers. Two months later… he received a response from a communications support professional, which was friendly and conversational and even sympathetic. The pro even acknowledged the architectural defect.

But beyond saying Microsoft cares about its customers, it didn’t go much farther than that. This story told me worlds about the state of the company and of its customers.

On my side of the conference center, where all the back-end server folks are learning about Docker for the first time, the talk has been about how the extensive changes to Windows Server have changed the corporate culture at Microsoft. Now that Windows developers are being compelled to adopt continuous deployment and continuous maintenance.

The upshot of all that is supposed to be that major companies are not supposed to take two months to respond to customers the size of Broadcom.

That 2010s Microsoft still behaves like 1990s Microsoft for a different set of its customer base, tells me Microsoft is still structured a lot like its own new corporate logo: square, completely different colors, and partitioned.

Whatever changes Microsoft is making in developing and maintaining Windows and Windows Server have not pervaded the part of the company that develops and maintains SharePoint.

And you have to wonder why that is. At some level of the company, someone is reticent to adopt what many folks, including within the company, proclaim to be the greatest strategic and cultural shift in information technology. It suggests that someone is waiting to see whether the changes on the Windows side will be successful.

And that suggests a lack of confidence at a very high level, which may be one of the biggest takeaways from this entire show. See what you can learn from running into someone new for lunch?