How does shifting to microservices create a run-time problem?

The first tweet was mine, so I'll expand on it:

Suppose you have 100 developers, working on a monolithic application. That's too many people to communicate effectively between each other, so the company has to work hard to divide them into smaller teams and create good communication patterns between them. When the organisation is "dysfunctional", teams probably aren't talking to each other, they aren't aligned to a larger goal, they disagree on priorities etc - as a result, it takes them forever to ship something. It's a "compile time problem" in the sense that the dysfunction is obvious before the software is produced. The project is probably a death march or never going to ship ("compile").

I think many people are attracted to micro services, and are moving to them, not because of inherit technical/architectural benefits, but because it allows them to ignore the organisational dysfunction. Instead of trying to align 100 developers, they hope that they can have tiny teams working in silos, each focussed on their own little micro service. If you are in such a dysfunctional organisation, this is so attractive: it gives you much greater permission to avoid people you don't like, to not communicate.

Unfortunately it becomes a "run time problem" because once the software is running in production, good communication becomes just as important. The problems with the organisation - the teams and how they are aligned and communicate - manifest at "run time".

The point of my tweet was: if what you have is a people problem, a new architecture isn't going to help. It will just delay the effects of the problem. I think the attractiveness of micro services to many people is the hope that it will magically solve these people issues.

My question is: What does it mean that shifting to microservices creates a run-time problem?

That is not what those tweets are saying! They don't say anything about shifting to microservices, nor do they say anything about creating problems. They only say something about shifting problems.

And they put a contextual restriction on their assertions, namely that your organization is dysfunctional.

So, what the first tweet is basically saying is two things:

• "if your organization is incapable of engineering complex systems now without microservices, it won't magically be able to engineer complex systems with microservices" and
• "the problems caused by that inability which now show up during compile-time, i.e. during development will then show up during run-time, i.e. in production" (technically, they could also show up during testing, but remember, the quote restricts itself to dysfunctional organizations, which likely have a sub-standard testing regime)

The second tweet says that the fact that the problems only manifest themselves in production, i.e. where customers see them, is a feature, not a bug, because when customers complain, that tends to be heard in different places than when a build breaks, namely in places which are able to do something about the organizational dysfunction (e.g. high-level management). Since organizational dysfunction usually is a failure of high-level management this means that unsatisfied customers reflect badly upon those who are ultimately responsible for that unsatisfaction, whereas low code quality caused by higher-level management failures usually only reflects badly upon the developers, who are, however, not at fault and unable to do something about it.

So, the first tweet says that microservices move problems caused by bad management from compile time, where only developers see them, to run-time, where customers see them. The second tweet says that's a good thing, because then, the problems hurt those who are responsible for them.

It creates a run-time problem as opposed to a compile-time problem.

A monolithic app is hard and expensive to compile. But once it compiles you can be reasonably sure that no extremely stupid incompatibilities between components exist, because the type system can catch them. The same error in a system of microservives might not show up until two specific components actually interact in a specific way.