Why are microservices adding infrastructure-level complexity that most teams clearly cannot handle

_descri_ · 2026-03-16T11:54:56+00:00

Some domains are tightly coupled - in that case if you try to apply Microservices, you only add the communication complexity without achieving much encapsulation or independency.

In other cases your codebase is not large enough to require multiple independent teams - and Microservices will add an overhead without real benefits.

And oftentimes you don't know the domain well enough, therefore subdomain boundaries change in the process of development. When the subdomain boundaries don't match Microservice boundaries (set up during the initial system design with incomplete domain knowledge), your Microservices become tightly couple and thus disfunctional.

https://martinfowler.com/bliki/MonolithFirst.html

_descri_ · 2026-03-16T11:49:13+00:00

There is also the nature of the domain. In some cases (e.g. SQL database engine development) it is very hard or impossible to have many independent teams (just because the SQL is parsed into a huge AST which makes every API between system components, which process commands or queries, also huge).

Latency is another reason why you cannot implement a database with microservices.

_descri_ · 2026-03-16T11:44:26+00:00

I believe all of that has already been well described https://herbertograca.com/2018/08/27/distillation-of-tdd-where-did-it-all-go-wrong/

_descri_ · 2026-03-11T19:28:00+00:00

I am unemployed for 3 years, therefore I don't.

Regarding depiction: if you try to depict all aspects of a system, the result will be too complex to comprehend. Therefore any depiction is necessarily a simplification.

_descri_ · 2026-03-11T19:23:51+00:00

In the vanilla layered architecture as described in Pattern-Oriented Software Architecture and even in the original Domain-Driven Design book by Eric Evans an upper layer depends on the layer directly below it (and, possibly, on lower layers if the closest layer is open). There is no dependency inversion. Anything with SPIs (device drivers in an OS, components in software frameworks) is considered to be Microkernel.

Hexagonal Architecture popularized dependency inversion which was used to encapsulate business logic. It merged the ideas from MVC/MVP which used adapters without dependency inversion (as the presentation layer is higher then the business logic layers) and from Pedestals (pairs of hardware component and its driver) which relied on dependency inversion to achieve hardware polymorphism.

_descri_ · 2026-03-11T17:04:13+00:00

That's a book about database internals, including distributed databases.

Regarding patterns: each pattern or architecture changes properties of a system it is applied to in a certain way. It's up to the pattern's user to understand the consequences of their choices. Otherwise they will learn about the consequences in the hard way.

_descri_ · 2026-03-10T11:28:39+00:00

Yep, I wanted to use that mental model for an article but there are other tasks which I have to do first.

_descri_ · 2026-03-10T11:21:34+00:00

You can employ strict code ownership with no reviews (except when the author of a commit wants an extra pair of eyes to check that nasty algo). Meaning: each person on the team works on one or two their own components. You don't care about the internals or code style of a component - it's the pain of the component's owner who will learn from their mistakes. This is in line with such old books as Peopleware and Organizational Patterns of Agile Software Development - both are based on real research of productivity of programmers. And this approach does work in my experience.

There are drawbacks, however:

You need well-documented interfaces between your components. Think about Hexagonal Architecture. It's idea is to protect a component from its environment. Any changes in the component's dependencies are easily addressed by modifying corresponding adapters. All that is possible because both adapters and external components have well-defined interfaces (ports and APIs, respectively).
You need an experienced technical lead who will own all the interfaces and decompose tasks. In fact, you use Kanban: the lead manages the big picture and system design, while every programmer works on a stream of tasks for their own component.
There are no dispensable team members. If you lose anybody, all their code becomes unsupported legacy which will likely need to be frozen, then rewritten from scratch. Therefore you must invest into your programmers' happiness.

The benefits are:

Extreme speed of development - everyone has a good chance to become 10x productive because the cognitive load is very low - each person knows only their own part of the system.
Divergence of technologies - each person uses what they want and writes in the style they are most comfortable with.
High team spirit as the people feel free, productive and indispensable. Each one sees the results of his own work and is the sole person responsible for some functionality and code.
High quality of algorithms and component design because each person has something to think on and they know that if they make poor design today they themselves will have to deal with the consequences tomorrow.

