| All my mentions of issues or friction in my previous comment was about pre-k8s team's experiences... I try and clarify a few key cases in the following: > Successful utilization of k8s, interesting metric, what is your criteria ? Sorry, what pain motivated using k8s, and using k8s relieved that pain. > I have seen properly staffed startups (in silicon valley) What is 'proper' for staffing? >> Are your SRE shipping the new features, or running like a red queen to keep the product developers able to keep shipping?
> Yes to both Is it the appropriate use of a Reliability engineer's skills to develop or change arbitrary features? Or are you saying they are at least Engineers so they should be able to pitch in everywhere... CSS accessibility features or k8s config. >> What development process or cycle has overheated with friction that requires k8s?
> Upgrading k8s :) This tautology keeps me away from k8s. Before k8s what pain in the process required using k8s to solve? > a pipeline getting product to production fast Does k8s make it fast? Does k8s make it possible? I think I'm deploying "fast", without k8s... But because you keep mentioning ITIL I suppose it's more about the infrastructure changes? Or are you talking about ITIL tension because k8s requires a more liberal policy than ITIL allows? There is so much assumed context when talking about k8s, the only comprehensible part of these discussions is k8s is a rabbit hole to end all rabbit holes. |