Здравствуйте, SkyDance, Вы писали:
SD>Я правильно понимаю, что если раньше тем самым "другим людям" (и "нормальным девопсам") достаточно было просто диктовать архитектуру и не давать руководству заменять дешевых разработчиков на дорогих, то сейчас вдогонку к тому нужно еще успеть уследить на 100.000 индусов, чтобы те не проторчали кишки во все стороны?
Нет, не правильно. Следить за 100000 индусов нужно в любом случае, но в микросервисной архитектуре это делать намного проще.
SD>Понимаю, что линейным менеджерам это только на руку, но с точки зрения компании выигрыш неочевиден.
Тем не менее аутсорс в Индию продолжает цвести буйным цветом.
Здравствуйте, SkyDance, Вы писали:
VC>>С микросервисами из-за на порядки меньшего размера, рефакторинг и приведение кода в порядок не становится запретительно дорогой операцией (как с монолитом) и может проводиться более-менее регулярно.
SD>Рефакторинг одного микросервиса и в самом деле становится дешевле. Но их же много, причем, как уже было отмечено выше, вдобавок еще и есть варианты того же "с перламутровыми крылышками". Поэтому сравнивать нужно сравнимое. Рефакторинг монолита правильно сравнивать с рефакторингом всех микросервисов сразу.
SD>Плюс еще тонкий момент с тестированием. Как уже было указано выше, чтобы иметь возможность хоть как-то тестировать "свой" сервис, нужно иметь возможность запустить либо тестовые экземпляры, либо моки всех зависимостей (хотя для e2e этот вариант может и не подойти). Как правило поднять экземпляр монолита проще, чем все зависимости "перламутровых пуговиц" микросервисов, где каждый кто во что горазд.
SD>Короче говоря, серебряной пули нет. И так и этак нужна железная воля руководства, чтобы держать возникающую на пустом месте сложность в узде. А это, однако, редко встречается, ибо, как тоже уже было указано, горизонты планирования большинства контор сейчас от силы год, а реально еще короче. Это пару веков назад можно было себе представить проект на всю жизнь, где можно было держать марку качества. А сейчас если продукт не скатился в <...> за двадцать лет — это, однако, круто!
Рефакторинг всех микросервисов сразу требуется куда реже (если их границы были выбраны правильно изначально). Может быть, да, в случае когда какая-то глобальная система меняется, что-нибудь типа авторизации / аутентификации, затрагивающее все микросервисы.
Или там переезд на другой сторидж, или другую систему очередей. Это вообще не рефакторинг уже, а редизайн, a редизайн любой большой системы это сильно дорогостоящая операция.
Я кстати совсем не уверен что в случае микросервисов это обойдется дороже — там чаще всего будет возможен вариант редизайна по частям, что в случае с монолитом обычно нереально.
Если же говорить про типовой рефакторинг для уменьшения tech debt, то это то что в монолите довольно часто просто нереально.
Просто потому что там с какого-то момента невозможно рефакторить "по частям", а глобальный рефакторинг такой же дорогостоящий как и редизайн.
Тестирование микросервисов более сложное, тут вопросов нет. То есть и в том и в другом подходе есть слабые стороны. Но, если развитие системы планируется надолго, монолит — это все-таки рискованная штука на длительном промежутке времени.
Я пока не видел ни одного крупного монолита, который бы развивался > 10 лет и не скатился в УГ. Правда, если честно, микросервисов которые столько бы прожили, тоже пока не видел .
Это все-таки более новые веяния, пока тому что я видел нет столько лет.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, VladiCh, Вы писали:
VC>>С микросервисами из-за на порядки меньшего размера, рефакторинг и приведение кода в порядок не становится запретительно дорогой операцией (как с монолитом) и может проводиться более-менее регулярно.
M>Зато рефакторить интерфейсы между сервисами становится практически невозможно поскольку для этого надо распинать кучу соседних команд. А у них у всех лапки и они ничего не хотят делать.
Интерфейсы между сервисами как правило никто не рефакторит, просто выкатывают новую версию интерфейса (или новый сервис) для замены старой (старого сервиса).
Это во всяком случае более поэтапный и управляемый процесс, чем рефакторинг чего-то в монолите.
И я не вижу в чем тут невозможность — такое происходит сплошь и рядом.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Круто. Начинали с того что микросервисы нужны для того чтобы снизить требования к квалификации разработчиков (это design goal такой). А закончили тем что они требуют более выской квалификации. НС>>
НС>>it allows organizations developing software to grow fast, and big, as well as use off the shelf services easier. Communication requirements are less.
НС>>https://en.wikipedia.org/wiki/Microservices НС>>Вобщем, ты явно что то путаешь.
S>Это не maxkar, похоже, путает -- вот тут, по ссылке из ссылки выше, пишут в cons для микросервисов: S>
S>But the switch to microservices comes with its fair share of costs, particularly when it comes to app monitoring and the toll it can take on developers. Adopters will have to consider factors such as:
S> Team expertise: The benefits of microservices are moot without a prepared staff. You should assess the skills of your team members before moving forward with a microservices architecture.
S> Testing and monitoring: Once you break apps into components, you'll have more moving parts to track and eventually fix. Without the right testing and monitoring tools in place, things could quickly spin out of control.
S>Можно сказать, что design goal не удался.
Для того чтобы перелезть на микросервисную архитектуру, нужна большая подготовительная работа — автоматизация создания этих самых микросервисов и управления ими — с мониторингом, логгингом, алертами, всяческими настройками автоскейлинга и т.п.
Это требует интеграции кучи различных систем. Если этого нет и делать это все вручную для каждого микросервиса, то можно во всех этих мелочах закопаться и общий результат будет печален.
Поэтому сейчас важность девопсов сильно возросла, потому как крупные компании всю эту работу автоматизируют.
Но, если эта автоматизация есть, то с собственно разработчиков микросервисов эта вся нагрузка снимается, им как правило это все настраивать не нужно и оно работает из коробки.
Здравствуйте, SkyDance, Вы писали:
C>>Пусть существуют. Компания большая, выдержит. SD>И то правда. В самом деле, так даже лучше, headcount больше, можно назваться "менеджером 3 команд". Это ничего, что там 3 дубликата одного и того же, зато 15 человек вместо 5. Более важный начальник, уже не просто менеджер, а менеджер менеджеров.
Ну да. А что делать? Хотя бы таким образом этот "важный начальник" ограничен своей песочницей, и не мешает развивать другие проекты.
Как минимизировать такую ситуацию организационными методами — это уже вопрос для высшего менеджмента.
SD>Но команда "Б" пришла не для этого, им свое хочется.
Ну и что? Смысл сервисной архитектуры в том, что она работают даже в неоптимальных организационных условиях. А неоптимальные условия будут в любой большой компании, это просто закон природы такой.
Да, возможно теряем производительность разработчиков за счёт дублирования функционала, но при этом выигрываем время за счёт того, что уменьшаем зависимости между командами.
SD>PS: если что, мой сын тоже ведь считает, что я ему исключительно по идеологическим причинам не даю круглосуточно сидеть в онлайн-играх, жрать чипсы и прочую дрянь. Ужасная идеология! А, вот еще, зубы чистить — ну просто высшее проявление идеологии. Он ведь уже несколько раз проверял, не почистил — ничего не случилось. Зачем вообще чистить, кроме как по идеологическим причинам.
Да, там была примерно та же причина: "Надо чистить зубы, и зубной врач не будет нужен! Потому поддержку зубных больниц мы добавлять не собираемся! И пофиг, что они на практике таки нужны".
Здравствуйте, VladiCh, Вы писали:
S>>Это не maxkar, похоже, путает -- вот тут, по ссылке из ссылки выше, пишут в cons для микросервисов: S>>
S>>But the switch to microservices comes with its fair share of costs, particularly when it comes to app monitoring and the toll it can take on developers. Adopters will have to consider factors such as:
S>> Team expertise: The benefits of microservices are moot without a prepared staff. You should assess the skills of your team members before moving forward with a microservices architecture.
S>> Testing and monitoring: Once you break apps into components, you'll have more moving parts to track and eventually fix. Without the right testing and monitoring tools in place, things could quickly spin out of control.
S>>Можно сказать, что design goal не удался. VC>Для того чтобы перелезть на микросервисную архитектуру, нужна большая подготовительная работа — автоматизация создания этих самых микросервисов и управления ими — с мониторингом, логгингом, алертами, всяческими настройками автоскейлинга и т.п. VC>Это требует интеграции кучи различных систем. Если этого нет и делать это все вручную для каждого микросервиса, то можно во всех этих мелочах закопаться и общий результат будет печален. VC>Поэтому сейчас важность девопсов сильно возросла, потому как крупные компании всю эту работу автоматизируют. VC>Но, если эта автоматизация есть, то с собственно разработчиков микросервисов эта вся нагрузка снимается, им как правило это все настраивать не нужно и оно работает из коробки.
Безусловно, нагрузка деплоймента и прочее code as infrasuructure с разработчика снимается, но как это сказывается
на требованиях и знания, которые я написал выше? Dockerfile писать надо? Надо. Т.е. надо изучать docker. Писать
код, который корректно и грамотно работает с локальным состоянимем, полностью с нуля развитие и поддержка локального
хранилища, а раньше была одна (край две) бд со спец. людьми на них. Теперь изоляция по хранилищу. Т.е. я ни разу
не говорю, что микросервисная арх-ра плоха. Она предъявляет большие требования к квалификации чем
монолит. Что-то стало делать проще, бизнес код стал проще, но у всего есть цена,
всяческих объвязок и прочей инфраструктуры стало больше.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Или нет. S>>Или да. НС>Т.е. аргументов у тебя нет. ЧТД.
Сложно аргументировать "Или нет", тем более если резать по цитатам -- целиком было:
Или да. Сначала пишут манифесты, потом начинается хайп, потом всплывает куча проблем что не всем и не всегда это
надо. Квалификация программистов, оказывается, нужна выше, а не ниже и т.д.
S>>Прежде как, а оно вообще надо? НС>Что вообще надо? Архитектуру какую то? Обычно надо.
Но почему сразу микросервисную?
S>>Допустим, а если разработчики монолита будут думать в терминах api, а не интерфейсов? НС>И как ты это проконтролируешь?
А как в мире разработки ПО что-либо контролируется? CR, wiki.
S >>В чем тогда выгода микросервисов? НС>В том что испохабить всю систему из одного микросервиса намного сложнее, чем из модуля монолита.
В целом справедливо, согласен. Доступность повышается.
НС>>>Почти все это нужно и для монолита. Ты же не сравниваешь всерьез микросервисы с системой, состоящей из одного сервера, надеюсь? S>>В целом сравниваю. НС>Тогда не вижу предмета для разговора.
Хорошо, не одна машина, а 2-3 машины. Что поменяется?
Почему сразу нет? Частный случай из определения по ссылке.
Monolithic software is designed to be self-contained; components of the program are interconnected and interdependent rather than loosely coupled as is the case with modular software programs. In a tightly-coupled architecture, each component and its associated components must be present in order for code to be executed or compiled.
Еще вопрос -- вот у нас монолит, с кучей dll и отличнейший loose coupling, продуманный api, интерфейсы и т.п.
Т.е. один exe и много dll, чем это не микросервисная арх-ра?
S>>Опыт работы над небольшими проектами, группой 2-3 человек, на 1-2 года работы. Иногда группы из 4-5 человек. S>>Взгляд со стороны, а не изнутри. НС>Ну то есть все сервисы исключительно single instance?
По-разному: от ui desktop, до обработчиков в сервиcной арх-ре с rmq. Т.е. экземпляров много (процесса), но машина одна.
Здравствуйте, Sharov, Вы писали:
НС>>Т.е. аргументов у тебя нет. ЧТД.
S>Сложно аргументировать "Или нет"
Аргументировать следовало вот это:
Люди пишут эти манифесты опробовав на маленькой выборке, теоретики типа.
На поверку пока что теоретиком оказался ты, а не они.
S>>>Прежде как, а оно вообще надо? НС>>Что вообще надо? Архитектуру какую то? Обычно надо. S>Но почему сразу микросервисную?
Кто сказал что сразу микросервисную?
S>>>Допустим, а если разработчики монолита будут думать в терминах api, а не интерфейсов? НС>>И как ты это проконтролируешь? S>А как в мире разработки ПО что-либо контролируется?
Ты это серьезно спрашиваешь?
НС>>Тогда не вижу предмета для разговора. S>Хорошо, не одна машина, а 2-3 машины. Что поменяется?
2-3 машины это уже распределенная система.
S>>> Опять же, надо определиться под тем, что называется монолит. Много кода в едином адресном пространстве -- это оно? НС>>Нет. https://whatis.techtarget.com/definition/monolithic-architecture S>Почему сразу нет?
Потому что монолит это про код, а не про количество инстансов.
S>Еще вопрос -- вот у нас монолит, с кучей dll и отличнейший loose coupling, продуманный api, интерфейсы и т.п. S>Т.е. один exe и много dll, чем это не микросервисная арх-ра?
Тем что связность модулей намного выше. Зачем задавать один и тот же вопрос несколько раз, если уже написан ответ?
НС>>Ну то есть все сервисы исключительно single instance? S>По-разному: от ui desktop, до обработчиков в сервиcной арх-ре с rmq. Т.е. экземпляров много (процесса), но машина одна.
Здравствуйте, VladiCh, Вы писали:
VC>Для того чтобы перелезть на микросервисную архитектуру, нужна большая подготовительная работа — автоматизация создания этих самых микросервисов и управления ими — с мониторингом, логгингом, алертами, всяческими настройками автоскейлинга и т.п.
Есть готовые решения. Если нет желания сразу много инвестировать в микросервисную инфраструктуру — тот же istio отличный пример.
Здравствуйте, VladiCh, Вы писали:
VC>Интерфейсы между сервисами как правило никто не рефакторит, просто выкатывают новую версию интерфейса (или новый сервис) для замены старой (старого сервиса). VC>Это во всяком случае более поэтапный и управляемый процесс, чем рефакторинг чего-то в монолите. VC>И я не вижу в чем тут невозможность — такое происходит сплошь и рядом.
Ровно поэтому API между сервисами и не рефакторят, что бесполезно. Выкатишь новую версию, а ресурсов ссадить пользователей со старой силенок не хватит. В результате поддерживаешь две версии непонятно зачем. И я не говорю про более серьезные преобразования, типа объединить два сервиса в один или перенести часть функционала в другой сервис. Ни один вменяемый менеджер не возьмет в свой отдел лишний кусок работы и не отдаст крайне необходимый кусок ресурсов. Поэтому, кстати, архитектура системы и копирует архитектуру организации, как еще во времена Брукса заметили. Мелкие рефакторинги в своей песочнице, пожалуйста, хоть все на хаскель перепишите. А что-то более серьезное завязнет еще на этапе согласования.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>> Т.е. надо изучать docker. НС>Здесь нет специфики микросервисов.
Серьезно, а специфика чего здесь есть? Монолитов?
S>>Писать код, который корректно и грамотно работает с локальным состоянимем, НС>Здесь нет специфики микросервисов.
Как же нет, когда надо писать код так, чтобы можно было как минимум легко перезапустить сервис.
Т.е. не только бизнес логика, а еще специфика окружения -- распределенная система.
S>> полностью с нуля развитие и поддержка локального хранилища, НС>Вообще не понял о чем ты.
На этом форуме писали, что суть микросервисов это изоляция хранилища, как осн. источник связности.
Соотв. каждый микросервис имеет свое хранилище.
S>>Она предъявляет большие требования к квалификации чем монолит. НС>К кому то большие, к кому то меньше. В девопсам большие, к разработчикам меньшие.
К девопсам не то что больше, они появились благодаря этому подходу.
S>> Что-то стало делать проще, бизнес код стал проще НС>Бизнес-код остался таким же. Стал проще код интеграционный.
Почему проще, при монолитах он был сложнее? Бизнес код остался таким же, но писать его надо
с учетом совершенно другой, ненадежной, среды.
S>>, но у всего есть цена, всяческих объвязок и прочей инфраструктуры стало больше. НС>И? Ты к чему ведешь? Что микросервисы не серебряная пуля? Да кто бы сомневался.
Я ни к чему не веду. Мы начали с полярного понимания к требованиям квалификации программистов микросервиса.
Таки требования в случае мс к ним больше.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, VladiCh, Вы писали:
VC>>Интерфейсы между сервисами как правило никто не рефакторит, просто выкатывают новую версию интерфейса (или новый сервис) для замены старой (старого сервиса). VC>>Это во всяком случае более поэтапный и управляемый процесс, чем рефакторинг чего-то в монолите. VC>>И я не вижу в чем тут невозможность — такое происходит сплошь и рядом.
M>Ровно поэтому API между сервисами и не рефакторят, что бесполезно. Выкатишь новую версию, а ресурсов ссадить пользователей со старой силенок не хватит.
Это издержки распределенной системы. Но в то же время и ее преимущество — она заставляет делать версионность API. В монолите в теории можно отрефакторить всю систему за раз, но на практике такие идеи заметают под ковер,
потому что любые крупные изменения или останавливают разработку везде, или мерж будет адский и сломает половину системы.
M>В результате поддерживаешь две версии непонятно зачем. И я не говорю про более серьезные преобразования, типа объединить два сервиса в один или перенести часть функционала в другой сервис. Ни один вменяемый менеджер не возьмет в свой отдел лишний кусок работы и не отдаст крайне необходимый кусок ресурсов.
Понятно зачем. Насколько долго будет старая версия жить — ну это уже от конкретного случая зависит и конкретной организации. Если есть политическая воля, про которую выше говорилось... (и тут ее нужно гораздо меньше, чем в случае постоянного контроля за tech debt).
Нужно согласование между всеми командами, в случае их большого количества это непростой процесс, но для этого есть специальные люди.
M>Поэтому, кстати, архитектура системы и копирует архитектуру организации, как еще во времена Брукса заметили.
Это не баг а фича в данном случае. Одна из причин почему вообще микросервисный подход работает.
M>Мелкие рефакторинги в своей песочнице, пожалуйста, хоть все на хаскель перепишите. А что-то более серьезное завязнет еще на этапе согласования.
Ну так... Как я и сказал, это и есть одна из целей — команды получают контроль над изменениями в своих песочницах, хотя бы.
С монолитным подходом этого нет.
Здравствуйте, Sharov, Вы писали:
S>>> Т.е. надо изучать docker. НС>>Здесь нет специфики микросервисов. S>Серьезно, а специфика чего здесь есть? Монолитов?
Здесь специфика современных средств деплоймента. Просто в микросервисах оно критично, а с монолитами еще можно пытаться жить по старинке, с виртуалками. Но, в целом, для новых проектов однозначно следует предпочесть контейнеры, вне зависимости от архитектуры.
S>>>Писать код, который корректно и грамотно работает с локальным состоянимем, НС>>Здесь нет специфики микросервисов. S>Как же нет, когда надо писать код так, чтобы можно было как минимум легко перезапустить сервис.
Возможность перезапуска критична для любой архитектуры, включая монолиты. Тут скорее сервисы позволяют сэкономить, отказавшись от пула воркеров внутри веб-сервера в пользу пула подов. Это упрощает сервис, так как вместо танцев с бубном со всякими внешними средствами хранения стейтов и хаками по запуску фоновых задач у условиях воркера, которого в любой момент может грохнуть веб-сервер мы просто пишем обычное консольное приложение с обычным стейтом, инициализируемым при стартапе.
S>Т.е. не только бизнес логика, а еще специфика окружения -- распределенная система.
Еще раз — распределенная система это не эквивалентное понятие микросервисам. Распределенность диктуется в первую очередь твоими задачами, и если требования по перфу выше того, что способна одна машина — у тебя просто других вариантов нет, при любой архитектуре.
А вот если тебе хватает с запасом одного сервера, и нет никаких требований HA и запрета на даунтайм даже при обновлении версии, то микросервисы точно не для этого кейса. И для маленькой команды на весь продукт микросервисы тоже негодный выбор.
S>>> полностью с нуля развитие и поддержка локального хранилища, НС>>Вообще не понял о чем ты. S>На этом форуме писали, что суть микросервисов это изоляция хранилища,
Не видел такого, чтобы именно суть. Но если писали, то это глупость. Суть микросервисов — выделение сравнительно небольшого функционала в сервис, связанный с остальным функционалом только через REST API (grpc, message bus etc). А изоляция хранилищ уже следствие, так как при расшаривании хранилища между несколькими сервисами между ними появляются плохо контролируемые паразитные связи.
При этом никакого абсолютного запрета нет. Если у тебя уже есть legacy БД с долгой историей разработки, толстым слоем изоляции средствами БД (хранимки и вьюхи) и целой кучей заинтегрированного через нее софта (совершенно типичная ситуация для крупных банков со своими отделами разработки, к примеру), то нужно быть безумцем чтобы пытаться нарезать ее на микрокусочки.
С другой стороны, даже для монолитов, состоящий из пары-тройки типов сервисов взаимодействие через общую БД довольно спорный выбор, так как порождает кучу неожиданных проблем при изменении схемы той БД. У меня прошлый проект как раз и был монолит с тремя типами узлов (и один из типов еще собирался из плагинов, эдаких куберовских подов для бедных). И вот там как раз была интеграция через общую БД. И вот эта интеграция была однозначно одним из основных источников проблем, так что ее долго и больно приходилось изживать.
S>>>Она предъявляет большие требования к квалификации чем монолит. НС>>К кому то большие, к кому то меньше. В девопсам большие, к разработчикам меньшие. S>К девопсам не то что больше, они появились благодаря этому подходу.
Нет. Девопсы появились в основном в связи с усложнением CI и появлением CD.
Из википедии:
In 2009, the first conference named devopsdays was held in Ghent, Belgium. The conference was founded by Belgian consultant, project manager and agile practitioner Patrick Debois.
2009 это самый расцвет SOAP и прочего аналогичного стаффа. А о микросервисах всерьез заговорили где то в районе 2012.
S>>> Что-то стало делать проще, бизнес код стал проще НС>>Бизнес-код остался таким же. Стал проще код интеграционный. S>Почему проще,
Потому что связи проще и беднее. Это вынуждает больше внимания уделять REST API. Как следствие, использовать среднепотолочный REST API сильно проще, чем среднепотолочный языковый фреймворк аналогичной сложности.
S>Бизнес код остался таким же, но писать его надо с учетом совершенно другой, ненадежной, среды.
Монолит точно так же ненадежен, и даже еще менее (ты вот явно не заморачиваешься НА и хелсчеками). ИМХО ты опять путаешь распределенные решения и микросервисы.
Опять же, для совсем ленивых есть istio, который утаскивает все заморочки с ненадежностью типа ретраев на инфраструктурный уровень, оставляя код без этих заморочек.
S>>>, но у всего есть цена, всяческих объвязок и прочей инфраструктуры стало больше. НС>>И? Ты к чему ведешь? Что микросервисы не серебряная пуля? Да кто бы сомневался. S>Я ни к чему не веду. Мы начали с полярного понимания к требованиям квалификации программистов микросервиса. S>Таки требования в случае мс к ним больше.
Ты не смог пока этого доказать. У тебя какое то очень странное понимание того, что требуется именно от программистов в случае микросервисов. В то время как на практике код типичного микросервиса кардинально проще аналогичного модуля монолита, сложность зачастую на уровне студенческого курсового и примерно такие же требования по качеству реализации. Сложность, она не в том чтобы прочитать какой нибудь простенький rest guidlines или прочий толмуд про основные шаблоны микросервисов. Сложность в том чтобы написать простой и качественный код, и вот тут монолиты однозначно в большом проигрыше, просто в силу объема и связности кодовой базы, а так же потенциальным эффектам от проблем в ней. И чем сложнее система в целом, тем больше микросервисы выигрывают в плане требований к квалификации над монолитом.
Здравствуйте, Miroff, Вы писали:
M>Ровно поэтому API между сервисами и не рефакторят, что бесполезно. Выкатишь новую версию, а ресурсов ссадить пользователей со старой силенок не хватит.
Странное заявление. Все зависит от конкретных команд. У нас, к примеру, есть вполне формальная политика в таких ситуациях: в версии А старый интерфейс объявляется deprecated (что приводит к исчезновению из swagger и пометке Obsolete/Deprecated в штатных клиентах). А в следующей мажорной версии API перестает поддерживаться. Это если речь про внутрикластерные API.
С публичными API посложнее, но их обычно сильно меньше. Да и с публичными тоже со временем процесс происходит, достаточно посмотреть на тот же MS, Google или Dropbox. Просто процесс занимает больше времени, 1-2 года обычно.
VC>Рефакторинг всех микросервисов сразу требуется куда реже (если их границы были выбраны правильно изначально).
Что считать рефакторингом?
И где граница работы команды? Вот, скажем, может ли команда выбирать технологии для постройки микросервиса? А до какого уровня? А можно вместо Linux использовать FreeBSD? А вместо виртуалок — bare metal?
Тут-то и находит коса на камень. Оказывается, что в каком-то месте "микросервисы" лежат поверх существующей инфраструктуры. И чем "микрее" сервисы, тем толще получается эта самая "инфра".
Но ведь ей, инфре, тоже нужно развиваться. А для этого нужно и рефакторинг производить. Да, в инфре. Это равносильно рефакторингу всех микросервисов сразу. Я именно про такой рефакторинг, а не когда в каком-то одном микросервисе "рефакторят" MySQL на MariaDB.
VC>Я пока не видел ни одного крупного монолита, который бы развивался > 10 лет и не скатился в УГ. Правда, если честно, микросервисов которые столько бы прожили, тоже пока не видел .
О, золотые слова Как обычно, все упирается не в технологии, а в людей и масштабы.
C>Ну да. А что делать? Хотя бы таким образом этот "важный начальник" ограничен своей песочницей, и не мешает развивать другие проекты. C>Как минимизировать такую ситуацию организационными методами — это уже вопрос для высшего менеджмента. C>Да, возможно теряем производительность разработчиков за счёт дублирования функционала, но при этом выигрываем время за счёт того, что уменьшаем зависимости между командами.
То есть с помощью микросервисов можно "масштабировать компанию". Но не в плане возможностей. А всего лишь в количестве наемных работников, суть расходов на R&D. Сам продукт при этом поначала будет развиваться быстрее. Это факт, ибо развитие идет в долг (создаются копии, параллельные сервисы, дубликаты инфры и т.п.). Но потом наступает довольно резкая остановка в развитии, потому что система превращается в распределенный монолит, который развивать становится еще сложнее. И вот тогда-то приходят молодые конкуренты, которые пока еще на предыдущей стадии ("резкий рост").
Да, знакомо.
Но называть это "правильным" или "хорошим" подходом я бы не стал.
M>Ровно поэтому API между сервисами и не рефакторят, что бесполезно. Выкатишь новую версию, а ресурсов ссадить пользователей со старой силенок не хватит. В результате поддерживаешь две версии непонятно зачем.
Именно так все и происходит
Разве что найдутся в компании герои, которые по сути пожертвуют себя ради вычистки конюшен, просто из чувства прекрасного. Но — только один раз, потому что будучи похлопанными по плечу "ма-ла-дец" за совершенный подвиг, но никак не будучи за это вознагражденными, такие герои теряют мотивацию и больше не совершают подвиги (собсно, то самое "выгорание", когда человек старался, стремился, шел — получил пшик и огорчился).
НС>Опять же, для совсем ленивых есть istio, который утаскивает все заморочки с ненадежностью типа ретраев на инфраструктурный уровень, оставляя код без этих заморочек.
Сильное заявление. Сами по себе "ретраи" то еще зло. Работоспособное только в случае идемпотентных изменений или linearisability.
Здравствуйте, SkyDance, Вы писали:
C>>Да, возможно теряем производительность разработчиков за счёт дублирования функционала, но при этом выигрываем время за счёт того, что уменьшаем зависимости между командами. SD>То есть с помощью микросервисов можно "масштабировать компанию". Но не в плане возможностей. А всего лишь в количестве наемных работников, суть расходов на R&D.
В плане возможностей тоже. В качестве примера — практически все облачные провайдеры.
Например, ядро AWS переписали с монолита на сервисную систему. С тех пор количество новых фич и улучшение текущих зашкаливает, даже следить сложно.
SD>Сам продукт при этом поначала будет развиваться быстрее. Это факт, ибо развитие идет в долг (создаются копии, параллельные сервисы, дубликаты инфры и т.п.). Но потом наступает довольно резкая остановка в развитии, потому что система превращается в распределенный монолит, который развивать становится еще сложнее. И вот тогда-то приходят молодые конкуренты, которые пока еще на предыдущей стадии ("резкий рост").
При хорошем управлении, количество дубликатов остаётся небольшим.
SD>Но называть это "правильным" или "хорошим" подходом я бы не стал.
А других нет.
. 
А, вот еще, зубы чистить — ну просто высшее проявление идеологии. Он ведь уже несколько раз проверял, не почистил — ничего не случилось. Зачем вообще чистить, кроме как по идеологическим причинам.
