I find myself saying these repeatedly in numerous meetings, discussions, and architecture reviews. I have no idea where these ideas originated from, but they are harmful and lead to entangled, distributed messes.

Yet countless other organisations implement those same "radical" ideas brought about by the same "purists" to thrive in increasingly competitive markets because they are not afraid to experiment, fail fast and deliver value sooner (& safer & happier).

@einarwh.bsky.social I could have sworn that this image had a post/explanation attached to it, no? I wanted to refer someone to it. Am I imagining it, or did I read it on another platform?

to aggregate and transform logs to a vendor-specific format before forwarding it. #Observability

Which is why I moved away from that initial requirement. The problem is they can't agree on what they want + no one wants to put the work in. They want to change nothing but somehow get everything.

'Architecture' wanted to understand system behaviour in prod, Developers didn't want to change anything as they are under constant pressure to deliver features, Compliance didn't know PII data was logged and want it removed, Security wanted to analyse logs in specialised tools, etc..

However, it quickly became apparent that that meant different things to different people and speaking to them surfaced a few. Top brass wanted to cut costs, SREs wanted more detailed telemetry + better alerting, DevOps (yes, they have a separate team) wanted standardised logging across microservice

That is part of the problem. They don't know what they want and the deeper I go the more dysfunctional I discover the org is and the more cans of worms I open. They work in silos and don't talk to each other. But when I inherited it the goal was centralised logging.

Today felt like the last straw. People who have tried/are selling observability to/at an org: at what point do you give up?

"We can't send our telemetry data to SaaS vendors; they contain all sorts of PII data", "how do you investigate issues without PII data?", "OK. We realise we shouldn't log PII data but..", "Don't care about all these benefits, only costs."

"We don't need this", "engineers don't have time to implement it", "every engineering director needs to be the 'go-to person' in big outages", "we build it, but we don't run it or design it - so what's in it for us?",

The "Is TDD Dead?" debate with Kent Beck & Martin Fowler vs DHH helped me see the light way back then

Someone did create a... oh, I get it :) I was rejected by JustEat around 10 years ago because my tests didn't isolate the units of code, and the structure of my test project didn't mirror that of the production code. Hopefully, that someone fixed all this now that he works there

I used consumers here because I have seen this implemented in many ways:

- Using orchestrator services
- Using the UI to orchestrate
- Relying on knowledge in users' heads

www.ashrafmageed.com/the-hidden-c...

Instead of business processes and rules being baked into your services with the data they operate on, they are pushed up to the consumers and the interactions between them.