Здравствуйте, SkyDance, Вы писали:

VC>>Рефакторинг всех микросервисов сразу требуется куда реже (если их границы были выбраны правильно изначально).
SD>Что считать рефакторингом?
Что-то, что влияет на все сервисы.

SD>И где граница работы команды? Вот, скажем, может ли команда выбирать технологии для постройки микросервиса? А до какого уровня? А можно вместо Linux использовать FreeBSD? А вместо виртуалок — bare metal?
Зависит от конкретной компании, но в теории нет ничего, что этому бы препятствовало. Сервис общается с внешним миром миром через чётко определённый интерфейс, а как он внутри реализован — дело конкретной команды.

Просто воображения будет ограничен только общекорпоративными стандартами.

SD>Тут-то и находит коса на камень. Оказывается, что в каком-то месте "микросервисы" лежат поверх существующей инфраструктуры. И чем "микрее" сервисы, тем толще получается эта самая "инфра".
Не особо. Я вообще не люблю слово "микросервис" — так как реально всегда получается "сервис" (без "микро-").

SD>Но ведь ей, инфре, тоже нужно развиваться. А для этого нужно и рефакторинг производить. Да, в инфре.
И что? Инфраструктура для сервисов — это всякая аутентификация/авторизация, роутинг и метрики/логи. Всё это прекрасно обновляется.

Например, в AWS делали рефакторинг авторизации — переходили на "service linked role" вместо "injection token" во всех внутренних сервисах. Это делалось так:
1. Принимается решение на высшем уровне о том, что переход нужен. Это решение доводится до всех в виде обязательных OKR.
2. Команда, поддерживающая старый механизм, делает "отчёт позора" со списком клиентов, вызывающий старый API. Этот отчёт каждую неделю отсылается в рассылку для менеджеров.
3. Все постепенно переходят на новый механизм. После исчезновения всех своих сервисов из "отчёта позора", каждая команда устраивает праздник с пиццей и пивом.
4. За полгода до окончания срока, все менеджеры сервисов из "отчёта позора" приглашаются на профилактические мероприятия к высшему менеджменту.
5. Каждый месяц профилактические мероприятия становятся всё строже.
6. Успех.

ЧСХ, в монолитах большой рефакторинг происходит примерно аналогичным образом.

Здравствуйте, SkyDance, Вы писали:

VC>>Рефакторинг всех микросервисов сразу требуется куда реже (если их границы были выбраны правильно изначально).
SD>Что считать рефакторингом?
Что-то, что влияет на все сервисы.

SD>И где граница работы команды? Вот, скажем, может ли команда выбирать технологии для постройки микросервиса? А до какого уровня? А можно вместо Linux использовать FreeBSD? А вместо виртуалок — bare metal?
Зависит от конкретной компании, но в теории нет ничего, что этому бы препятствовало. Сервис общается с внешним миром миром через чётко определённый интерфейс, а как он внутри реализован — дело конкретной команды.

Простор воображения будет ограничен только общекорпоративными стандартами.

SD>Тут-то и находит коса на камень. Оказывается, что в каком-то месте "микросервисы" лежат поверх существующей инфраструктуры. И чем "микрее" сервисы, тем толще получается эта самая "инфра".
Не особо. Я вообще не люблю слово "микросервис" — так как реально всегда получается "сервис" (без "микро-").

SD>Но ведь ей, инфре, тоже нужно развиваться. А для этого нужно и рефакторинг производить. Да, в инфре.
И что? Инфраструктура для сервисов — это всякая аутентификация/авторизация, роутинг и метрики/логи. Всё это прекрасно обновляется.

Например, в AWS делали рефакторинг авторизации — переходили на "service linked role" вместо "injection token" во всех внутренних сервисах. Это делалось так:
1. Принимается решение на высшем уровне о том, что переход нужен. Это решение доводится до всех в виде обязательных OKR.
2. Команда, поддерживающая старый механизм, делает "отчёт позора" со списком клиентов, вызывающий старый API. Этот отчёт каждую неделю отсылается в рассылку для менеджеров.
3. Все постепенно переходят на новый механизм. После исчезновения всех своих сервисов из "отчёта позора", каждая команда устраивает праздник с пиццей и пивом.
4. За полгода до окончания срока, все менеджеры сервисов из "отчёта позора" приглашаются на профилактические мероприятия к высшему менеджменту.
5. Каждый месяц профилактические мероприятия становятся всё строже.
6. Успех.

ЧСХ, в монолитах большой рефакторинг происходит примерно аналогичным образом.