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

НС>>Опять же, для совсем ленивых есть istio, который утаскивает все заморочки с ненадежностью типа ретраев на инфраструктурный уровень, оставляя код без этих заморочек.
SD>Сильное заявление. Сами по себе "ретраи" то еще зло. Работоспособное только в случае идемпотентных изменений или linearisability.
"Вы ещё делаете неидемпотентное API? Тогда мы идём к вам!"

Здравствуйте, 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>Тут-то и находит коса на камень. Оказывается, что в каком-то месте "микросервисы" лежат поверх существующей инфраструктуры. И чем "микрее" сервисы, тем толще получается эта самая "инфра".

Непонятно в чем тут сложности с поэтапным переездом на новую инфраструктуру Смена Linux на FreeBSD или виртуалок на bare metal для приложения может быть вообще прозрачной, в зависимости от дизайна этого приложения.

SD>Но ведь ей, инфре, тоже нужно развиваться. А для этого нужно и рефакторинг производить. Да, в инфре. Это равносильно рефакторингу всех микросервисов сразу. Я именно про такой рефакторинг, а не когда в каком-то одном микросервисе "рефакторят" MySQL на MariaDB.

Приведи конкретный пример когда это создаст необходимость рефакторинга всех микросервисов сразу и этого нельзя будет избежать.

C>С тех пор количество новых фич и улучшение текущих зашкаливает, даже следить сложно.

Это потому, что фичи стали микроскопические. Примерно как SEO-странички, раньше обзор был из одной длинной страницы, теперь же 12 коротеньких.

C>При хорошем управлении, количество дубликатов остаётся небольшим.

Возвращаемся к вопросу о "политической воле". Собственно, в нее, волю, все всегда и упирается.

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

M>>Ровно поэтому API между сервисами и не рефакторят, что бесполезно. Выкатишь новую версию, а ресурсов ссадить пользователей со старой силенок не хватит. В результате поддерживаешь две версии непонятно зачем.

SD>Именно так все и происходит

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

Происходит по-разному, зависит от той самой "политической воли", потому как переход требует ресурсов (т.е. денег), эти ресурсы должны быть запланированы, выделены и учтены корпоративной бюрократией.
Соответственно пендель должен быть дан с более высокого уровня. Когда он есть в наличии, то все крутится, работает и апгрейдится на новую версию. Если его нет — ну тогда на верхнем уровне пофигу на это, и пендель может прийти
от кого-то еще выше уровнем. А если они там все мух не ловят, ну значит так им и надо, получат в результате свалку мусора в API рано или поздно.

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

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

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

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

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

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

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

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

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

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

VC>Точно не смену инфраструктуры. Инфраструктура — это часть изначального дизайна

Ха. То есть давайте самую сложную часть системы назовем "инфраструктурой" и заметем проблему туда, под коврик. Пусть другие мучаются с монолитом инфраструктуры, зато у нас все хорошо с микросервисами.
Хорошо бы, конечно. Но это ж какие должны умы работать в той самой инфраструктуре.

VC>Непонятно в чем тут сложности с поэтапным переездом на новую инфраструктуру Смена Linux на FreeBSD или виртуалок на bare metal для приложения может быть вообще прозрачной, в зависимости от дизайна этого приложения.

Сам процесс поэтапного переезда и есть проект высочайшей сложности, ничуть не отличающийся от рефакторинга монолита. В конечном счете что монолит могут рефакторить только избранные Нео, что переделывать инфраструктуру в понимании микросервисов.
Иногда еще эту инфраструктуру называют "платформой". И там нужны самые сильные кадры. Вот только где ж их взять, да еще удержать от rage quit, когда очередной раз в инфраструктуру сваливаются "перламутровые пуговицы", которые кто-то из работающих над микросервисами выкатил как "очередной прорывный фреймворк".

VC>Происходит по-разному, зависит от той самой "политической воли"

Думаю, на этом и сойдемся

Монолит, микросервисы... как в "Армаггедоне", "Русская электроника, американская электроника... все сделано на Тайване!"

В конечном итоге "быстрое движение" всегда наблюдается в долг. Переход от одной схемы к другой (разнесение на сервисвы) — когда тот самый долг чутка отдали, а значит, можно снова двинуться вперед с высокой скоростью. И дело не в переходе с монолита на микросервисы, а просто в том, что возникла политическая сила этот технический долг вернуть. Под соусом ли перехода на сервисы, или как-то иначе, уже не критично.

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

VC>>Точно не смену инфраструктуры. Инфраструктура — это часть изначального дизайна

