Using Continuous Deployment to Drive Azure Footprint

About a month ago, Microsoft acquired Github for $7.5B, with the clear goal of driving developer engagement and beginning the long path towards rebuilding its relationship with a new generation of developers. While I appreciated Ben's perspective, I think that there remains another vector for growth that was conspicuously missing from his initial post: leveraging the Github developer base to tilt the scale away from AWS towards Azure for new projects and companies.

Building a new software company in 2018 involves a number of concrete engineering decisions that happen early on in company formation:

• Where should we host our code to begin development?
• Which frontend platform / language should we use (iOS, Android, Web, Native Desktop)?
• Which baseline services (databases, authentication providers, analytics, payment processing) should we orient around?
• Which cloud provider should we run everything on?

Historically, Microsoft had strong moat-enforcing solutions for every one of these questions; more recently, their solutions have been subject to increasing competition from third-party competitors. Additionally, as interoperability at the service layer (Microsoft's traditional strength) has increased competition and lowering the barrier for individual companies to build deep offerings in a specific segment of the service space (e.g. Okta in Auth), it seems like the critical question for Microsoft has to be how to drive organic Azure growth.

On the surface, building a new product or company is easier than ever - make an organization in Github, create a couple repositories (or one, looking at you monorepo folks) for your application and backend persistence layer, write some code, build a container and deploy it to AWS.

In practice, the actualization of this process remains a serious challenge to manage. Especially during the growth phase of a new company, maintaining quality and velocity is a non-trivial challenges. Writing and running tests, drafting and approving releases, phased deployment, zero-downtime schema migrations, and beta-testing new versions of a product is still a dark art that requires patching together a wide set of open-source and proprietary toolchains. 

Enter Github and Azure. The Github acquisition is the best opportunity for Microsoft to intercept new projects and companies before they release their first version to production, changing the default assumption. Almost definitionally, companies start writing code in Github before they start renting servers on AWS. As such, Github offers a brilliant wedge into the earliest phase off company formation, the largest existential threat facing Azure.

With a relatively simple toolchain for continuous deployment (augmented by a targeted M&A buying spree), I suspect that Microsoft should be able to convince Github developers that Azure is the best place to run their tests, compile their software, build their containers, and, most critically, deploy their applications to production on Azure.

This shift would be a total revitalization of Microsoft's cloud infrastructure, and would shift the balance of power between the cloud companies and heighten competition between the two behemoths in Washington. Also, as an engineer myself, I'm excited to see what a company who has focused so much on developers for the vast percentage of its history might do to the modern world of building incredibly complex cloud-based applications. Indeed, while I'm not making any bets on this path, winning developers in the cloud might also offer the best path towards reclaiming developers on Windows, thus extending and deepening the Windows moat by allowing native OS-level integration with Azure-based build systems and test infrastructure to reduce the burden on a local workstation.