Software architecture diagrams suck.
My father and grandfather built houses. I grew up with blueprints, the large drawings used for construction. For those who may have never seen such drawings before, here is an example:
"You're playing and you think everything is going fine. Then one thing goes wrong. And then another. And another. You try to fight back, but the harder you fight, the deeper you sink. Until you can't move... you can't breathe... because you're in over your head. Like quicksand."
As a software developer or devops engineer, you need to recognize when you are in quicksand.
Here is how you get out.
Picture the pool of available skilled technology workers as an inverted pyramid. Each level is dependent upon the technology skills of the level below it. The higher one goes on the inverted pyramid, the more common and less expensive the skill set. The lower one goes on the inverted pyramid, the less common and more expensive the skill level.
A wise man once observed, "There are two types of people in this world: those who divide people into two types and those who do not." Perhaps it was Steve Martin; I don't remember.
In that same vein of reasoning, I have found that there are two types of engineers:
I call the first type Simplifying Engineers and the second type Complicating Engineers. I despise the second type of engineer. He is obnoxious to industry.
Leo Tolstoy begins his novel Anna Karenina with the profound observation that:
“Happy families are all alike; every unhappy family is unhappy in its own way.”
Not to be maudlin, but an engineering development team is a lot like a family, especially where Tolstoy's observation is concerned. I would state the Karenina Principle as:
“Successful development teams are all alike; every unsuccessful development team is unsuccessful in its own way.”