SD>Ха. То есть давайте самую сложную часть системы назовем "инфраструктурой" и заметем проблему туда, под коврик. Пусть другие мучаются с монолитом инфраструктуры, зато у нас все хорошо с микросервисами.
SD>Хорошо бы, конечно. Но это ж какие должны умы работать в той самой инфраструктуре.

Большинство компаний сейчас не держит своей инфраструктуры как таковой, аутсорсит ее в какой-нибудь AWS или там GCP — пусть у них голова болит.
Ну во всяком случае нижний уровень этой инфраструктуры. Все что поверх этого это уже чем девопсы занимаются — развертывание, масштабирование, обвязка всякими логгингами, трейсингами, мониторингами и проч.

VC>>Непонятно в чем тут сложности с поэтапным переездом на новую инфраструктуру Смена Linux на FreeBSD или виртуалок на bare metal для приложения может быть вообще прозрачной, в зависимости от дизайна этого приложения.

SD>Сам процесс поэтапного переезда и есть проект высочайшей сложности, ничуть не отличающийся от рефакторинга монолита. В конечном счете что монолит могут рефакторить только избранные Нео, что переделывать инфраструктуру в понимании микросервисов.
SD>Иногда еще эту инфраструктуру называют "платформой". И там нужны самые сильные кадры. Вот только где ж их взять, да еще удержать от rage quit, когда очередной раз в инфраструктуру сваливаются "перламутровые пуговицы", которые кто-то из работающих над микросервисами выкатил как "очередной прорывный фреймворк".

Пример плиз... Что за проекты высочайшей сложности от рефакторинга инфраструктуры (рефакторинг инфраструктуры это оксюморон какой-то как по мне).
Если речь вообще про смену скажем одной облачной инфраструктуры на другую — это понятно, но это уже не рефакторинг ни в каком виде.
Это аналог фактически переписывания системы с нуля, в большинстве случаев. Ну и подобные переезд будет одинаково неподъемен что для микросервисов что для монолита.

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

VC>>Происходит по-разному, зависит от той самой "политической воли"

SD>Думаю, на этом и сойдемся

SD>Монолит, микросервисы... как в "Армаггедоне", "Русская электроника, американская электроника... все сделано на Тайване!"

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

Скорее не "долг отдали", а ввели законы, запрещающие давать в долг под процент выше фиксированного .

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

C>Например, ядро AWS переписали с монолита на сервисную систему. С тех пор количество новых фич и улучшение текущих зашкаливает, даже следить сложно.

А как планировали жить с этим монолитом с самого начала интересно? Т.е. n-ое количество крутых серверов для HA?

VC>Большинство компаний сейчас не держит своей инфраструктуры как таковой, аутсорсит ее в какой-нибудь AWS или там GCP — пусть у них голова болит.

В таком варианте принимается. Только надо понимать, во сколько это все обходится. Я тут как раз сейчас должен занимается чем-то подобным, и маржа на этом самом "аутсорсинге" очень впечатляет. Нормальная такая пратика, нарезАть серверы за $400/мес по 32 пода, и каждый продавать поа по $60/мес (дешевые DigitalOcean) или ~$120/мес (AWS).

VC>Ну во всяком случае нижний уровень этой инфраструктуры. Все что поверх этого это уже чем девопсы занимаются — развертывание, масштабирование, обвязка всякими логгингами, трейсингами, мониторингами и проч.

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

И так каждые 3-4 месяца.

VC>Пример плиз... Что за проекты высочайшей сложности от рефакторинга инфраструктуры (рефакторинг инфраструктуры это оксюморон какой-то как по мне).

Один пример — переезд с bare metal и как следует оптимизированного софта для вполне конкретного metal на некую generic cloud provider infra. Хотя, эх, если б на generic, а то ведь чаще всего не на generic, а "вот ту, на которую у нас есть лицензия, и которую мы уже оплачиваем".

VC>Если речь вообще про смену скажем одной облачной инфраструктуры на другую — это понятно, но это уже не рефакторинг ни в каком виде.
VC>Это аналог фактически переписывания системы с нуля, в большинстве случаев. Ну и подобные переезд будет одинаково неподъемен что для микросервисов что для монолита.

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

VC>Скорее не "долг отдали", а ввели законы, запрещающие давать в долг под процент выше фиксированного .

