I spent an amazing few days with others in the Kubernetes community last week in Seattle for the second Kubecon. The experience renewed the enthusiasm that led me to co-found the Cluster Ops SIG earlier this year.
Both events were about the same size and project age. Both were marked with tremendous optimism for the project and community. Both were also the start emergence of an eager vendor community. That does not mean that Kubernetes is following in OpenStack footsteps. The projects have very different governance plans and community cultures; however, I’m concerned about that the same type of vendor pressures that have hampered OpenStack will influence this project.
It’s impossible to write platforms without some “we’re changing the f-ing world” hubris; however, the I see a community that knows the ride is bumpy and requires human interactions to succeed.
Vendors are not bad for projects! In fact, they are essential for its success. I believe strongly that shared open source projects must ensure that vendors can fairly profit. The challenge is finding the right balance and incentives. With that in mind, I’m offering four “keep doing” and four “cautions” for the project.
1. Focus on a Tight Core: Having a well-defined and limited boundary for Kubernetes ensures that the project can control its scope. This allows the community to extend and enrich the platform in interesting ways without having the project blocking innovative exploration.
2. Build a Diverse Community: So far, Kubernetes has done a good job bringing a lot of different groups to the table. We’re hearing from early adopters, innovative start-ups, pivoting PaaS solutions and major vendors. That’s a lot of voices making the project stronger.
3. Multi-cloud and Hybrid: Kubernetes strength is that it’s not infrastructure limited. The community is intent on completing the work to decouple Amazon Web Services and Google Cloud Platform integrations and make it even more easy to port.
4. Be Humble and Honest: The community does a good job of being self-critical and people-first in interactions. It’s impossible to write platforms without some “we’re changing the f-ing world” hubris; however, the I see a community that knows the ride is bumpy and requires human interactions to succeed.
1. Avoid “The One Ring” Universal Solution Hubris: While Kubernetes is a great platform, it’s not going to be the right solution for every problem. The project will grow fastest when we target on applications that fit the platform and push back against adapting to mismatched requirements.
2. Avoid Over Vendoring: Well-funded vendors help pay for events, build momentum and customer exposure but they are generally risk averse and hype driven. The start-ups and end-users have more at stake in project success. They are the ones building the pushing the edges and need help to rise above the noise.
I have a very specific recommendation here: Kubernetes should provide some marketing guidelines that limit how vendors describe their products. We must avoid runaway forward promotion (like in OpenStack) that creates a vendor hype feedback loop.
3. Decouple Installers, Brokers and Providers: These extensions are generally vendor or platform specific so it makes sense to keep these adjacencies out of core. I believe we should encourage variation in the ecosystem and then extract emergent patterns. Some of these extensions will be proprietary and that’s healthy and normal.
4. Eschew Fast Release Cycles. Moving to a quarterly release is great for a quickly evolving project to ingest innovative ideas. Unfortunately, it’s also harder for user and operators to absorb platforms that are changing so quickly. Kubernetes will need to ensure backward compatibility for APIs and provide long-term support for select releases. I’m encouraged that the next release will focus on stabilization.
I’m excited by what I’ve seen so far. I hope these observations help people just coming into the project better understand the shifting dynamics of the project for 2017.
Feature image via Pixabay.