This is part of a blog post series based on my observations 3 months into my new role at Pivotal.
As PKS moves from toddler (v1.0) into early energetic childhood (v1.1, K8s 1.10) one topic that we’ve been discussing internally as well as with customers is the topic of community contributions, participation in key SIGs.
Let me make two statements in black and white terms:
- I think that Pivotal and VMware can, should, and will make more contributions to the K8s Open Source Software (OSS) community and active participation to the Special Interest Groups (SIGs). I think we are doing more, and will keep doing more.
- We’re not hung up on it – and I certainly don’t think it’s the most important thing we can do.
Part 2 will make OSS fans start drawing me with horns on my head (remember “fan” is the abbreviation for “fanatic”):
PS: I’m not really like that 🙂
Some people in the OSS community are fanatical about OSS, almost for it’s own sake. You’ve met them. If you disagree with me, you might BE one 🙂
Don’t get me wrong, Pivotal believes in OSS. I believe in OSS. We are in the top OSS contributors list, and punch WAY above our weight.
However… In the last 3 months I’ve learnt what we do a little differently – and it’s rooted in the way we see the world.
For Pivotal, OSS is a means to an end – it’s one of the tools that we use to drive customer outcomes, it’s not an end unto itself. We are transforming the way the world builds software – and OSS is a key part in that, but just a part. I think that some people forget that in their OSS fury, and when they point at contributions as the only measure that matters (hint, it isn’t the only thing that matters).
Beyond our focus on outcomes – why do I think that the rate of Pivotal contributions to K8s, Istio and other products is IMPORTANT but not the MOST IMPORTANT thing? Well, a couple simple reasons:
- Google is the dominant contributor to these projects, and has been a very benevolent leader on the projects. This is likely rooted in the fact that they are not a vendor who sells K8s (and every time Google has tried to work on selling to the enterprise it’s been a little bumpy – I’m sure they will keep trying) – but they are geniuses at using OSS tools to deliver services. They are developer-centric, because devs are their target (internally). This means they are very open. Upstream contributions are working (at least from where I sit). Google takes a very ecosystem-friendly approach, and fights efforts to fork projects. Trying to “out contribute Google” on K8s, on Istio seems… silly.
- These projects (so far) are avoiding the early traps of “trying to do too much” (I think this was one of the traps OpenStack fell into), but instead are focusing on how intersections/API surfaces work – making K8s extensible, in a thoughful way. This will take years to work through – but pays dividends in the long haul (interesting strategic question here about whether people who’s business is solely K8s will have to twist/turn it to make it broad enough for survival).
- It’s not how we provide value in and around K8s – but how we make K8s dial tone simple, easy and enterprise-ready… and then build on top.
Let me expound a little on the last bullet. Our focus together with VMware on PKS is to build the best, Enterprise ready Kubernetes. This is harder than one thinks, and as people roll up their sleeves they find out how and why.
Don’t listen to me, look at this tweet (and if you do a little digging, you’ll see these folks know what they are talking about).
Now, when you look at the follow-up responses to the tweet (warning: which start to descend into OSS super-fandom), it highlights that YES, the community will work on this, and we will be part of that. But – it also highlights that pragmatism is important….
This the problem domain we’re tackling now – how do we solve these problems for customers, now? How do we do this openly, but also pragmatically – with out diverging from Google?
That list of considerations reads like the PKS tracker for 1.x releases. Let’s talk about just a couple of them – multi-tenancy, resource isolation, permission management…. Everytime I see a customer talking about “one big cluster”, the dialog about the K8s cluster as the tenancy and security domain starts.
Yes, the SIGs are working on improving namespaces as a security construct, but right now, if you want to get on to doing practical things – you need drop the “one big cluster” thing, and that in turn means solving the problems associated with managing fleets of K8s clusters in an enterprise. That’s something you can do with K8s NOW – but needs what we are working on in the PKS control plane, which – if we do it right, stays totally aligned with native K8s.
This is why this message from a customer on Friday was so nice – it’s our focus, our work having an impact:
“You did more today than what it took us to do in 6 weeks with vanilla, in house Kubernetes”
We focus our efforts on provide value UNDERNEATH, BESIDE, and ON TOP of Kubernetes, versus trying to “out contribute Google”.
That’s why part of our PKS core charter has “constant compatibility” (which is more than conformance) with GKE as a core tenet. We align with, and behind Google when it comes to K8s.
HINT: This is particularly important as other projects work to expand the developer-focused surfaces and other services on top of Kubernetes, like Istio/Envoy and others – more on this tomorrow.