[gsteinacker]

In the beginning, every team that is able to build a monolith should also be able to build multiple microservices. Think of microservices being highly cohesive and loosely coupled components...

But this will not scale with respect to the number of dev/ops/qa people or with respect to the number of microservices. We did it differently from the beginning by starting with four instead of a single team.

Today, we have ~12 "feature teams" and a few teams for "cross cutting concerns": A team that is responsible for loadtests (ensuring scalability), one for (ensuring) security, one for "platform engineering".

The feature teams are responsible for one or few "bounded contexts" (->Domain Driven Design) like "ShoppingCart", "Search", "Navigation". Every BC is implemented by one or more microservices.

Teams have developers, testers, and everything else, that they need to develop and operate their services. Splitting teams by skill (DB, Frontend, ...) instead of splitting by business domain (shopping cart, ...) would only have the effect, that multiple teams heavily depend on each other, all the time. IMHO not a good idea. I would strongly recommend to build mostly independent, autonomous, cross-functional teams. DevOps teams.

--Guido

[merb]

Actually what you describe here is mostly why I think that it was stupid to rebuilt otto.de from scratch. microservices are a improvment over a monolith inside a bigger Application with a big team. Microservices are happening caused by team sizes and management overhead, it had nothing to do that a monolith is bad at all. And that's why I dislike all the fancy posts about them, nothing stops you from doing all the same things with a monolith, especially when you have a small team. As your team grows you mostly change to a service oriented architecture and evolve from there. it mostly isn't a good practice to start with a microservice architecture without having a monolith that you need to split (I know there are some but stil.. it's hard to say that the overhead it produces with a "few" people is valueable). Actually a lot inside this article explains what parts were easy, however the hard parts about such systems are mostly not written anywhere near, which is most managing logs, faulty systems, automatic routing, versioning, database migrations if the system has a database, updating servers, service discovery, service load-balancing, service monitoring, edge service router and that are prolly just a few of the dozen things which makes such systems harder.

[gsteinacker]

We did not rebuild otto.de from scratch because we wanted a microservice architecture. We had to rebuild otto.de, because the old monolithic shop was not meeting non-functional (and a single functional) requirements anymore. And we had to rebuild it, because the old shop was based on a standard product, so we were unable to simply refactor it. When we started the development, we were looking for an architecture that is meeting our requirements - and we did not chose microservices in the beginning, but self-contained systems (http://scs-architecture.org, https://en.wikipedia.org/wiki/Self-contained_Systems). Microservices were introduced later, when the first SCS became too large again. I think, you should not use microservices, because they are interesting. You should use microservices, when you have problems that are addressed by this architectural style.

I totally agree, that microservice architectures (just like any other kind of distributed system) have a lot of challenges. It is hard to solve the problems, that you mentioned. My article was about the good parts - but I could very well imagine to write a follow-up about all the challenges :-)

--Guido