What happens to these people when ppl move to mircoservices. Now we have bunch of devs who are expected to be jack of all trades doing everything sub optimally .
I've seen some places move all database experts to 'db as service' team, but this arrangement is awkward at best and have strange organizational and management issues that were not present in monolith style development
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
That is such a huge win. Time spent deploying and monitoring is wasteful; especially when you have a large application running on hundreds of machines.