I think that introducing additional abstraction/complexity is worthwhile only when its (abstraction) complexity is less than the complexity of the problem it solves.

Coming from a SysAdmin background and dealing with software developers that then think of themselves as equally competent SysAdmins because of things like k8s; it's very easy to see the reasons why simple things become overly complex and costly because the wrong tool and skillset are trying to be forced to work to fix a problem. All of the additional requirements that Kelsey starts laying out can be still be easily solved, even without k8s. Wisdom is knowing when to grow into a tool organically and not hinder or force yourself from/into making that transition. Lastly, always incorporate having a means of getting metrics and performance data no matter what solution is created or used; so that when management and customers start yammering on about needing to scale up to be the next Amazon but they're just a bicycle repair shop in a small town, you'll have quantitative data to give them as to why their "needs" of "twenty-seven 9s of uptime" and "geolocated on 6 continents" is ridiculous.

I like that almost everything I do is HPC type stuff. We just use something like PBS to submit jobs and have them run.

Kelsey is such a good teacher and demo-er. Always time to learn from him even when I don’t need high level of k8

Kubernetes is complex if the only abstraction you're dealing with is raw YAML manifests... or if you skip that step to go full Kustomize and GitOps. There is a sweet spot in between.

Mr. Hightower's point about vim vs. emacs and tabs vs. spaces is a valid one. It's also broadly applicable, whether it be about software engineering, politics, or sports teams.

I agree with not adding unnecessary complexity upfront, but it is true that the job market will be looking for people that understand the tools, so engineers need to learn some of them anyway

Good to see that Dave, like me, is also subject to being a bit curmudgeonly at times, and a great reminder from Kelsey that not all complexity is accidental or unnecessary. Tools like k8s solve very real problems, and for many organisations the learning curve is well worthwhile to help support requirements that are now considered basic table stakes in modern software.

Surely "serverless" tools are actually using Kubernetes or Borg under the hood? i.e. They are just wrappers over Kubernetes and their ilk, that allow developers to use Kubernetes without knowing the knowing they are using Kubernetes. I wish this question was asked an answered during this interview....

"The open, accessible web should be built upon endless build systems, virtual environments, full test coverage and endless gatekeepers." - Sir Tim Berners Lee

Isn’t this like a year or something old?

To the question: Is Kubernetes suitable for developers to build anything and everything? Why do software developers have the tendency to be all or nothing over their tools and practices? NO! Kubernetes is a new highly automated infrastructure layer automating and managing container runtime. To build Kubernetes onprem is a quite high invest to do at scale and manage lifecycle. It is a CaaS Layer on top of Infra/IaaS. Developers should care about to implement their business / user requirements coding using TDD to ensure integrity and correctness of their applications. Kubernetes, when using it, needs additional layers (with even additional complexity) on top, to satisfy developers. The k8 API has not a good contract between platform and developers because a developer needs to care about too many things infra related. Kubernetes is an option for many workloads and there are also good reasons to run workloads on top of k8.

no