но при этом они административно выделены и не подчиняются другим командам

они пишут апи, доку

и ты, как потребитель, их рассматриваешь как отдельную сущность, почти как левую компанию

т.е. ты конечно можешь их попросить чота изменить, и они среагируют быстрее чем гугол на тебя, но суть в административном делении

а если у тебя просто монолит по апи размазали, это просто апи

не, так это не работает ))) задачи могут рандомиться по любой части... в итоге организационно 1) часть народа будет гарантированно простаивать; 2) нужно будет проводить больше совещания по каждому архитектурному чиху и новой вводной во всех командах; 3) появляются интеграционные взаимодействия между командами, по которым надо протоколировать и оповещать другие команды... в итоге получаем кучу бюрократии, малоповоротный глючный механизм, причем постоянно простаивающий ) это на примере не сильно большого проекта... будет именно на этом проекте больше 10 разработчиков - уже можно думать делить

ну так если тебе не подходит такая организация, ты ее просто не юзаешь
но тогда и называть это микросервисами не надо

просто расхуярил монолит по апишкам для масштабируемости

вот упадет у тебя одна апишка, остальное тоже хуйца соснет?

микросеврисы это архитектурное понятие, а не организационное ) и одно четко не равно другому )))

я считаю административное

а вот не упадёт, каждый комит гоняет тесты на взаимосвязь микросервисов

а если разделить репозитории так не выйдет )

ибо организационно архитектурно и так есть soa, нахуя два слова для одного говна?

я про то что физически упадет и не поднимется

органзационно пофик у тебя там микросервис, сервис, веб-сервис или другая хня, главное по сути )

как физически? сервак на пол? )

типа

если один микросервис падает, остальные по-максимуму без него справляются ) если в проде

а в тестах - изменить апи и пройти тесты дело очень сложное )