Thanks for an insightful response - Don't you think that a lot of wizbang software developers just want to use latest and greatest buzzword thing, whatever that might be, to get some cool points? As I grow older, I see increasing lack of objectivity and decreasing attention to KISS principles.
Yes, absolutely, and it drives me up the wall. I've seen some incredibly unsuitable technology choices made, the complexity of which have absolutely sunk productivity on projects.
That said, it's easy to become cynical and associate anything that's become recently popular with hype-driven garbage. But that can blind you to some really great new stuff too. I tend to hang behind the very early adopters and wait to see how useful new tech becomes in the wild - the "a year with X" style blog posts tend to be really informative.
The point I'm trying to make is that people often think in absolute terms. The problem isn't thinking "React is good for SPAs" - it's thinking "React is good for all websites". I've come across a number of engineers now who genuinely think React is a good fit for e.g. totally static sites, "because it's fast".
I've come across similar persistent beliefs around NoSQL databases. Some teams wouldn't begin to consider an RDBMS for their primary data store, even while their data is heavily relational - because "SQL databases don't scale".
It's not that technologies are good or bad - it's the blind belief that a given technology is best for all situations. The hype drives the development. Not of the underlying tech itself, but in the teams using that tech.
If the same company had to hire someone else with your same skillset as they expand or replace a coworker, they would pay them market value. They would have to offer competitive salary. When that happens, you find new employees making more than equally skilled existing employees. It’s called salary inversion.
but, the company I worked for was not paying higher wages for the newer employees than myself and I got pretty regular, pleasant raises.
I bet they talk about the company “being like a family”, don’t they?
It remains the best company I’ve ever worked for. Small and my opinion and actions actually had real impact to core features of the company, so :)
Worth it, I think.
I did have direct influence into huge and important parts of that business, though and I really, actually was respected and given broad rein in what I could do. My coworkers and I also tended to have a great time working, and I had direct lines to the CTO. We talked often.
There's two things there - the complexity of engineering the cluster itself, and the complexity of using it.
The former is where the pain is. If you can remove that pain by using a reliable managed offering, it changes the perspective a bit.
The complexity of using it is also non-trivial - you have to learn it's terminology and primitives, understand the deployment and scheduling model, know how volumes are provisioned, aggregate logs, etc.
However, the ROI for learning that complexity can be pretty good. If you get comfortable with it (maybe a month or so of learning and hacking?) you get sane rolling deployment processes by default, process management and auto healing, secrets and config management, scheduled tasks, health checks, and much, much easier infrastructure as code. Which means if things do go really sideways, it's usually not that hard just to stand up a replacement cluster from scratch. With a bit more reading and some additional open source services, you get fully automatic SSL management with let's encrypt too.
All that said, I absolutely agree with you in principle. No one should overcomplicate their deployments for no benefit. It's just worth reflecting on what those benefits are. Kubernetes had a bunch of them - and whether they're worth the effort of getting to know it depends very much on the system(s) you're running.