Should We Build EVERYTHING In Kubernetes? | Kelsey Hightower
Vložit
- čas přidán 22. 06. 2024
- 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?
In this clip, Kelsey Hightower & Dave talk Kubernetes, software engineering more broadly and MORE.
You can listen to the full podcast HERE ➡️ open.spotify.com/episode/6dYb...
-
🗣️ THE ENGINEERING ROOM PODCAST:
Apple - apple.co/43s2e0h
Spotify - spoti.fi/3VqZVIV
Amazon - amzn.to/43nkkRl
Audible - bit.ly/TERaudible
-
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
-
#softwareengineer #developer #kubernetes - Věda a technologie
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.
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.
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
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?
Yeah, it's a clip from an older episode.
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.
Where would a developer not need to worry about infrastructure? If you move up the managed service scale to cloudrun there is less, but if you're going to VMs there is more. Perhaps you have a separate infra team from development team, so devs don't do any infra, well that pattern works pretty well with kubernetes too. With a platform team managing the platform, CD portion of the delivery pipeline, helm charts etc, and the developer handling the development and CI portions, and picking if the service needs to be internal/external and its names.
no