Здравствуйте, Cyberax, Вы писали: C>Тогда на практике в больших компаниях просто этот компонент переписывают, причём независимо от старой команды.
Не понял, это как? То есть в понедельник приходит команда, которая отвечает за микросервис "верификация телефонного номера", а им говорят: "посоны, теперь у нас две реализации этого микросервиса — ваша, и та, которая с воскресенья в проде" — так что ли?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
C>>Тогда на практике в больших компаниях просто этот компонент переписывают, причём независимо от старой команды. S>Не понял, это как? То есть в понедельник приходит команда, которая отвечает за микросервис "верификация телефонного номера", а им говорят: "посоны, теперь у нас две реализации этого микросервиса — ваша, и та, которая с воскресенья в проде" — так что ли?
Примерно.
Реальный сценарий, который у меня был на практике:
1. Есть сервис (будем считать, что для верификации номеров), который написан и поддерживается Равшаном и Джамшутом из отдела "А". Все вызовы сервиса — синхронные, и могут висеть по 5 минут до получения ответа.
2. Многие клиентские библиотеки от такого немного фигеют, и требуют специально крутить таймауты. Всех это достаёт, и отдел "Б" делает обёртку, которая скрывает синхронный интерфейс за асинхронным фасадом, с поддержкой нотификаций через местную систему сообщений.
3. Обёртка заворачивается в REST-интерфейс и начинает использоваться внутри проектов отдела "Б".
4. Отдел "В", которой тоже осточертели те же проблемы сервиса, замечает этот фасад и просит отдел "Б" дать им доступ к сервису-фасаду. Отдел "Б" соглашается (а чего бы не помочь хорошим людям?).
5. Шаг 4 повторяется несколько раз.
6. Менеджер отдела "Б" замечает, что REST-обёртка сервиса верификации — это уже неплохой внутренний продукт, и нанимает под него менеджера и программистов.
7. Выделенный менеджер и программисты замечают, что вообще-то самим реализовать верификацию не так уж и сложно, и тогда можно избавиться от вызовов к сервису "А" совсем.
Усё. Имеем два сервиса с одинаковой функциональностью. Причём достаточно разнесённые по иерархии менеджмента, так что "дефрагментировать" их никого особо не тянет. Исходный сервис после этого может постепенно умереть своей смертью.
Разные вариации на эту тему видел лично несколько раз. Вариант "вот это, но с перламутровыми крылышками" даже сам писал из-за того, что другая команда по идеологическим причинам не хотела добавлять нужный функционал.
Здравствуйте, maxkar, Вы писали:
G>>Так всетаки микросервисы проще монолитов или сложнее? M>Сложнее. И требуют более высокой кваливикации разработчиков, чтобы начать делать хорошо.
Круто. Начинали с того что микросервисы нужны для того чтобы снизить требования к квалификации разработчиков (это 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.
Вобщем, ты явно что то путаешь.
M>На архитектурном уровне вместе с микросервисами приходит eventual consistency. В монолите можно сделать большую транзакцию, в микросервисах — в целом нет.
Распределенная транзакция с попыткой обеспечить ACID сложнее и требует более высокой квалификации, нежели eventual consistency. Аргумент твой доказывает обратное заявленному.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Круто. Начинали с того что микросервисы нужны для того чтобы снизить требования к квалификации разработчиков (это 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
НС>Вобщем, ты явно что то путаешь.
Я не путаю. В приведенной цитате да и вообще в статье нет ничего про стоимость и квалификацию. Более того, вводный параграф вообще функциональность приложения обходит стороной. Противоречия здесь никакого нет. Можно нанять много разработчиков, они все будут очень-очень заняты. А на выходе — прямо как в анекдоте: "Я могу печатать 600 символов в минуту но получается какая-то фигня". Для того, чтобы все более-менее работало (и работало 24/7) нужна будет квалификация. В другую сторону тоже работает — если получится найти сильных разработчиков в качестве лидеров команд, законченный продукт можно получить быстро.
Да и вообще вообще вся статья писалась по "вражеским" материалам. Например:
A microservice architecture – a variant of the service-oriented architecture (SOA) structural style
Я учил архитектурные стили по Neal Ford и Mark Richards. У них микросеврисы стоят рядом с SOA и не являются её разновидностью (bounded contexts — microservices, infrastructure services & service per business function — SOA). Микросервисы в разновидность SOA очень любят записывать консультанты вроде IBM. Это им нужно, чтобы продавать infrastructure services (общие пользователи и т.п.), которые в микросервисы не вписываются. Еще консультантам очень интересно продать как можно больше консультантов (organization grow fast). В большинстве случаев оплата идет по time & materials, и становится выгодно, чтобы проекты не заканчивались в срок. Если переборщить с communications are less, как раз получится мифический человекомесяц, когда все сервисы есть но не интегрируются друг с другом.
M>>На архитектурном уровне вместе с микросервисами приходит eventual consistency. В монолите можно сделать большую транзакцию, в микросервисах — в целом нет. НС>Распределенная транзакция с попыткой обеспечить ACID сложнее и требует более высокой квалификации, нежели eventual consistency. Аргумент твой доказывает обратное заявленному.
Так в монолите же нет распределения через границы сервисов. А для транзакций внутри монолита (но через разные хранилища) решения разработаны уже давным давно. В JEE/JTA стандартные интерфейсы (javax.transaction.xa) для координатора транзакций были уже 17 лет назад. Поэтому "сложность разработки" сводится к использованию аннотации @Transactional по поводу и без. Настраивается это все один раз в начале проекта знающими людьми. А вот в микросеврисах такая магия не работает. Я вот часто вижу (и на rsdn темы периодически поднимаются), что делают rpc over http вместо rest. Об обработке ошибок даже не задумываются. Ты думаешь, с этими разработчиками можно конструктивно говорить про eventual consistency? А вот в монолите local procedure call прекрасно работает. Инфраструктура с транзакцией разберется если что-то пойдет не так.
Здравствуйте, maxkar, Вы писали:
M>Я не путаю. В приведенной цитате да и вообще в статье нет ничего про стоимость и квалификацию.
Естественно прямо тебе никто не скажет, что эту технологию придумали чторбы эффективнее использовать стадо индусов. Но намек про это вполне прозрачен.
M>А на выходе — прямо как в анекдоте: "Я могу печатать 600 символов в минуту но получается какая-то фигня".
Именно. И микросервисы позволяют вот эту фигню изолировать в маленьком кусочке и остальным от нее не так сильно страдать, как в монолите.
M>Я учил архитектурные стили по Neal Ford и Mark Richards. У них микросеврисы стоят рядом с SOA
Микросервисы и SOA, при внешней похожести, все таки сильно не одно и тоже. SOA породили архитекты-теоретики, пытаясь пропихнуть некий концепт. А микросервисы наоборот, родились "от сохи". Когда адепты SOA начали ощущая загибание этой самой SOA со всеми причиндалами типа SOAP и WCF, вот тогда они и начали усиленно натягивать SOA на микросервисы.
M>Микросервисы в разновидность SOA очень любят записывать консультанты вроде IBM.
Вот вот. Не могут же они сказать, что то что они впаривали за гигабаксы до этого оказалось фигней.
M>Еще консультантам очень интересно продать как можно больше консультантов (organization grow fast).
Ты неверно интерпретировал фразу. organization grow fast это когда мы покупаем за внезапно полученные от инвесторов бабки кучу индусов, и после этого начинаем думать как же нам со всей этой сомнительной толпой наконец начинать что то делать. Микросервисы — отличный подход. Пилим систему на кучу почти несвязанных кусков, а потом отдаем индусам всю эту тряхомудию. А микросервисы позволяют этому хоть как то взлететь.
НС>>Распределенная транзакция с попыткой обеспечить ACID сложнее и требует более высокой квалификации, нежели eventual consistency. Аргумент твой доказывает обратное заявленному. M>Так в монолите же нет распределения через границы сервисов.
Это чего вдруг? Эра односерверных решений ушла в прошлое, они не годятся для high load, и даже монолитам надо уметь как минимум HA, а лучше все таки уметь в скейлинг.
Здравствуйте, Ночной Смотрящий, Вы писали:
M>>Сложнее. И требуют более высокой кваливикации разработчиков, чтобы начать делать хорошо. НС>Круто. Начинали с того что микросервисы нужны для того чтобы снизить требования к квалификации разработчиков (это 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.
Смысл цитировать эти манифесты за все хорошее? Люди пишут эти манифесты опробовав на маленькой выборке,
теоретики типа. У Нетфликса получилось, давайте все делать как Нетфликс. Зачастую это либо реально сложно из-за предметной
области, либо просто не нужно. На счет требований к инженерам -- ну вот какие навыки нужны от программиста в монолитном
сервисе? Язык, предметная область, sql+ еще какой-нибудь dsl, паттерны проектирования.
Требования к программисту микросервисов -- тоже самое + знание распределенных систем, ну хотя бы
на уровне Fallacies&pitfalls of distr. computing, типа что сеть не надежна,
пакеты теряются. Далее, писать соотв. образом, чтобы можно было без проблем перезапускать упавший сервис, т.е. грамотно
работать с локальным состоянием, знать про service discovery и прочие паттерны вроде sidecar, уметь заворачивать
свой сервис в докер, облачные технологии и т.п. вещи, nosql (event. consistency). Сразу куча вещей, которые надо
изучать и инвестировать не мало своего времени на это. Те же, по сути, требования что и к монолоиту+еще куча всего.
Сразу оговорюсь, у меня нету опыта работа над микросервисной архитектурой, соотв. про требования я взял из описания вакансий+
мое понимание работы и устройства микросервисных систем и архитектур. Я не очень понимаю, за счет чего требования к
квалификации программистов должны снизится, если наоборот, должны вырасти?
C>Усё. Имеем два сервиса с одинаковой функциональностью. Причём достаточно разнесённые по иерархии менеджмента, так что "дефрагментировать" их никого особо не тянет. [Исходный сервис после этого может постепенно умереть своей смертью.
Проблема в том, что выделенное обычно попросту не происходит. Две (а по факту много больше) инфраструктуры существуют параллельно. Так что разработчикам приходится еще и мучаться с "интеграцией" этого добра, а также учить свои сервисы поддерживать оба варианта.
C>Разные вариации на эту тему видел лично несколько раз. Вариант "вот это, но с перламутровыми крылышками" даже сам писал из-за того, что другая команда по идеологическим причинам не хотела добавлять нужный функционал.
Мне неоднократно доводилось стоять с другой стороны баррикад. В большинстве случаев вовсе не Равшан и Джамшут сделали сервис А. Чаще все наоборот. Процитирую:
Есть начальная команда, <...> эффективные менеджеры заменяют на более дешевых и управляемых <...> нанимает еще более дешевых разработчиков. Это будет третье поколение. Новые разработчики дешевые, но существующий код читать не умеют. Про рефакторинги и приведение монолита в порядок даже и говорить не приходится. Зато они умеют писать новый код. Внешние костыли гордо называются микросервисами.
Как раз "вот это, но с перламутровыми крылышками" и есть та стадия, когда "новые разработчики дешевые, но существующий код читать не умеют, зато умеют писать новый код" — те самые крылышки. Сплошь и рядом разработчики прикладного уровня даже не пытаются разобраться, как пользоваться существующими инструментами. Зато горазды велосипеды строить.
А далее по накатанной: параллельная реализация "с перламутром" оригинальными разработчиками с гордым видом сдается куда-нибудь в инфра-команду, с выражением "смотрите, вот мы сделали новую классную штуку, а поддерживать — это нам не с руки, мучайтесь сами, делайте что хотите, но сохраните вот этот вот API". И там, конечно, жуть и кошмар, сплошные макароны, обычно с минимумом тестов, в лучшем случае покрывающем нужды только оригинального разработчика. Почти всегда с текущими абстракциями, настолько затрудняющими рефакторинг (и сведение двух параллельных систем к одной).
Так вот, возвращаясь к "сам писал, потому что другая команда по идеологическим причинам не хотела". Причины очень часто не "идеологические", а банальная сложность поддержки костылей, которые просят натыкать, или абстракций, которые могут протечь, если продырявить "перламутровую пуговицу" где не надо. Монолит, конечно, упрощает такое, но и в случае с микросервисами выставить кишки наружу (и тем самым считай что запретить рефакторинг) — очень частая забава в "быстро растущем продукте".
Здравствуйте, SkyDance, Вы писали:
C>>Усё. Имеем два сервиса с одинаковой функциональностью. Причём достаточно разнесённые по иерархии менеджмента, так что "дефрагментировать" их никого особо не тянет. [Исходный сервис после этого может постепенно умереть своей смертью. SD>Проблема в том, что выделенное обычно попросту не происходит. Две (а по факту много больше) инфраструктуры существуют параллельно. Так что разработчикам приходится еще и мучаться с "интеграцией" этого добра,
Пусть существуют. Компания большая, выдержит.
Это куда лучше, чем борьба внутри "монолита" по поводу того, как развивать его.
SD>а также учить свои сервисы поддерживать оба варианта.
Тут не очень понятно зачем. Потребители будут просто выбирать один из сервисов. Поддерживать все варианты нужно будет только в каких-то очень специфических случаях.
SD>
SD>Есть начальная команда, <...> эффективные менеджеры заменяют на более дешевых и управляемых <...> нанимает еще более дешевых разработчиков. Это будет третье поколение. Новые разработчики дешевые, но существующий код читать не умеют. Про рефакторинги и приведение монолита в порядок даже и говорить не приходится. Зато они умеют писать новый код. Внешние костыли гордо называются микросервисами.
И причём тут микросервисы? В монолите будет всё так же, но ещё хуже.
SD>А далее по накатанной: параллельная реализация "с перламутром" оригинальными разработчиками с гордым видом сдается куда-нибудь в инфра-команду, с выражением "смотрите, вот мы сделали новую классную штуку, а поддерживать — это нам не с руки, мучайтесь сами, делайте что хотите, но сохраните вот этот вот API". И там, конечно, жуть и кошмар, сплошные макароны, обычно с минимумом тестов, в лучшем случае покрывающем нужды только оригинального разработчика. Почти всегда с текущими абстракциями, настолько затрудняющими рефакторинг (и сведение двух параллельных систем к одной).
Это решается удалением такого понятия как "инрфа-команды". Те кто пишет сервис — поддерживают его во время его жизни.
SD>Так вот, возвращаясь к "сам писал, потому что другая команда по идеологическим причинам не хотела". Причины очень часто не "идеологические", а банальная сложность поддержки костылей, которые просят натыкать, или абстракций, которые могут протечь, если продырявить "перламутровую пуговицу" где не надо.
Там была чистая идеология, реализация с нуля с нужным функционалом заняла несколько недель.
SD>Монолит, конечно, упрощает такое, но и в случае с микросервисами выставить кишки наружу (и тем самым считай что запретить рефакторинг) — очень частая забава в "быстро растущем продукте".
Как раз наоборот. В монолите будет препятствие в виде идеологии. Причём непреодолимое.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Ночной Смотрящий, Вы писали:
M>>>Сложнее. И требуют более высокой кваливикации разработчиков, чтобы начать делать хорошо. НС>>Круто. Начинали с того что микросервисы нужны для того чтобы снизить требования к квалификации разработчиков (это 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>Смысл цитировать эти манифесты за все хорошее? Люди пишут эти манифесты опробовав на маленькой выборке, S>теоретики типа. У Нетфликса получилось, давайте все делать как Нетфликс. Зачастую это либо реально сложно из-за предметной S>области, либо просто не нужно. На счет требований к инженерам -- ну вот какие навыки нужны от программиста в монолитном S>сервисе? Язык, предметная область, sql+ еще какой-нибудь dsl, паттерны проектирования. S>Требования к программисту микросервисов -- тоже самое + знание распределенных систем, ну хотя бы S>на уровне Fallacies&pitfalls of distr. computing, типа что сеть не надежна, S>пакеты теряются. Далее, писать соотв. образом, чтобы можно было без проблем перезапускать упавший сервис, т.е. грамотно S>работать с локальным состоянием, знать про service discovery и прочие паттерны вроде sidecar, уметь заворачивать S>свой сервис в докер, облачные технологии и т.п. вещи, nosql (event. consistency). Сразу куча вещей, которые надо S>изучать и инвестировать не мало своего времени на это. Те же, по сути, требования что и к монолоиту+еще куча всего.
S>Сразу оговорюсь, у меня нету опыта работа над микросервисной архитектурой, соотв. про требования я взял из описания вакансий+ S>мое понимание работы и устройства микросервисных систем и архитектур. Я не очень понимаю, за счет чего требования к S>квалификации программистов должны снизится, если наоборот, должны вырасти?
Микросервисы меньше размерами, удержать к голове архитектуру гораздо проще, проще сам процесс разработки, отладки, тестирования.
Размер в общем имеет значение. Я как-то работал с довольно большим, мягко говоря, монолитом, из несколько сотен Java модулей,
где разные части написаны как попало и как попало синтегрированы. Новому разработчику чтобы войти в курс дела и что-то начать
продуктивное писать не наломав дров сразу же, требуется где-то 3 месяца. Практически никто не видит полной картины, как вся система
работает, поэтому регулярно случались истории типа, что-то переместил в одном месте, отвалилось совсем в другом (и это удача если
это другое место было покрыто тестами. тестов там было много, но покрыть прямо все нереально).
По сравнению с этим, сложности микросервисов которые были упомянуты, они есть, но ими как правило занимаются специальные люди,
то есть при грамотной архитектуре, разработчик прикладной части микросервисов с ними не так много сталкивается.
Хотя сталкивается конечно, но это просто специфика, которая есть в каждом проекте. Я бы не сказал что нужна большая
квалификация разработчикам микросервисов. Но и что меньшая — тоже. Вообще здесь нет какого-то общего случая, может быть и так и эдак.
Однозначный плюс микросервисов — это размер, как я уже упомянул пару раз. Из-за него существенная часть сложности уходит.
Людей буквально заставляют делить большой проект на части физически, что в какой-то степени уменьшает степень макаронности кода.
Можно конечно и с микросервисами спагетти написать мама не горюй если архитектурой не занимаются вообще, но это все-таки
не так распространено как в монолитах.
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Так всетаки микросервисы проще монолитов или сложнее?
M>Сложнее. И требуют более высокой кваливикации разработчиков, чтобы начать делать хорошо.
M>Как SkyDance здесь уже отметил, микросервисы на раннем этапе всего-лишь позволяют предотвратить излишнюю связность. Особенно на нижнем уровне вроде базы данных. Это можно делать и в монолите, но нужна определенная политическая воля.
Это "всего-лишь" довольно дорогого стоит на самом деле.
Если мы говорим про длительный отрезок времени (10-15-20 лет), это (политическая воля и все такое) 99.9% нереально. Ну то есть политическая воля нужна на самом-самом верху, да и это может не помочь, потому что CEO приходят и уходят, да и основатели компании могут уже уйти к тому времени.
А типичный и всеми используемый процесс разработки оперирует краткосрочными целями (квартал, ну максимум год), долгосрочный tech debt всем пофигу по большому счету, на всех уровнях менеджмента.
То есть превращение монолита в макаронного монстра просто-напросто неизбежно, можно сказать заложено силами природы . Ну или корпоративной практики, что в данном случае одно и то же.
С микросервисами из-за на порядки меньшего размера, рефакторинг и приведение кода в порядок не становится запретительно дорогой операцией (как с монолитом) и может проводиться более-менее регулярно.
Здравствуйте, VladiCh, Вы писали:
VC>С микросервисами из-за на порядки меньшего размера, рефакторинг и приведение кода в порядок не становится запретительно дорогой операцией (как с монолитом) и может проводиться более-менее регулярно.
Зато рефакторить интерфейсы между сервисами становится практически невозможно поскольку для этого надо распинать кучу соседних команд. А у них у всех лапки и они ничего не хотят делать.
Здравствуйте, Sharov, Вы писали:
S>Смысл цитировать эти манифесты за все хорошее? Люди пишут эти манифесты опробовав на маленькой выборке,
Или нет.
S>У Нетфликса получилось, давайте все делать как Нетфликс.
А как надо?
S> Зачастую это либо реально сложно из-за предметной области, либо просто не нужно.
Зачастую? У тебя есть статистика?
S>На счет требований к инженерам -- ну вот какие навыки нужны от программиста в монолитном S>сервисе? Язык, предметная область, sql+ еще какой-нибудь dsl, паттерны проектирования.
Нужно умение хорошо структурировать код. И чем больше размер монолита, тем важнее это умение.
Интерфейсы языка программирования намного богаче и позволяют делать очень высокую связность, особенно если пользоваться ими неумело. А вот микросервисы принудительно вводят очень жесткие границы, не позволяющие высокой связности в силу специфики REST API.
S>тоже самое + знание распределенных систем, ну хотя бы на уровне Fallacies&pitfalls of distr. computing, типа что сеть не надежна, S>пакеты теряются. Далее, писать соотв. образом, чтобы можно было без проблем перезапускать упавший сервис, т.е. грамотно S>работать с локальным состоянием, знать про service discovery и прочие паттерны вроде sidecar, уметь заворачивать S>свой сервис в докер, облачные технологии и т.п. вещи, nosql (event. consistency). Сразу куча вещей, которые надо S>изучать и инвестировать не мало своего времени на это.
Почти все это нужно и для монолита. Ты же не сравниваешь всерьез микросервисы с системой, состоящей из одного сервера, надеюсь?
S>Сразу оговорюсь, у меня нету опыта работа над микросервисной архитектурой
S>>Смысл цитировать эти манифесты за все хорошее? Люди пишут эти манифесты опробовав на маленькой выборке, НС>Или нет.
Или да. Сначала пишут манифесты, потом начинается хайп, потом всплывает куча проблем что не всем и не всегда это
надо. Квалификация программистов, оказывается, нужна выше, а не ниже и т.д.
S>>У Нетфликса получилось, давайте все делать как Нетфликс. НС>А как надо?
Прежде как, а оно вообще надо? Т.е. на эти вопросы надо сначала ответить.
S>> Зачастую это либо реально сложно из-за предметной области, либо просто не нужно. НС>Зачастую? У тебя есть статистика?
Нету, кроме общих рассуждений и, по сути, заваленного проекта на фирме.
S>>На счет требований к инженерам -- ну вот какие навыки нужны от программиста в монолитном S>>сервисе? Язык, предметная область, sql+ еще какой-нибудь dsl, паттерны проектирования. НС>Нужно умение хорошо структурировать код. И чем больше размер монолита, тем важнее это умение. НС>Интерфейсы языка программирования намного богаче и позволяют делать очень высокую связность, особенно если пользоваться ими неумело. А вот микросервисы принудительно вводят очень жесткие границы, не позволяющие высокой связности в силу специфики REST API.
Допустим, а если разработчики монолита будут думать в терминах api, а не интерфейсов? В чем тогда выгода микросервисов?
S>>тоже самое + знание распределенных систем, ну хотя бы на уровне Fallacies&pitfalls of distr. computing, типа что сеть не надежна, S>>пакеты теряются. Далее, писать соотв. образом, чтобы можно было без проблем перезапускать упавший сервис, т.е. грамотно S>>работать с локальным состоянием, знать про service discovery и прочие паттерны вроде sidecar, уметь заворачивать S>>свой сервис в докер, облачные технологии и т.п. вещи, nosql (event. consistency). Сразу куча вещей, которые надо S>>изучать и инвестировать не мало своего времени на это. НС>Почти все это нужно и для монолита. Ты же не сравниваешь всерьез микросервисы с системой, состоящей из одного сервера, надеюсь?
В целом сравниваю. Ну не одно систему, а 2-3 пилят на 10 мелких. Опять же, надо определиться под тем, что называется
монолит. Много кода в едином адресном пространстве -- это оно?
S>>Сразу оговорюсь, у меня нету опыта работа над микросервисной архитектурой НС>А опыт работы над современными монолитами есть?
Опыт работы над небольшими проектами, группой 2-3 человек, на 1-2 года работы. Иногда группы из 4-5 человек.
Взгляд со стороны, а не изнутри.
НС>Интерфейсы языка программирования намного богаче и позволяют делать очень высокую связность, особенно если пользоваться ими неумело. А вот микросервисы принудительно вводят очень жесткие границы, не позволяющие высокой связности в силу специфики REST API.
Если уж на то пошло, REST API далеко не единственный и уж точно не лучший вариант для формализации общения между сервисами. Низкая эффективность, высокие накладные расходы и куча не совсем осмысленных ограничений.
Куда логичнее было бы применить какой-нибудь message passing interface. Чтобы у сервисо-писателей даже не возникало чесотки сделать очередные RPC тут и там. Но вот же беда, пресловутых 100.000 индусов научить мыслить в терминах распределенной (и по определению асинхронной) системы куда сложнее, чем дать возможность совершать [local] blocking calls. В итоге практика показывает, что микросервисы попросту превращаются в еще более страшный кошмар архитектора — распределенный монолит. Когда на вид там микросервисы, но протекшие абстракциями отовсюду. И везде сплошные crawler'ы, постоянно шерстящие систему в поисках разных там tombstones, orphan entities и прочего забытого добра. А потом, конечно, скандалы, "компания G годами не удаляла данные пользователей, которые хотели удалить эти данные в соответствии с GDPR, ах эти G, злые они, так и хотят украсть что-то, нельзя им верить".
VC>С микросервисами из-за на порядки меньшего размера, рефакторинг и приведение кода в порядок не становится запретительно дорогой операцией (как с монолитом) и может проводиться более-менее регулярно.
Рефакторинг одного микросервиса и в самом деле становится дешевле. Но их же много, причем, как уже было отмечено выше, вдобавок еще и есть варианты того же "с перламутровыми крылышками". Поэтому сравнивать нужно сравнимое. Рефакторинг монолита правильно сравнивать с рефакторингом всех микросервисов сразу.
Плюс еще тонкий момент с тестированием. Как уже было указано выше, чтобы иметь возможность хоть как-то тестировать "свой" сервис, нужно иметь возможность запустить либо тестовые экземпляры, либо моки всех зависимостей (хотя для e2e этот вариант может и не подойти). Как правило поднять экземпляр монолита проще, чем все зависимости "перламутровых пуговиц" микросервисов, где каждый кто во что горазд.
Короче говоря, серебряной пули нет. И так и этак нужна железная воля руководства, чтобы держать возникающую на пустом месте сложность в узде. А это, однако, редко встречается, ибо, как тоже уже было указано, горизонты планирования большинства контор сейчас от силы год, а реально еще короче. Это пару веков назад можно было себе представить проект на всю жизнь, где можно было держать марку качества. А сейчас если продукт не скатился в <...> за двадцать лет — это, однако, круто!
И то правда. В самом деле, так даже лучше, headcount больше, можно назваться "менеджером 3 команд". Это ничего, что там 3 дубликата одного и того же, зато 15 человек вместо 5. Более важный начальник, уже не просто менеджер, а менеджер менеджеров.
C>Там была чистая идеология, реализация с нуля с нужным функционалом заняла несколько недель. C>Как раз наоборот. В монолите будет препятствие в виде идеологии. Причём непреодолимое.
Конкретно ваш случай обсуждать не стану, ибо конкретики не знаю. Но подобных ситуаций я наблюдал очень много. Обычно заявления "вон та команда по идеологическим причинам не делает то, что я хочу" возникают при низкой квалификации требующего, который не в состоянии понять, почему отказ "вытащить вот те данные" является не идеологическим. В самом деле, вот почему бы не вытащить кишки sk_buff через какие-нибудь sysctl, так удобно было б по-быстрому подсмотреть всякие кастомные битики в заголовках IP, или еще что такое.
Также встречаются банальные провалы менеджмента. Когда команде "А" неповезло, и ее менеджер не в состоянии выбить headcount. Поэтому у команды постоянно аврал, вечно растущие backlog'и, постоянная дерготня от смены приоритетов (сегодня пришли из payments, давайте спешно их требования удовлетворять, а завтра пришли из кернел, ну надо значит им теперь помочь). У команды "Б" же, наоборот, людям заняться нечем (начальник у них оказался пронырливый, headcount выбил, но чем теперь людей занять, не знает). Вот тогда "Б" и начинают городить параллельную инфраструктуру. Иногда от нечего делать, иногда "to unblock ourselves". И нет бы им разобраться да помочь "А", написать тесты, сделать нужные pull request. Нет, что вы, это ж надо в чужом коде разобраться. Но команда "Б" пришла не для этого, им свое хочется.
Заканчивается подобное тем, что рано или позно для команды "Б" таки находится чем заняться, и начинается какой-то проект. А параллельная инфраструктура, поскольку уж очень она похожа на продукт команды "А", как раз и сваливается на "поддержку" (стало быть, merge & deprecate) в ту самую команду "А". Чем вызывает вполне законную злость представителей "А" на товарищей из "Б", последними принимаемыми за "идеологическое препятствие". Однако ж никакой там идеологии нет, просто уровень знаний повыше.
PS: если что, мой сын тоже ведь считает, что я ему исключительно по идеологическим причинам не даю круглосуточно сидеть в онлайн-играх, жрать чипсы и прочую дрянь. Ужасная идеология! А, вот еще, зубы чистить — ну просто высшее проявление идеологии. Он ведь уже несколько раз проверял, не почистил — ничего не случилось. Зачем вообще чистить, кроме как по идеологическим причинам.
Здравствуйте, Sharov, Вы писали:
S>>>Смысл цитировать эти манифесты за все хорошее? Люди пишут эти манифесты опробовав на маленькой выборке, НС>>Или нет. S>Или да.
Т.е. аргументов у тебя нет. ЧТД.
S>>>У Нетфликса получилось, давайте все делать как Нетфликс. НС>>А как надо? S>Прежде как, а оно вообще надо?
Что вообще надо? Архитектуру какую то? Обычно надо.
S>Допустим, а если разработчики монолита будут думать в терминах api, а не интерфейсов?
И как ты это проконтролируешь?
S>В чем тогда выгода микросервисов?
В том что испохабить всю систему из одного микросервиса намного сложнее, чем из модуля монолита.
НС>>Почти все это нужно и для монолита. Ты же не сравниваешь всерьез микросервисы с системой, состоящей из одного сервера, надеюсь? S>В целом сравниваю.
Тогда не вижу предмета для разговора.
S>Ну не одно систему, а 2-3 пилят на 10 мелких.
Пилят на микросервисы систему, которая изначально на одном сервере работает, я верно тебя понял?
S> Опять же, надо определиться под тем, что называется монолит. Много кода в едином адресном пространстве -- это оно?
Нет. https://whatis.techtarget.com/definition/monolithic-architecture
S>>>Сразу оговорюсь, у меня нету опыта работа над микросервисной архитектурой НС>>А опыт работы над современными монолитами есть? S>Опыт работы над небольшими проектами, группой 2-3 человек, на 1-2 года работы. Иногда группы из 4-5 человек. S>Взгляд со стороны, а не изнутри.
Ну то есть все сервисы исключительно single instance?
Здравствуйте, SkyDance, Вы писали:
НС>>Интерфейсы языка программирования намного богаче и позволяют делать очень высокую связность, особенно если пользоваться ими неумело. А вот микросервисы принудительно вводят очень жесткие границы, не позволяющие высокой связности в силу специфики REST API.
SD>Если уж на то пошло, REST API далеко не единственный и уж точно не лучший вариант для формализации общения между сервисами. Низкая эффективность, высокие накладные расходы и куча не совсем осмысленных ограничений.
В контексте разговора эффективность не принципиальна. Главное что не очередная разновидность OORPC.
SD>Но вот же беда, пресловутых 100.000 индусов научить мыслить в терминах распределенной (и по определению асинхронной) системы куда сложнее, чем дать возможность совершать [local] blocking calls.
А им и не нужно мыслить. Их задача обычно диктуется уже спроектированным API и наложенными на них ограничениями в виде лимитов пода и SLA. Как это все будет натягиваться на реальную инфраструктуру — задача уже других людей.
При этом, конечно, если забить на нормальных девопсов и посадить все это натягивать на инфраструктуру таких же индусов — фейл неизбежен и никакие микросервисы не спасут.
НС>А им и не нужно мыслить. Их задача обычно диктуется уже спроектированным API и наложенными на них ограничениями в виде лимитов пода и SLA. Как это все будет натягиваться на реальную инфраструктуру — задача уже других людей. НС>При этом, конечно, если забить на нормальных девопсов и посадить все это натягивать на инфраструктуру таких же индусов — фейл неизбежен и никакие микросервисы не спасут.
Я правильно понимаю, что если раньше тем самым "другим людям" (и "нормальным девопсам") достаточно было просто диктовать архитектуру и не давать руководству заменять дешевых разработчиков на дорогих, то сейчас вдогонку к тому нужно еще успеть уследить на 100.000 индусов, чтобы те не проторчали кишки во все стороны? Не, эт дохлый номер, оно так не сработает. Просто теперь расходы на такой проект вырастут на те самые 100.000 индусов и их менеджеров, плюс потребуется еще больше грамотных людей. Понимаю, что линейным менеджерам это только на руку, но с точки зрения компании выигрыш неочевиден.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Круто. Начинали с того что микросервисы нужны для того чтобы снизить требования к квалификации разработчиков (это 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.
Это не maxkar, похоже, путает -- вот тут, по ссылке из ссылки выше, пишут в cons для микросервисов:
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:
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.
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.
. Ну или корпоративной практики, что в данном случае одно и то же.
А, вот еще, зубы чистить — ну просто высшее проявление идеологии. Он ведь уже несколько раз проверял, не почистил — ничего не случилось. Зачем вообще чистить, кроме как по идеологическим причинам.