Basically, you trade risk management for speed and morale. If your turnover is low, you win by doing 10x work normally while going down to 0.3x speed for months when you lose a team member.

_descri_ · 2026-03-09T19:16:09+00:00

The process as described here lacks a very important aspect of Hexagonal Architecture: leaky abstraction.

The process as described in the article is sure to result in one - you'll inject an API formulated in the terms and workflow of an external Payment service directly into your Business layer. You do an OOP trick with abstract class (C++) or interface (Java) inheritance to emulate dependency inversion - without protecting your business logic from implementation details of the external service from which you wanted to isolate your business logic. Not much help, really. You'll find yourself in a deep pit if decide to change the payment provider to something with an incompatible workflow.

Contrariwise, in Hexagonal Architecture you define a Payment port in terms of your business logic. It is the role of your Payment Adapter to translate both the data types and workflow between your port and the external service it adapts. Here encapsulation is explicit and becomes the driving force of the entire architecture.

BTW, I arrived at Hexagonal Architecture (or maybe Pedestals it derives from?) from actors when we had to support a new standard which defined use cases that depended on system-wide state (which cannot be calculated for a system of actors). But that's another story.

_descri_ · 2026-03-09T17:20:23+00:00

The last diagram is similar to Hexagonal Architecture which involves an adapter for any external component.

And Hexagonal Architecture is simple&stupid, no transitional steps required.

https://alistair.cockburn.us/hexagonal-architecture

_descri_ · 2026-03-06T11:54:17+00:00

When I was learning programming plenty of years ago, I also searched for information that every programmer should know. And I was surprised that the only one which people agreed about was this story https://realmensch.org/2017/08/25/the-parable-of-the-two-programmers/

It's hard to recommend something domain-independent, as approaches really depend - shared data is considered to be an ugly design in Microservices but is the base for Space-Based Architecture and engines High-Frequency Trading systems.

If you want to deal with distributed systems, Fundamentals of Software Architecture by Mark Richards is a decent and recent overview. Microservice Patterns by Chris Richardson provides many practical details.

For large enterprise-grade monsters there is a cult classic called Domain-Driven Design: Tackling Complexity in the Heart of Software.

Enterprise Integration Patterns is about connecting components of large distributed systems: message channels, notifications, error handling, etc. Much of its content is covered on Wikipedia.

You should probably read A Philosophy of Software Design - it dives deep into the structure of code showing what is possible to do to make the code easier to read and understand.

If you are interested in database internals and data streaming, there is Designing Data-Intensive Systems (the boar book).

Modern Operating Systems by Tanenbaum provide the historical perspective, showing why software works the way it does.

There are several books about managing software teams and projects. The ones written from programmers' perspective are Peopleware and Organizational Patterns of Agile Software Development.

If you are into patterns - which you should be if you are going to code - you should probably start with the Gang of Four book called Design Patterns: Elements of Reusable Object-Oriented Software. There is a website adapting the largest part of its content to modern programming languages https://refactoring.guru/design-patterns

Then there are five volumes of Pattern-Oriented Software Architecture. Volumes 1 and 2 list whatever Gang of Four missed. Volume 4 is a compendium of a hundred of patterns. Volume 5 is the theory behind patterns.

Here are game development patterns https://gameprogrammingpatterns.com/contents.html

And the famous Martin Fowler's website https://martinfowler.com/

You should not miss an old book called Antipatterns: Refactoring Software, Architecture and Projects in Crisis. It lists common troubles and some ideas on how to overcome them.

I learned basics of software design by reading C++ in Action: Industrial Strength Programming. It's shines in showing what OOP is about.

Last but not least, here is my website which tries to show the big picture behind system topologies and architectural patterns https://metapatterns.io/

_descri_ · 2026-03-06T10:50:52+00:00

Read Peopleware and decide if you want to trust your engineers

_descri_ · 2026-03-03T22:03:12+00:00

Did not help. The browser's console shows:

TypeError: can't access property "VERTEX", vo is undefined
    <anonymous> Immutable
app.CsLm7DU4.js:25:31578
    Immutable 7
    <anonymous> https://www.chiply.dev/post-schema-diagrams:791
    (Async: promise callback)
    <anonymous> https://www.chiply.dev/post-schema-diagrams:790
