X
Innovation

Developers, developers, developers: For Microsoft the tune might change but the words remain the same

Back-to-back events reveal Microsoft's developer strategy for the next few years.
Written by Simon Bisson, Contributor
developer-programmer-thumb.jpg
Microsoft shows developers just how they are important they are to its long-term strategies.
Image: Corepics VOF/iStock
Microsoft has always been a developer-focused company, but its recent BUILD and Ignite events showed just how important developers - and IT pros - are to the company's strategy.

It's a strategy that's always adapted to how developers work, but now, instead of following them, it's anticipating where they're going, aiming to deliver the tools that they're going to need tomorrow.

If that means working with node.js in Docker containers, by providing a programmer's editor for MacOS and for Linux, and by supporting iOS in traditionally Windows tooling, well, that's what it takes. Microsoft is rebuilding its developer story from the ground up, retuning for a new generation of coders both in and outside the enterprise.

You only had to watch the BUILD Day One keynote to see the shape of Microsoft's development platform. Instead of starting with Windows, as in PDCs of old, it started the way developers look at modern applications, as services in the cloud. Starting with Azure, the keynote took a whistlestop tour through the layers of a modern app, ending up with tomorrow's UI in the shape of HoloLens. As a keynote, it may not have had the consumer edge that some were looking for, but for its developer audience it showed the shape of a changing Microsoft that they could work with.

Microsoft is now a full stack company.

That change is a big one, but it's also one that takes Microsoft back to its roots. 'Cloud first and mobile first' are developer aspirations; they're statements about how developers think about code and about where today's (and tomorrow's) apps will live.

What Microsoft is focusing on now is its stack, the tools and technologies that go together to build apps. That stack starts in the cloud with Azure and Nano Server, moves into the data center with Azure Stack and Windows Server 2016, and on to users' devices with Windows Universal Applications and the new Windows Store bridge technologies for iOS and for Android - all of it held together by Visual Studio and Visual Studio Online.

With sessions at BUILD on containers, and at Ignite on APIs, the cross-over between Microsoft's developer and IT professional constituencies is getting bigger. Talking to senior folk in the Azure team, it's clear that Microsoft is well down the internal journey of treating everything as code; now it's time to take that model to its customers.

Nano Server is a particular example of this, offering a completely UI-less server that can only be managed using remote management tooling. Want a Nano Server running node.js? You'll build a set of Desired State Configuration PowerShell scripts that configure a deployed VM with all the pre-requisites before downloading and running server software and then deploying an application from Github.

With two container models in Windows-hosted Docker containers and in Hyper-V containers, the next generation of Windows Server is ready for the next stage of the DevOps movement: immutable containers. If VMs virtualize infrastructure with virtualized compute, storage, and networking, then containers add a new abstraction, virtualizing and isolating applications. That means we can make a container the output of a build process, wrapping an application and all its components and services in one single, easy to deploy, unit.

Using an immutable container, a new build means a new container. To deploy, we throw away the encapsulated application and roll out a new one, touching all the servers in a distributed architecture. In fact, using a software defined architecture we can build and deploy new VMs for our application containers, while the old version continues to run - just switching DNS to the new version when it's ready (and keeping the old infrastructure on standby inn case of problems).

Microsoft's 2016 stack is more than just servers and dev tools, it's also Microsoft's platform. One aspect is Azure's growing selection of platform-as-a-service tools and features. Perhaps the most significant element is Azure's machine learning tooling, which builds on Microsoft Research concepts. You might not be wanting to build a recommendation engine, but you may well need to identify out-of-bounds readings from Internet of Things sensors.

That's where Microsoft's platform tools come into play, with Azure services that manage event streams, handle stream analytics (and display results in tools that let you explore the data), as well as machine learning to help identify significant results. It's an interesting combination that goes beyond the pure cloud analytics model, providing APIs that can plug service results into your applications.

One place Microsoft's stack takes an interesting turn was highlighted at Ignite, with the extension of its Office Graph contextual search tools into the Office 365 APIs. Microsoft's ambition is to host all your corporate data, and the Office Graph builds on that data to extract information. In the past that would have needed proprietary apps - but now it's a RESTful API, that lets you quickly identify users, groups, and the documents they've got permissions to use.

Microsoft knows it can't be all things to all people. That's why it's going where the developers are, into a world of microservices and containers, of RESTful APIs and devops, of mobile and of cloud. It's not an easy transition for Redmond, and not an easy one for its users, either. Moves made to attract developers who aren't traditional Microsoft developers are seen as abandoning platforms - as users forget that for Microsoft devices and operating systems are only part of a full stack platform: Microsoft itself.

BUILD and Ignite were showcases for that new Microsoft, for that new platform. Now all that's needed is for developers to start building on it.

Further reading

Editorial standards