[reactordev]

This is complete lack of experience on the authors part. No tracing, no observability, no knowledge of distributed systems design to allow them to see what they can clearly measure. Your take is the correct one. Microservices break up the monolith so that multiple teams can work on pieces of the solution/platform without stepping on each others toes. The rest of it is documentation/discovery.

[jbreckmckye]

Tracing and o11y are a poor sibling to static analysis.

> This is complete lack of experience on the authors part

Actually I'm going to turn the accusation back on yourself: if you think reasoning about a system's entire graph of behaviours from runtime traces is trivial, I don't believe you've worked on a truly complex system

The range of what a program can do is much larger than what a program does do in your two week Datadog aggregation window

[reactordev]

It is trivial when properly configured and used. I get why you think I might not have worked on large systems but to the contrary, I've built systems for Fortune 500s. All of them had this baked in and all of them had a place to go when things went wrong. Self-service, observable, documented, and supported by the very folks who wrote it.

[jbreckmckye]

Observability and operability are just not the same thing as being able to reason about the software. You need both

You can't capture the full range of behaviours and edge cases unless you are willing to ingest billions of events without lossiness

Metrics have limitations of cardinality. Logs need to be reduced or else you are in archive rehydration hell

There will be code paths that have never been triggered that you still need to reason about as part of analysing a system, eg in threat modelling

> I get why you think I might not have worked on large systems

I didn't, necessarily. But it looked like an excessively strong claim, combined with a challenge to the author's competence. I wanted to call that out.

[reactordev]

>”There are code paths that have never been triggered”

I don’t know where you learned engineering but where I work, we test our code. There are no “dark” paths.

98% code coverage over 50+ microservices.

[mrkeen]

Missing the point.

Static analysis doesn't go away. Metrics just covers the gap of "is this used by external callers", and nothing more than that. You need that to identify dead routes in a monolith anyway.

If you like static analysis, you should be able to spin up new code in a language more amenable to it than the incumbent code. Not doable in a monolith.

[inigyou]

Why do you think different people can't work on different parts of a single deployment unit (which is what we mean by "monolith")?

[mrkeen]

* My last monolith job had 4 hour release windows.

* You can't change anything of substance. The more people touching the same codebase as you statistically puts you way lower in the pecking order. Changes become political, not technical.

Sometimes the forces of stupidity cancel each other out. It was a 10+ year-old C# monolith, and the top dog wanted to switch to Python because "AI works better with it". I didn't have to waste any time worrying or arguing, since him keeping the system as a monolith made this change impossible.

[inigyou]

Why would a single deployment unit have to be written in exactly one language?

[mrkeen]

OK, count me onboard!

Can we convince the 2-3 other stakeholders in our deployment unit to go with this crazy plan? Or are there 40-60 other stakeholders we need to convince?

[inigyou]

Why would the number of stakeholders be related to the number of deployment units?

[reactordev]

why would a single deployment unit require more than one language?

[inigyou]

Doesn't, but if you want to, you can