You still have to debug things in a cattle approach, though. If anything there’s even more and more complex things to debug.
I would disagree on your complexity metric (for the purposes of learning troubleshooting) for cattle. What can be more complex than a completely unique system that only exist because of 10+ years of running on that same hardware with multiple in-place OS upgrade occurring along with sporadic (but not complete) patches to both the OS and the application? Throw in the extra complexity of 9 other unrelated applications running on that same server (or possibly bare metal) because the org was too cheap to spring for separate servers or OS licenses for a whole hypervisor.
If you have a memory leak in your application in a container running on k8s that will kill the pod after running for 72 consecutive hours, would you even notice it if you have multiple pods running it on a whole cluster as long as the namespace is still available?
I’ve maintained both and still do. While you may not be debugging memory leaks on k8s (although you should), you get all sorts of other fun things to debug. Things like:
Why did our AWS bills suddenly triple?
Why is that node accepting jobs but just hanging when they start?
Why is that statefulset not coming back up? Is the storage still attached somewhere else perhaps?
Why did all the data in our Kafka suddenly disappear?
Why is everything still down after that outage? Maybe a circular dependency, thundering herd problem, or both?
What’s wrong with my Helm chart this time?
The list goes on and on. With increased complexity you don’t get less problems, just different ones.
And nearly all of those problems are ones that other people have run into or at least have guidance on how to go about addressing. Old organically grown systems are many times unique one-offs which have little to no established path except to start diving into the fundamentals about the hardware and software.
I’m not here to get into a pissing match about who’s job is/was harder. If you think juniors have a better chance at learning on today’s systems than they did in the past, I still disagree with you. Problems exist on modern system, except juniors will rarely if ever get a chance to try to solve them and thereby learn from them.
I’m starting to think we’re talking past each other. Your last paragraph seems to imply that legacy systems were more approachable for a newbie to debug. If that’s your point I wholeheartedly agree. It’s not that hard as long as you get over the fear of fucking something up.
I do agree that juniors had an easier time learning on legacy systems, and that’s been true since the dawn of technology. Things get more complicated, and thus harder to get a deep understanding of, the more time passes. It’s a lot easier to understand older and simpler technology.
I’m a little confused why you seem to be arguing both that the issues I mentioned are easy to google, while at the same time saying newbies never get a chance to debug them. Surely, if it’s so easy, the newbie can take a stab at it?
Personally, I like to let the newbies have a stab at non-urgent issues first, and nudging them if they get stuck. They may not be able to solve the problem solo, but they know a lot more about how the system works afterwards anyway.
I think we have slightly different approaches but ultimate want the same thing: opportunities for juniors to get exposure.
However, employers these days are reluctant to hire them, and the barrier to entry is higher now so they can’t necessarily get in the door on their own merits without that experience they don’t have access to learn.
I would disagree on your complexity metric (for the purposes of learning troubleshooting) for cattle. What can be more complex than a completely unique system that only exist because of 10+ years of running on that same hardware with multiple in-place OS upgrade occurring along with sporadic (but not complete) patches to both the OS and the application? Throw in the extra complexity of 9 other unrelated applications running on that same server (or possibly bare metal) because the org was too cheap to spring for separate servers or OS licenses for a whole hypervisor.
If you have a memory leak in your application in a container running on k8s that will kill the pod after running for 72 consecutive hours, would you even notice it if you have multiple pods running it on a whole cluster as long as the namespace is still available?
I’ve maintained both and still do. While you may not be debugging memory leaks on k8s (although you should), you get all sorts of other fun things to debug. Things like:
The list goes on and on. With increased complexity you don’t get less problems, just different ones.
And nearly all of those problems are ones that other people have run into or at least have guidance on how to go about addressing. Old organically grown systems are many times unique one-offs which have little to no established path except to start diving into the fundamentals about the hardware and software.
I’m not here to get into a pissing match about who’s job is/was harder. If you think juniors have a better chance at learning on today’s systems than they did in the past, I still disagree with you. Problems exist on modern system, except juniors will rarely if ever get a chance to try to solve them and thereby learn from them.
I’m starting to think we’re talking past each other. Your last paragraph seems to imply that legacy systems were more approachable for a newbie to debug. If that’s your point I wholeheartedly agree. It’s not that hard as long as you get over the fear of fucking something up.
I do agree that juniors had an easier time learning on legacy systems, and that’s been true since the dawn of technology. Things get more complicated, and thus harder to get a deep understanding of, the more time passes. It’s a lot easier to understand older and simpler technology.
I’m a little confused why you seem to be arguing both that the issues I mentioned are easy to google, while at the same time saying newbies never get a chance to debug them. Surely, if it’s so easy, the newbie can take a stab at it?
Personally, I like to let the newbies have a stab at non-urgent issues first, and nudging them if they get stuck. They may not be able to solve the problem solo, but they know a lot more about how the system works afterwards anyway.
I think we have slightly different approaches but ultimate want the same thing: opportunities for juniors to get exposure.
However, employers these days are reluctant to hire them, and the barrier to entry is higher now so they can’t necessarily get in the door on their own merits without that experience they don’t have access to learn.