Нет-нет, именно что "долг отдали".
Сначала набрали много в долг (наделали "макаронных связей" в монолите).
Потом решили перебраться на микросервисы, и в процессе этого переезда, само собой, вынуждены были эти API привести в сколь-нибудь подобие порядка (то бишь отдали тех. долг — в этом, собственно, и состоит force function микросервисов).
Затем с новыми силами говнокодили ускоренно развивали продукт.

На выходе — распределенный монолит. Даже более сложная схема, чем просто монолит.

	Скрытый текст
	На этом месте неплохо бы зайти на очередной виток спирали, с еще более новым баззвордом, ценность которого, как обычно, будет заключаться в вызове необходимой "политической воли" для возврата хотя бы части тех. долга. Кто готов придумать термин? Такая ведь отличная возможность вписать имя в историю. Что будет после микросервисов? Если что, service mesh не считается, я бы вообще это называть service spaghetti. Ибо mesh ведь и есть спагетти.

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

C>>Например, ядро AWS переписали с монолита на сервисную систему. С тех пор количество новых фич и улучшение текущих зашкаливает, даже следить сложно.
S>А как планировали жить с этим монолитом с самого начала интересно? Т.е. n-ое количество крутых серверов для HA?
Ага. В одном большом проекте был маршрутизатор, система защиты от DDoS, и реализация некоторых сервисов. Оно работало в нескольких режимах на кластерах.

Ошибку такого подхода поняли достаточно быстро, но полный переход на сервисы занял что-то около 10 лет.

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

SD>Теперь представь, что какой-то особо ретивый инженер заявил "а я свой микросервис хочу писать на расте, делайте мне развертывание, масштабирование, и прочие логгинги, а еще не забудьте про удобства разработки". Ну ладно, одного-то может просто лесом пошлют. Но теперь представь, завтра приходят и говорят "мы тут купили стартам рога-и-копыта, у него классный продукт, который дубликат нашего, но на другом стеке, сделайте интеграцию, и чтоб ничего не сломалось".
Ну вот я прямо недавно этим занимался из-за вот этого:
https://www.renewableenergyworld.com/solar/aurora-solar-strengthens-commercial-offering-with-acquisition-of-helioscope/#gref

Совсем разные стеки, но у обоих компаний сервисная архитектура. Так что замена системы управления журналами, распределённой трассировки, миграция БД и прочее заключалась просто в большом количестве исправлений в конфигах.

SD>Один пример — переезд с bare metal и как следует оптимизированного софта для вполне конкретного metal на некую generic cloud provider infra. Хотя, эх, если б на generic, а то ведь чаще всего не на generic, а "вот ту, на которую у нас есть лицензия, и которую мы уже оплачиваем".
Ну значит, не надо такой софт использовать.

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

C>>С тех пор количество новых фич и улучшение текущих зашкаливает, даже следить сложно.
SD>Это потому, что фичи стали микроскопические. Примерно как SEO-странички, раньше обзор был из одной длинной страницы, теперь же 12 коротеньких.
Хм. Нет. См.: EFS, например. Или Serverless DB.

C>>При хорошем управлении, количество дубликатов остаётся небольшим.
SD>Возвращаемся к вопросу о "политической воле". Собственно, в нее, волю, все всегда и упирается.
Да. Но в монолите никакая воля не спасает.

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

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

C>>Например, в AWS делали рефакторинг авторизации — переходили на "service linked role" вместо "injection token" во всех внутренних сервисах. Это делалось так:
SD>Дай угадаю, тебе не приходилось долго работать в инфраструктуре. Конечно, тем кто не работает над инфрой, все видится как "просто и прекрасно".
Мимо. Я вообще почти всю профессиональную жизнь занимаюсь инфраструктурой.

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

C>>3. Все постепенно переходят на новый механизм. После исчезновения всех своих сервисов из "отчёта позора", каждая команда устраивает праздник с пиццей и пивом.
SD>Это в теории, а на практике, у каждой команды возникает своя отписка из серии "у нас другие приоритеты", "у нас нет ресурство" и т.п..
Необходимость соблюдать общие OKR донесут во время профилактических мероприятий. После чего приоритеты ВНЕЗАПНО меняются.

C>>5. Каждый месяц профилактические мероприятия становятся всё строже.
C>>6. Успех.
SD>В теории так, но на практике все упирается в post-completion error, когда все вроде бы доложили "мы перешли!", но старый сервис удалить нельзя, т.к. где-то там остались какие-то легаси системы, и никто не работает над их выкашиванием из прода.
Эти сервисы передаются тем, кто компетентен. Менеджеры, которые получили повышения из команды этих сервисов, получают втык.

