Given some recent comments by Jason Zander, Microsoft’s executive vce president for Azure, it’s worth repeating: If you have a choice to make between superior technology and superior community, take the community option. Every. Single. Time. While tech supremacy is somewhat subjective, it’s nearly always fleeting in the face of community development.
Yet that is precisely what Microsoft is doing with Azure Kubernetes Service.
Zander is no dummy. As the person responsible for Azure, he’s helping spark a renaissance in that business that sees an ever-growing horde of developers build applications there.
With all the good he’s doing for developers, I should probably give him a pass on comments he made at Microsoft’s Future Decoded conference in London recently. But I won’t, given that it reflects a persistent myth worth addressing.
Zander was doing fine until he started touting Azure Service Fabric, a Microsoft-developed container orchestration solution that rivals Google’s Kubernetes: “They are both first-class solutions," he allowed,” but some first-class solutions are more first-class than others, it seems. He continued,
If you're looking for a container orchestrator, especially if you want the integration with the open source community, Kubernetes is an awesome solution for that. What we've tried to do with AKS [Azure Kubernetes Service] is to make that first-class, we'll do the management for that.
Service Fabric provides the same container orchestration work but also provides a lot more advanced services on top of that. That includes things like state, highly available state, programming models around that, reactor—it has all of those things built in.
I do expect the Kubernetes ecosystem will catch up and build some of that other functionality. To be honest, they are still about two or three years behind the functionality that Service Fabric has today.
To be clear, both are open source. And yet Zander seems to throw faint praise to Kubernetes: “If you’re into open source community,” he basically says, “Kubernetes is great. But if you want stuff that community is years away from developing, Service Fabric is your answer.”
Except that it’s not. I’ve seen this too many times: Superior community alwaysbeats superior tech. Always. Why? Because as individual members of the community begin to realize there’s more to be gained by pitching in on a communal project rather than reinventing wheels—however technically superior they may be—that collaborative innovation picks up pace and runs over that individual bit of brilliance.
“Well, surely the same community could commit to Azure Service Fabric. It’s open source, right?” True, but the community has already voted for Kubernetes, and this after years of deliberating among Docker, Apache Mesos, and more. Kubernetes won. As a recent Digital Ocean developer survey found, by far the number one thing enterprises look for when adopting open source software is “technology that is widely adopted” (according to 63 percent of respondents).
Kubernetes is widely adopted. Azure Service Fabric is not. End of argument.
So, the right question for Microsoft is: Why keep running this solo effort, diverting resources from the winning team? Why not take all those “advanced services” and build them for Kubernetes? It’s not an act of charity; it’s pure self-interest. By so doing, Microsoft would build up credibility and influence in the Kubernetes community, making it a big player instead of the bit player it is today (after Google and Red Hat, the two dominant contributors to Kubernetes).
Microsoft is a smart company, and increasingly savvy about open source. It should know better than to try to fork the container orchestration community in this way.