>>888782 (OP)
никаких подводных камней. пока не напорешься на них.

>>888782 (OP)
>начал переписывать под них весь проект.
>
Обосрешься ты переписать большой легаси-проект.

А вообще подводные камни это продолжение достоинств. У тебя вместо одного сервера и одной бд их теперь будет множество, возможно десятки. В итоге:
1) Сложно и долго разворачивать
2) Сложно тестировать (ехали моки через моки)
3) Бывает сложно поддерживать, если разные микросервисы пишутся разными мало взаимодействующими командами. Например можно через годик ВНЕЗАПНО обнаружить, что один из сервисов написан на каком-нибудь Haskell, или использует какую-нибудь ебнутую БД с которой никто не умеет толком работать - просто потому что его команде захотелось поэкспериментировать, вот только команда с тех пор уже успела уволиться.
Конечно такие проблемы (когда никто не знает как работает внутри компонента) бывают и у монолитов, но там хотя бы язык и стандарты кодирования будут общие с прочим кодом.
4) Вопросы производительности. Лишние сетевые задержки там, где монолит бы отработал моментально.

Это то что в голову приходит.

>>888844
>2) Сложно тестировать (ехали моки через моки)

Вот мне интересно, а если у меня все взаимодействия через очереди, то по идее весь тест сервиса это то, что он в нужную очередь записал/прочитал/преобразовал сообщение. Разве нет? Поясните

ньюфак-в-трети

>>888853
Смотря что протестировать хочешь. Но в целом, да, сделал мок очереди и доволен.

>>888844
>3) Бывает сложно поддерживать, если разные микросервисы пишутся разными мало взаимодействующими командами. Например можно через годик ВНЕЗАПНО обнаружить, что один из сервисов написан на каком-нибудь Haskell, или использует какую-нибудь ебнутую БД с которой никто не умеет толком работать - просто потому что его команде захотелось поэкспериментировать, вот только команда с тех пор уже успела уволиться.
Конечно такие проблемы (когда никто не знает как работает внутри компонента) бывают и у монолитов, но там хотя бы язык и стандарты кодирования будут общие с прочим кодом.

дык если реально микро-сервис, то его должно быть достаточно просто переписать, если известна функциональность.

ньюфорк-в-четверти

Вкотился.
Все пишем на микросервисах(На самом деле просто на сервисах), даже небо даже аллаха.
http://martinfowler.com/articles/microservices.html
http://microservices.io/
Я как ПМ счастлив, потому что усьо файно скейлится, ничего разом не падает, нарезать задачи рабам стало проще.
Заказчик хлопает в ладошки, разработчики дрочат вприсядку, количество сервисов уже 200 и растет, никто не помнит нахуй они нужны и начали пилить лисапеды, каждый наносервис отжирает 200-300 метров оперативы в контейнере, а заказчику и норм, ГРОБ ГРОБ КЛАДБИЩЕ ПИДОР.

>>888860
>то его должно быть достаточно просто переписать
Ну микро или не микро, а несколько недель или месяцев может занять, на ровном месте проебется куча времени и усилий.

очередная сильвер буллет для веб макак
расслабься

подводные камни что ты, уебище, вместо того чтобы сделать то что тебя попросили дяди (а именно тупо добавить restful или soap доступ к вашей инфраструктуре) ты уже решил "переписывать весь проект"
я щитаю шо таких уебков надо пиздить ногами и выебывать нахуй с галеры

>>888914
Ахаха)
Вряд ли он с галеры. Но юмор понял)

>>888881
Несколько недель норм для случаев, если писала команда хаскелистов, которая уволилась. А если несколько месяцев, то сервис уже не микро получается.

>>889068
>>888881
По идее микросервис команда может переписать/написать с нуля за неделю.
Если нет - это уже не микросервис.

>>888877
Квадриплодабл врать не будет

>>889091
>>889068
И откуда ты это взял? По идее микросервис - это просто некая логическая единица функциональности, составной кирпичик более сложного процесса. Она совсем не обязана быть тривиально простой, но она должна быть неделимой.

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

