I've been struggling on and off with this for the past few years since moving into consulting after 15~ years of permanent (platform/ops/automation) engineering roles.
Often the most difficult situations are not complex due to the use of some advanced technology or business need - but instead because of the sheer amount of components in play that you need to understand in order to add any value.
The ramp up time just to understand WHAT components make up a given system let alone HOW they work seems to have shot through the roof over the past 5 or so years.
With once monolithic systems being broken down into distributed microservices, service meshes being widely deployed, everything-is-an-API architecture and other good things - an unfortunate side effect (when combined with seemingly growing expectations on engineers to be 'full stack') is that cognitive load has shot through the roof.
While compared to 10 years ago - it does seem like most systems have better uptime - I'm not convinced they're easier to support and aren't over-engineered most of the time.
Edit: spelling, grammar (sorry it's midnight and I'm falling asleep)
If your distributed microservices require several to be updated at a time for every change, are they really separate services? Isn't the entire point of a microservices architecture to reduce the cognitive load with understanding how everything in the system works? You simply need to learn endpoints, not inner-workings. Take Uber for example: post API 1 for calling a ride, post API 2 for payment data, post API 3 for reporting a problem.
Unless your business requirements change drastically every 2-6 months, then it doesn't matter what architecture you use - you'll have to redo most of the stack in a monolith or distributed microservice arch.
Are these good things, or just fashionable things? Is optimizing for five nines, at the expense of many other metrics, ever the right choice if you're not Google? Or is it just a fad? Especially if and when the implementation is just pure blind cargo-culting?
The amount of people excitedly telling me their 8 person startup is using microservices really upsets me. I try to tell them what a mistake it is, but they never listen. They don't know what problems microservices solve or bring. They just know "microservices = good." It gets really frustrating sometimes.
Often the most difficult situations are not complex due to the use of some advanced technology or business need - but instead because of the sheer amount of components in play that you need to understand in order to add any value.
The ramp up time just to understand WHAT components make up a given system let alone HOW they work seems to have shot through the roof over the past 5 or so years.
With once monolithic systems being broken down into distributed microservices, service meshes being widely deployed, everything-is-an-API architecture and other good things - an unfortunate side effect (when combined with seemingly growing expectations on engineers to be 'full stack') is that cognitive load has shot through the roof.
While compared to 10 years ago - it does seem like most systems have better uptime - I'm not convinced they're easier to support and aren't over-engineered most of the time.
Edit: spelling, grammar (sorry it's midnight and I'm falling asleep)