Тут как раз всё очень просто. Есть сервис, его авторы известны. Так что нет никаких оправданий вида: "а мы эти классы не писали, это команда XXXXX всё виновата, мы их просто потом доработали".

SD>Часто случается, что менеджменту доложили "мы все сделали", те далее по цепочке передали до самого верха, где решение принималось. А то, что на самом деле старая система никуда не делась, менеджменту проверить уже нет возможностей, слишком уж менеджмент удален от тех, кто работает в поле.
То есть? Отчёт есть. Он простой и объективный, так что и OKR получается простой и бинарный. Высший менеджмент прекрасно такие вещи понимает.

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

VC>>Большинство компаний сейчас не держит своей инфраструктуры как таковой, аутсорсит ее в какой-нибудь AWS или там GCP — пусть у них голова болит.

SD>В таком варианте принимается. Только надо понимать, во сколько это все обходится. Я тут как раз сейчас должен занимается чем-то подобным, и маржа на этом самом "аутсорсинге" очень впечатляет. Нормальная такая пратика, нарезАть серверы за $400/мес по 32 пода, и каждый продавать поа по $60/мес (дешевые DigitalOcean) или ~$120/мес (AWS).

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

VC>>Ну во всяком случае нижний уровень этой инфраструктуры. Все что поверх этого это уже чем девопсы занимаются — развертывание, масштабирование, обвязка всякими логгингами, трейсингами, мониторингами и проч.

SD>Теперь представь, что какой-то особо ретивый инженер заявил "а я свой микросервис хочу писать на расте, делайте мне развертывание, масштабирование, и прочие логгинги, а еще не забудьте про удобства разработки". Ну ладно, одного-то может просто лесом пошлют. Но теперь представь, завтра приходят и говорят "мы тут купили стартам рога-и-копыта, у него классный продукт, который дубликат нашего, но на другом стеке, сделайте интеграцию, и чтоб ничего не сломалось".

SD>И так каждые 3-4 месяца.

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

VC>>Пример плиз... Что за проекты высочайшей сложности от рефакторинга инфраструктуры (рефакторинг инфраструктуры это оксюморон какой-то как по мне).

SD>Один пример — переезд с bare metal и как следует оптимизированного софта для вполне конкретного metal на некую generic cloud provider infra. Хотя, эх, если б на generic, а то ведь чаще всего не на generic, а "вот ту, на которую у нас есть лицензия, и которую мы уже оплачиваем".

Здесь-то как раз не должно быть больших проблем, так как нет архитектурной завязки на сервисы конкретного клауд провайдера.
Любые провайдеры предоставляют и bare metal тоже, так что физически перетащить и потом адаптировать к новой инфраструктуре можно постепенно.

VC>>Если речь вообще про смену скажем одной облачной инфраструктуры на другую — это понятно, но это уже не рефакторинг ни в каком виде.
VC>>Это аналог фактически переписывания системы с нуля, в большинстве случаев. Ну и подобные переезд будет одинаково неподъемен что для микросервисов что для монолита.

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

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

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

VC>>Скорее не "долг отдали", а ввели законы, запрещающие давать в долг под процент выше фиксированного .

SD>Нет-нет, именно что "долг отдали".
SD>Сначала набрали много в долг (наделали "макаронных связей" в монолите).
SD>Потом решили перебраться на микросервисы, и в процессе этого переезда, само собой, вынуждены были эти API привести в сколь-нибудь подобие порядка (то бишь отдали тех. долг — в этом, собственно, и состоит force function микросервисов).
SD>Затем с новыми силами говнокодили ускоренно развивали продукт.

Если бы просто отдали — это не так интересно. Интересно чтобы новая архитектура препятствовала накоплению нового тех долга (что микросервисы в какой-то степени и делают, и что я и имел в виду сказав про "запрет давать в долг").

SD>На выходе — распределенный монолит. Даже более сложная схема, чем просто монолит.

Ну это не обязательно, чтоб распределенный монолит получить это еще постараться надо. Это как — сервисы завязаны один на другой и не могут деплоиться независимо?
Разные сервисы работают с одной и тем же слоем хранения? Ну как бы сделать то такое конечно можно, но кто в здравом уме будет?

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


SD>[cut]
SD>На этом месте неплохо бы зайти на очередной виток спирали, с еще более новым баззвордом, ценность которого, как обычно, будет заключаться в вызове необходимой "политической воли" для возврата хотя бы части тех. долга. Кто готов придумать термин? Такая ведь отличная возможность вписать имя в историю.
SD>Что будет после микросервисов?

Serverless, это разве не оно?