This year I have been working on the ConfigSync project at Google. The concept of syncing a git repository for a Kubernetes cluster has been around forever, for instance git-sync v2.0 was published in 2016 . What is the draw of using git as the source of truth while it often is a mirror of what’s in the cluster? There are some obvious reasons like sharing some common code and preserving versions. Today, I’d like to focus on the data ownership aspect of Git and Kubernetes combination, which is one of the most powerful features of Kubernetes and should be considered by platform designers in the future. First key thing about Kubernetes is the Kubernetes Resource Model (KRM) which is described here . While under the hood JSON or YAML gets sent over the wire to the cluster, the API style is very different than a most REST APIs which expect you to have a sequence of calls. The focus of KRM is the final desired state which gets sent or retrieved from the cluster. There are multiple com
When drafting a product roadmap, the tension between the vision and the specific customers often comes into play. Founders and product leaders love to talk about the grand vision and seeing the future from the beginning. From my experience the grand vision was a product of analysis of many individual customers. I have seen many failed product teams who were afraid to focus on any specific customer. They didn’t want to overoptimize the product for too small of a customer base and become a consulting company. It is true that there is a danger where one large customer is hijacking your roadmap and you start getting so deep into features or special built integrations that you fail to build a mass market product. More often the “visionary” product has no grounding. The teams that can’t waste their time digging deep with their early adopters miss the opportunity and never build anything useful for anyone. When we launched DocuSign API , we had 3 (three) customers who had access to a pr