I worked pretty heavily with Docker and K8s at my last job, and while I like them, I'm semi-skeptical of them. I think for certain classes of systems, K8s is a great technology that gives you lots of really useful things, like auto-scaling and the self-healing "oh, your pod crashed, I'll restart it" feature.
I also believe strongly that below a certain scale, you should not build and manage your own K8s clusters. If you're hosting on AWS, Azure, or GCP, I think you're better off using the provider's own managed Kubernetes service, even if you end up accepting that this may tie you to a specific version or potentially lead to minor vendor lock-in. It's too easy to go down a rabbit hole of ever-shifting cluster setup scripts and application breakage leading to spending a lot of time fixing that instead of focusing on what you're actually building.
K8s aside though, I'm a big fan of Docker and containerization technologies. Being able to make a process repeatable and eliminate whole classes of "worked on my machine" issues is great.
Over time Kubernetes will become just another API for deploying applications and will require the same level of administration as the EC2 hypervisors — none, your provider will own the cluster layer, it will disappear, and only the Kubernetes API will remain. twitter.com/PaulDJohnston/…
17:09 PM - 11 Feb 2020
Paul Johnston - @home / looking for next thing
@PaulDJohnston
The number of CTOs that privately tell me that the use of Kubernetes is entirely connected to the ability to "move to another cloud" is huge.
The number of CTOs that tell me "the likelihood of moving to another cloud is nil" is pretty much the same.
So... why Kubernetes?
214
935
"Managed k8s" today isn't where Kelsey predicts here, but I think his intuition on this holds. Remember that most of our competitive advantage in this business is from distinguishing "core" versus "context". Managed database services like RDS are successful because everything below the DB app level is "context." In the future Kelsey is predicting here, writing the podspec or deployment spec can be "core", but much of the control plane config in k8s will be "context" for many shops. Offloading it to EKS/GKE/AKS makes as much sense as offloading DBA tasks to RDS.
Having said that, RDS didn't wipe out the "roll your own"/"on-prem" set, so my guess is that both with remain for k8s as well.
That's interesting, I hadn't seen that tweet from Kelsey, thanks :)
I agree with your take here, and I like the core vs context framing here; I know the idea has been around for a while, but I first saw it articulated by Gene Kim in The Unicorn Project last year and it resonated with me - probably because I spent a lot of time working on context because of broken cluster init scripts. ;)
but I first saw it articulated by Gene Kim in The Unicorn Project last year and it resonated with me
Exactly where I first saw it too. To be honest, I've been working my way through everything he's ever written. Books you may like and have probably already read:
Shape Up: Stop Running in Circles and Ship Work that Matters, by Ryan Singer
An Elegant Puzzle by Will Larson
Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim
I've heard of all of them, but haven't read them yet. An Elegant Puzzle, in particular, is on my list to check out. I'm not sure engineering management is where I want to go, but having some grounding in it should be helpful and I've found other books on the topic to be relevant even from a senior/lead developer perspective.
Have you by any chance read Camille Fournier's The Manager's Path? Well written and relevant even at the individual contributor level; I should read through it again soon.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I worked pretty heavily with Docker and K8s at my last job, and while I like them, I'm semi-skeptical of them. I think for certain classes of systems, K8s is a great technology that gives you lots of really useful things, like auto-scaling and the self-healing "oh, your pod crashed, I'll restart it" feature.
I also believe strongly that below a certain scale, you should not build and manage your own K8s clusters. If you're hosting on AWS, Azure, or GCP, I think you're better off using the provider's own managed Kubernetes service, even if you end up accepting that this may tie you to a specific version or potentially lead to minor vendor lock-in. It's too easy to go down a rabbit hole of ever-shifting cluster setup scripts and application breakage leading to spending a lot of time fixing that instead of focusing on what you're actually building.
K8s aside though, I'm a big fan of Docker and containerization technologies. Being able to make a process repeatable and eliminate whole classes of "worked on my machine" issues is great.
Kelsey Hightower agrees with you:
"Managed k8s" today isn't where Kelsey predicts here, but I think his intuition on this holds. Remember that most of our competitive advantage in this business is from distinguishing "core" versus "context". Managed database services like RDS are successful because everything below the DB app level is "context." In the future Kelsey is predicting here, writing the podspec or deployment spec can be "core", but much of the control plane config in k8s will be "context" for many shops. Offloading it to EKS/GKE/AKS makes as much sense as offloading DBA tasks to RDS.
Having said that, RDS didn't wipe out the "roll your own"/"on-prem" set, so my guess is that both with remain for k8s as well.
That's interesting, I hadn't seen that tweet from Kelsey, thanks :)
I agree with your take here, and I like the core vs context framing here; I know the idea has been around for a while, but I first saw it articulated by Gene Kim in The Unicorn Project last year and it resonated with me - probably because I spent a lot of time working on context because of broken cluster init scripts. ;)
Exactly where I first saw it too. To be honest, I've been working my way through everything he's ever written. Books you may like and have probably already read:
I've heard of all of them, but haven't read them yet. An Elegant Puzzle, in particular, is on my list to check out. I'm not sure engineering management is where I want to go, but having some grounding in it should be helpful and I've found other books on the topic to be relevant even from a senior/lead developer perspective.
Have you by any chance read Camille Fournier's The Manager's Path? Well written and relevant even at the individual contributor level; I should read through it again soon.