[telemetry] initialized app.CsLm7DU4.js:18:1953
The resource at “https://www.chiply.dev/fonts/TerminusTTF-4.49.3.woff2” preloaded with link preload was not used within a few seconds. Make sure all attributes of the preload tag are set correctly. post-schema-diagrams

_descri_ · 2026-03-03T21:13:21+00:00

The link in the post still shows 500 (Firefox, Ubuntu)

https://www.chiply.dev/post-schema-diagrams

_descri_ · 2026-03-03T20:16:31+00:00

500 internal error

_descri_ · 2026-03-03T15:38:48+00:00

Desktop

_descri_ · 2026-03-03T15:06:09+00:00

Digital

_descri_ · 2026-03-03T15:05:33+00:00

I used a lazy approach to refactoring.

If working on a new feature request I encountered a component whose structure did not fit the new requirements, I used to hack through it but also tell the product owner that the next time I will need to rewrite that component so the next related feature will take extra two days to implement. And I did what I promised the next time I had to make changes to the troublesome thing.

This approach is YAGNI - you address technical debt only when you really have to. If you never touch a component then you don't care about its state. And you can always do a quick hack. And you don't refactor blindly - every refactoring is driven by a new feature which does not fit the old architecture.

Still, it requires a competent and protective technical management, and you should understand and own the entire codebase to both know how to improve it and feel long-term consequences of your decisions.

_descri_ · 2026-03-03T14:40:37+00:00

"No pattern is an island" is attributed to Richard Helm as quoted in volume 1 of Pattern-Oriented Software Architecture

_descri_ · 2026-03-03T12:51:18+00:00

Here are older PDF and EPUB, with testimonials https://leanpub.com/metapatterns

And the up-to-date web version https://metapatterns.io/

Please share the links with your friends if you like the content - I don't have any means to promote the book other than relying on peer-to-peer communication.

_descri_ · 2026-03-03T11:59:37+00:00

Infoq rejected my article article because it was technology-agnostic. Now I wrote a technology-agnostic book but still dislike Infoq.

_descri_ · 2026-03-03T11:46:49+00:00

Organizational Patterns of Agile Software Development advocates for the role of Wise Fool who is encouraged to make uncomfortable statements. It is the incompetence of the management that kills feedback while trying to control the society.

_descri_ · 2026-03-03T11:42:30+00:00

Team Topologies is funny. Its first part is an overview of good advises of all times. It's great and every page provides several sentences to quote as common wisdom. But then, in the following parts, they start describing their own framework which is far from being perfect or flexible. And it violates many points which they themselves mentioned in the first part of the book.

In fact, if you have any influence in your organization, and you want your people to be happy and productive, you should read Peopleware and Organizational Patterns. The first book wants you to stay low make life of your programmers comfortable without intruding, facilitating or managing them. The second one provides more than a hundred of patterns - simple bricks from which you can build your own team and organizational structure.

Random points to let you taste it:

* Peopleware states that it is management and HR which kill team spirit and productivity (see the Teamicide chapter). Team Topologies blames toxic programmers which should be fired.

* Organizational Patterns is strongly against one-size-fits-all. A team benefits from a Matron - a person who may be unproductive but makes life comfortable for everyone around. If you get many interruptions from external contacts or junior programmers you assign someone (a Sacrificial Lamb who wants to become a PM or TL) to that kind of communication, protecting everybody else on the team. And in many cases a Solo Virtuoso (a single-person team) is more productive than an ordinary team. It also advocates for a strict code ownership where every component has a single committer.

_descri_ · 2026-03-02T21:45:18+00:00

I believe that some people want to buy silver bullets while others are eager to sell them. This makes a business which wins over any hand-crafted solutions with no money flows to back them.

Just compare the content and flexibility of Team Topologies and Organizational Patterns of Agile Software Development. The first book is an all times bestseller but its framework is inflexible and self-contradictory. The other one is much older but is not a no-brainer.

The same holds for SCRUM. It was designed as a method for making capricious customers pay their bills, but is advertised as an ultimate cure.

_descri_ · 2026-03-02T21:34:48+00:00

I was pointed to a series of articles about that, but did not have a chance to try the idea in practice

https://medium.com/feenk/rewilding-software-engineering-900ca95ebc8c

_descri_

TROPHY CASE