Q&amp;A for <@U043L23CJQH> - thank you for providi...
# platform-stories
d
Q&A for @Reynis Vazquez-Guzman - thank you for providing insides on our internal Kubernetes-based app platform. We currently have made very similar findings with regard to the level of interface users expect from an application platform. In the beginning of your talk you introduced the technical vehicles you utilized to build your initial "version" of the platform (Mustache, Kustomize together with a set of templates etc.). Are you able to share a few insights on how or really if this tools has changed for the more shallow interfaced version you are currently running? Was it really a tooling problem on your side or more the way how to use these tools (e.g. providing sensible defaults and therefore reducing the number of necessary inputs on the user side). I would really appreciate a few insides on how the takeaways and migration of the platform interface to a more shallow variant influenced your tooling landscape.
r
Hey Daniel, great question! I think it was a bit of both tooling and how we used the tooling. The fact that we pulled together multiple tools and then added a lot of our own custom templating on top of it made it slower to iterate on the system we built which in turn made it harder to change how we used the tooling and the processes in place. We are currently in the process of moving to helm to replace this more custom template setup. Part of the reason is because helm is better known/more industry standard/easier to look up documentation but a huge part of the focus on moving to helm is also changing the processes around our templating. For example, we are establishing guidelines for creating charts, including making sure every input field has a default, trying to minimize any schema-breaking changes. Another thing we’re focusing on is what do the application developers need to see (i.e. the chart users) vs what do the platform developers need to see (i.e. the chart creators). In our old system, the final kubernetes manifests are generated in the same repo as the application developers’s inputs to k8s resources and their application code, which generated a lot of noise in their PRs so we’re rethinking this as well.
d
@Reynis Vazquez-Guzman valuable insights! Thank you very much for taking the time to answer my question! We are also on the way to provide some platform capabilities on top of Helm. I think it is totally doable but as you also described it is sometimes hard to find the right layer of abstraction without blocking all means for user flexibility.