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

Question

The following commentator writes:

Microservices shift your organizational dysfunction from a compile time problem to a run time problem.

This commentator expands on the issue saying:

Feature not bug. Run time problem => prod issues => stronger, faster feedback about dysfunction to those responsible

Now I get that with microservices you:

• potentially increase latency of your through-put – which is a production and run-time concern.
• increase the number of “network interfaces” in your code where there could be potential run-time errors of parsing.
• can potentially do blue-green deployments. Those could be held-up by interface mismatches (see network interfaces). But if blue-green deployments work then it is more of a run-time concern.

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

Answer 1

I have a problem. Let's use Microservices! Now I have 13 distributed problems.

Dividing your system into encapsulated, cohesive, and decoupled components is a good idea. It allows you to tackle different problems separately. But you can do that perfectly well in a monolithic deployment (see Fowler: Microservice Premium). After all, this is what OOP has been teaching for many decades! If you decide to turn your components into microservices, you do not gain any architectural advantage. You gain some flexibility regarding technology choice and possibly (but not necessarily!) some scalability. But you are guaranteed some headache stemming from (a) the distributed nature of the system, and (b) the communication between components. Choosing microservices means that you have other problems that are so pressing that you are willing to use microservices despite these problems.

If you are unable to design a monolith that is cleanly divided into components, you will also be unable to design a microservice system. In a monolithic code base, the pain will be fairly obvious. Ideally, the code will simply not compile if it is horribly broken. But with microservices, each service may be developed separately, possibly even in different languages. Any problems in the interaction of components will not become apparent until you integrate your components, and at that point it's already too late to fix the overall architecture.

The No 1 source of bugs is interface mismatch. There may be glaring mistakes like a missing parameter, or more subtle examples like forgetting to check an error code, or forgetting to check a precondition before calling a method. Static typing detects such problems as early as possible: in your IDE and in the compiler, before the code ever runs. Dynamic systems don't have this luxury. It won't blow up until that faulty code is executed.

The implications for microservices are terrifying. Microservices are inherently dynamic. Unless you move to a formal service description language, you can't verify any kind of correctness of your interface usage. you have to test, test, test! But tests are expensive and usually not exhaustive, which leaves the possibility that problems might still exist in production. When will that problem become apparent? Only when that faulty path is taken, at run time, in production. The notion that prod issues would lead to faster feedback is hilariously dangerously wrong, unless you are amused by the possibility of data loss.

Answer 2

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 inherent 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.

Answer 3

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.

Answer 4

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.

Answer 5

Both in monolithic systems and microservices you have to define interfaces between the subsystems. The interfaces should be well-designed, well-documented and as stable as possible. This is the same as in OOP.

If your organization is not able to do this, microservices will also not solve the problem. In microservices you have public Web interfaces. So you even have to spend more effort into interface design.

If the interface is not designed properly, you will get two kinds of runtime problems:

1. If the interface is not used correctly, you will get an error on runtime, not at compile time.
2. Calling a Web interface is quite slow, so you can get performance problems.

I think producing runtime issues is not the right way communication organizational problems to those which are responsible.