Вопрос: микросервис это или нет?

>>889518
Ты ебанутый? Ты что там делаешь? Монолит нахуярил на сто тыщ строк и назвал микросервисом? Если ты уебок не можешь свой "неделимый" разбить на мелкие модули, то пиздуй асфальт кидать за 100$ в месяц. "Неделимый" у него, пиздец.

Ты соверешенно не понимаешь суть микросервисов, суть вовсе не в неделимости, а в куче простых модулей, каждый из которых делает маленький (микро- как бы намекает, это 10^-6) объем работы. Они нужны чтобы любой индус мог в нем разобраться, а всяких сеньоров за 5к$, у которых "неделимо" головного мозга, можно было было на мороз выкинуть.

>>888877

ты просто из этих, объектно-ориентированных.

А микросервисы это другое, это свободные отношения.

>>889608

мессейдж для >>889518

>>888877 а вот этому котофану мне нечего сказать. с ним и так все ясно.

>>889518
маня, ты бы хоть почитал чем монолит отличается от SOA и микросервисов. two pizza и возможность переписать за неделю-две - чуть ли не основные признаки того что твой апп - микро.
а тебе с твоими "дохуя логики" можно еще очень долго декомпозировать.

>>889787
у микросервисов один огромный минус, для того чтобы начать их писать нужно очень долго проектировать модель сообщения, а потом долго всем разработчикам вдалбливать, что они должны ее придерживаться. Этого можно избежать, если есть опыт проектирования микросервисов в этой предметной области и оптимальная модель известна.
Если стандарта модели сообщения не будет, то будет полный пиздец. Лучше монолит, чем спагети из разновыебанных структур сообщений. В этом случае новую версию переписанного микросервиса до прода будите месяцами доставлять, так как если микросервис был через жопу написан да и вообще проектирование было через жопу,то и документация через жопу и вообще никто не понимает как работает, и кто его юзает, легче ,в любом случае не будет, не будет.

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

>>889854
это проблемы не микросервисов, а макак-девелоперов
что мешает сразу создать гайдлайн по структуре обмена сообщениями?
очень сомнительно, что при таком подходе монолит будет писать много проще

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

>>889885
с подходом хуяк-хуяк-в-продакшен оно то конечно

>>889885
>код монолита под носом, сиди копируй да имитируй такойже код.
делаешь рефернсный сервис, все сидят с него и копируют, однохуйственно, наехал тут на микросервисы, щенок.

>>888782 (OP)
забудь про то что говорят тебе аноны выше. микросервисы — это не про "починить быстро" или "нарастить функционал". Эти задачи решаются и в монолите, если он добротно спроектирован. Микросервисы — это в первую очередь про идею о том, что разделив всю бизнес-логику на некоторые автономные составляющие мы убережем себя от ненужного усложнения этой бизнес-логики (потому что большой монолит, очевидно, переусложнить не сложно). Микросервисы — это про интуитивную декомпозицию сложной системы, про реализацию в таком виде, в котором система существует на стадии идеи. Микросервисы — не лучше и не хуже. Микросервисы — это в первую очередь образ мышления, а не архитектурный подход. Выбери микросервисы.
ОДНАКО АНОН ЗНАЙ
Микросервисы — не панацея. Микросервисы — это лишь один из вариантов, который подходит для реализации лишь определенных типов систем. Нет никакой нужды пытаться разбить систему на микросервисы, если ты после первого ознакомления с системой не видишь в ней явных и независимых подсистем. Не обманись, анон, учись видеть перспективу того, что ты разрабатываешь. Не выбирай слепо.

Если прочитав это ты еще не киваешь головой одобрительно, а скорее по-прежнему не понимаешь по каким же признакам выбирать модель — не бойся. Лучше любого моего объяснения сработает твой труд. Представь себе несколько гипотетических, но максимально разных бизнес-задач. И для каждой попробуй подойти с точки зрения монолита и с точки зрения микросервисов. Ты почувствуешь. Или мы вернём тебе деньги.