C>Зависит от конкретной компании, но в теории нет ничего, что этому бы препятствовало. Сервис общается с внешним миром миром через чётко определённый интерфейс, а как он внутри реализован — дело конкретной команды.
C>Простор воображения будет ограничен только общекорпоративными стандартами.

Кто-то же должен реализовывать эти "общекорпоративные стандарты". Вот это я и называют "инфраструктура". Поддерживать эту инфраструктуру для микросервисов куда сложнее, чем для монолитов, потому что для каждого сервиса — свои погремушки, свои deprecation schedule и все прочее. Рефакторинг чего-то в инфре и выливается в жуткую головную боль.

C>И что? Инфраструктура для сервисов — это всякая аутентификация/авторизация, роутинг и метрики/логи. Всё это прекрасно обновляется.
C>Например, в AWS делали рефакторинг авторизации — переходили на "service linked role" вместо "injection token" во всех внутренних сервисах. Это делалось так:

Дай угадаю, тебе не приходилось долго работать в инфраструктуре. Конечно, тем кто не работает над инфрой, все видится как "просто и прекрасно". И даже процесс перехода с "А" на "Б", видится безоблачным:

C>1. Принимается решение на высшем уровне о том, что переход нужен. Это решение доводится до всех в виде обязательных OKR.

Ха. Это было б счастьем, коли такое бы существовало. Но в реальности основной головняк инфра-команды идет _ДО_ того, как "решение на высшем уровне" принимается. Собственно, айсберг как раз там, в том, чтобы вообще сдвинуть эту гору, и заставить принять официальное решение. Особенно если менеджмент не понимает, о чем идет речь. И совсем уж тяжело если эта инициатива идет снизу (от тех же инфра-команд, которым приходится поддерживать этот зоопарк).

C>3. Все постепенно переходят на новый механизм. После исчезновения всех своих сервисов из "отчёта позора", каждая команда устраивает праздник с пиццей и пивом.

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

C>5. Каждый месяц профилактические мероприятия становятся всё строже.
C>6. Успех.

В теории так, но на практике все упирается в post-completion error, когда все вроде бы доложили "мы перешли!", но старый сервис удалить нельзя, т.к. где-то там остались какие-то легаси системы, и никто не работает над их выкашиванием из прода. Часто случается, что менеджменту доложили "мы все сделали", те далее по цепочке передали до самого верха, где решение принималось. А то, что на самом деле старая система никуда не делась, менеджменту проверить уже нет возможностей, слишком уж менеджмент удален от тех, кто работает в поле.