New Era of Open Source
In the 2010s, open-source was driven mainly by startups as a strategy to build a viable business, which led to companies like Red Hat, CloudBees, Elastic, & Mongo.
It was also painfully clear in KubeCon that the forces that shaped the landscape of open-source has changed completely. Today, open-source is primarily driven by unicorn end user companies who needed to solve problems that vendors didnâ€™t even knew existed. Thatâ€™s where innovations are. And they donâ€™t need to make any money from those projects unlike startups. Substantive projects highlighted in KubeCon were from companies like Uber, Lyft, and Spotify. Sessions by engineers from those companies were packed. Everyone wants to be like them, no wonder their projects are popular.
The other kind of open-source projects are from vendors. They are either Hail Mary gamble moves out of desperation (e.g., IBMâ€™s razee), or torpedos designed to drag down the market leaders through indirection or commoditization.
I still saw plenty of startups who are trying to repeat the single vendor open-source model of the 2000s, but the going will be really tough for them. First, they have to find problems that arenâ€™t already solved by unicorn end users. Then they have to cross the sea where 3 cloud titans are shooting torpedos to each other and random Hail Mary are shot into from the sidelines. Really the only sensible move is SaaS.
3 Cloud Titans
Speaking of 3 cloud titans, Microsoft won my respect once again with their SMI announcement. Along with KEDA, together they clearly show the Microsoft OSS strategy of making sure innovations in the Kubernetes ecosystem get contained behind the common portable interface/spec. Then Microsoft can â€œembrace and extendâ€ or build their proprietary implementation nicely integrated with the rest of Azure. This is the exact same play IBM, BEA, Oracle, etc. have done with JavaEE. Use JCP to create portable APIs, let Sun implement the free tier, and focus on building the for-pay value-add tier. The move makes sense, and it works because end users share the same interest.
I didnâ€™t see Amazon, but I assume they are making sure that EKS is good and otherwise doing the bare minimum in the Kubernetes ecosystem. That way, they can focus on building up their own services, like Microsoft.
What made me wondering is Googleâ€™s plan. Maybe itâ€™s just that they didnâ€™t get the air time they deserve in KubeCon, but it felt like they are going down the route Sun did. They seem to be busy building awesome commons that benefits everyone, which wins tremendous developer love, but no $$$. Iâ€™m sure GKE is the best managed Kubernetes service right now, but it is a thin value layer that requires constant upkeep.
Itâ€™s a tragedy that it takes a truly selfless act of engineering brilliance to create a great developer platform, like Sun and Google, yet the inventing company itself never financially gains from the innovation. But then maybe thatâ€™s why they gain so much respect and fame. I truly love those companies.
End Users Need Industry Standard
It was also very clear that app developers are overwhelmed with choices and chaos of the ecosystem. It was proclaimed, as if thatâ€™s what people want, that â€œKubernetes is a platform to create platforms.â€ Well, most people there are writing apps, not creating a platform. The last thing they want is to pick & choose their own cloud native platform out of 100+ CNCF ecosystem software just so that they can write apps. I wonder who solves this problem for them. That gotta be the biggest opportunity.
I noticed that quite a few consultancy shops were there posing as Kubernetes experts, claiming to solve that problem on behalf of the customers, but I question how much they know themselves.
Jenkins X is clearly in the right spot, with this regard. Its code and governance are growing at a breakneck speed thanks to the Jenkins X community and the CDF, but the market is growing faster.
My money is on Microsoft, Red Hat, and end user companies to come up with JavaEE/WS-I/WHATWG-esque â€œstandardâ€ body that defines a set of the common APIs, like SMI and KEDA. This will include the space Jenkins X is in, so it will have a role to play, too. That way, end users get to avoid lock-in, cloud providers get to provide implementations specific to their cloud and compete with value-add. It will be like the LAMP stack of the cloud native.
KubeCon is worth a visit. HistoryÂ is repeating itself. Open-source is thriving, though the rules have changed.