For a while now, and more even since the rise of docker, it becomes a trend to split applications in parts and approach them as a collection of micro-services. This is not exactly new, I remember in 2002 having seen various applications based on this concept. But they had shortcomings. Development was harder and it imported a whole bunch of increased complexity because there was a lot of moving parts.

In a project that I have the occasion of following, I can watch the migration from monolith to micro-service and I can tell you, the architecture change is not simple technical decision. By splitting application there is a whole lot of application aspects that move out of the area of the developers team and are now the responsibility of the infrastructure team. The shift cannot be taken lightly.

From what I observed, the switch to micro-services can only be efficient if there was already a shift to a real devops organization. It means that the development and the infrastructure are more tightly coupled. Otherwise, it’s just a mess. The QA also can get crazy, and the networking layer gets increased complexity (or even dramatic latencies). Errors and services resilience also need an extra layer of attention.

Don’t move to micro-services if you are not ready for it, seriously, it can end up by shooting yourself in the foot.