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.
What I've learned from the comments above is k8s consulting business is the best thing since OOP. Just tell the marketing team you have a magic button that being installed will give them ability to change the course of business every 5 minutes by handwaving and a PowerPoint slide.
>Sorry, what pain motivated using k8s, and using k8s relieved that pain.
CTO / CIO / $SOME_C reads a blog and decides they want k8s is how it usually is introduced
> What is 'proper' for staffing?
Experienced C Developers who can do operations ( like google level SRE )
Summary of k8s : if you use the proper methodology to implement k8s and you are in a cloud framework you likely dont need k8s :)
What shines about k8s is it leverages the current container fad to ship code faster because devs like it. The current container fad pushes the burden of supporting buggy code to operations teams. IF the operations teams have issues they had better be highly skilled to figure them out
I have yet to see a company let requirements drive the choice to use k8s.
> 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.