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.
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.