company_banner

Остановитесь!!! Вам не нужны микросервисы

Автор оригинала: Ebin John
  • Перевод

Идет 2020 год. Если вам нужно пояснение, что такое микросервисы — лучше потратьте свое драгоценное время на что-то другое. Но если вы впечатлены историями успеха о микросервисах и хотите нырнуть в "панацею" с головой — продолжайте читать. Прошу прощения, будет немного длинновато (не очень, прим. переводчика).


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


По первой части вопроса договорились легко, а вот вторая встала весьма остро. Через пару минут общения часть фактов была собрана:


  • Есть желание использовать микросервисную архитектуру в будущем продукте, надо это как-то утвердить.
  • Кворум был в большей степени нетехническим, чем больше он переходил в "техническую плоскость", тем более неуместным он становился.
  • Длинные паузы и отсутствие вопросов подразумевали незнание функционала как веб-сервисов, так и микросервисов.

Я их не осуждал за отсутствие знаний о функциях веб-сервисов или о следствиях работы микросервисов. Собеседники, конечно же, весьма превосходили меня в работе в своей отрасли. Но они хотели запрыгнуть в микросервисы без оценки возможных последствий!


Впервые о микросервисах я узнал еще в 2013 году, это был ролик на YouTube, где пояснялась архитектура сервисов Netflix. Было весьма впечатляюще, но я пропустил все без сожаления, поскольку это было слишком сложно для меня, человека, который тогда только начал постигать принципы разработки. Скоро это стало навязчивой идеей, поскольку на новом проекте объявили о внедрении микросервисов. Разработка проекта была увлекательной, он до сих пор остается лучшим по кодовой базе из тех, что попадали ко мне.


Честно говоря, широкие возможности модульной разработки были где-то далеко от меня, и я просто добавил дополнительный уровень сложности, будучи невежественным разработчиком, скрывавшимся от DevOps. Спустя пять лет я уже работаю с совершенно новым продуктом и другими людьми. У меня куча проблем, возникших из-за плохо разработанных микросервисов, приправленных тактикой девопсов-любителей (девляпсов?, прим. переводчика). Пелена довольно скоро спала, обнажив хрупкость микросервисов. Также я начал смотреть на всю эту архитектуру более опытным взглядом. Было поздно, но лучше поздно, чем никогда.


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


Ваше приложение достаточно большое, чтобы дробить его на микросервисы?


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



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


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


Нужно ли на самом деле масштабировать отдельные компоненты приложения?


Предположим, что владелец продукта обратился к вам с идеей системы управления для автоматизации отдела кадров компании, в которой работает от 10.000 сотрудников. Технический энтузиаст внутри вас ответит мгновенно: микросервисная архитектура.



Конечно, это граничный случай, но общий смысл вы уже уловили! Одно из основных преимуществ использования этой архитектуры — простота масштабирования отдельного компонента. Можно найти множество приложений, в которых этот принцип сработает, но нужно ли это вашему приложению?


Есть ли транзакции, распределенные между сервисами?


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


Cервисы REST не имеют состояния по определению, а также не должны участвовать в транзакциях, которые проходят по нескольким сервисам. В мире высокой производительности двухфазный коммит (2PC) — ненужное зло. Шаблон SAGA добавляет еще один уровень сложности, к которому вы не будете готовы.


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

Возможно ли иметь распределенные по сервисам транзакции?


Да, конечно.


Стоит ли делать цепочку действий поверх сервисов без состояния (stateless)?


Возможно, не стоит!!


Есть ли нужда в частом общении между сервисами?


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


Есть много проверенных и протестированных решений, но цена у них одна и та же — задержка. При переходе к микросервисам задержка вырастает от наносекунд до микросекунд. Попробуйте представить, что есть три сервиса, передающие данные по сети. Предполагая, что каждый вызов сервиса занимает 100мс (не очень быстро под нагрузкой), вы потратите 300мс только на сеть.


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


Кое-что ещё


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

Следует помнить, что усредненная организация в IT не обладает такими же навыками, как команды инженеров Netflix. mike_pfeiffer

  • Цена распределенных систем. Микросервисы — распределенные системы с молекулярностью. Но распределенность имеет свою цену. Монолит был бы развернут на большой виртуалке или в некотором предварительно сделанном контейнере. Но микросервисы должны разворачиваться независимо (в идеальном мире) на нескольких виртуалках или контейнерах. Конечно же, они бывают небольшими по размеру, но это стоит также учитывать, и помнить, что я еще не начал говорить о затратах на управление и обслуживание.


  • Внедрение DevOps может быть как полезным, так и вредным. DevOps — проверенное и широко распространенное решение, но если вы работаете в маленькой компании, создание команды DevOps может принести больше вреда, чем пользы. Но одно можно сказать точно — нельзя поддерживать и управлять микросервисами без команды DevOps.


  • Сильная связность — некоторые приложения сильно связаны по своей природе. Разбиение на микросервисы, чтобы «вписаться» в архитектуру, будет катастрофическим.


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


  • Сквозное тестирование. Типичное монолитное приложение позволяет запускать тест практически мгновенно. Наличие нескольких служб с взаимозависимостью задержит тестирование без жизнеспособной оркестровки.


  • Хаотичные контракты на данные. Разработка и хранение контрактов на данные внутри команды сильно отличается от их распространения среди команд. А когда вы работаете с микросервисами, ваша команда может не находиться в одном регионе, не говоря уже об использовании одного и того же языка программирования. Выработка контрактов с данными для особых нужд будет стоить вам времени и места.


  • Устаревшая кодовая база — давайте будем честными. Для большинства из нас работа с устаревшей кодовой базой — это повседневная деятельность. Это хлеб с маслом большинства организаций. Быстро меняющиеся технологические достижения ставят нас впереди всех, но и в то же время они изолируют нас от устаревшей кодовой базы. Вы уверены, что только что разработанный фреймворк, использующий RabbitMQ, хорошо работает с устаревшим приложением, работающим на AIX?


  • Устранение неполадок — каждый сервис будет иметь свой собственный набор файлов журналов для анализа. Больше сервисов = больше файлов.



Заключение


Я здесь, чтобы сказать "Не используйте микросервисы"?


Конечно же, нет!!


Микросервисы заслужили известность. Они решили проблемы, которые считались неразрешимыми. История Netflix по применению микросервисов вдохновила многих. И список определенно не останавливается на Netflix. Uber, SoundCloud и гигантский Amazon — вот некоторые примеры, которые у всех на слуху. И не думайте, что истории успеха ограничиваются только потребительскими приложениями. Я имел непосредственный опыт работы с американским гигантом здравоохранения и был очарован возможностями дизайна, каждый раз, когда открывал исходный код.


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


Мне нравятся увлеченные программисты, я сам такой когда-то был таким, да и все еще есть. Они преданы тому, что делают, и переходят все границы, чтобы решить свою проблему. Но вы не можете так же энергично принимать решения, которые могут стоить вам и организации целое состояние, извините за резкость. Микросервисы не должны быть вашей архитектурой приложений по умолчанию. Это не серебряная пуля, которую вы искали. Сохраняйте равновесие с KISS и YAGNI.


Как сторонник технологии и энтузиаст, вы имеете право что-либо предпочитать. Однако то, что показывает вас с лучшей стороны — способность выбирать прагматично, когда варианты находятся между «правильным выбором» и «вашим любимым выбором».

Southbridge
Обеспечиваем стабильную работу highload-проектов

Комментарии 246

    +53
    Почему-то в статьях всегда обсуждают крайности, микросервисы против монолита. Почему не разбивать приложения на естественные куски с минимальным числом связей, назвать их сервисами, и иметь только плюсы обоих подходов?
      0
      Если вы сможете разбить приложение на cohesive сервисы, то можно предположить, что вам не придётся преодолевать обычные проблемы веб-сервисов (ныне микросервисов).
        +9
        Потому что хайп движет миром.

        Если вы предложите просто «разбить приложения на естественные куски с минимальным числом связей» — то вам покажут 100500 незакрытых фич-реквестов и никто ничего разбивать не будет.

        А вот если вы покажете решение, которой может решить сразу все мировые проблемы сразу и будуте говорить достаточно убедительно — ресурсы, может быть, и удастся получить…
          +4

          Вероятно, потому что «не модно». Сам задаюсь этим вопросом пару лет.
            0
            Очень многие пилят «микросервисы», когда как на практике придерживаются сервисной архитектуры, которой уже сто лет в обед будет — en.wikipedia.org/wiki/Service-oriented_architecture

            Нормальные микросервисы — это когда не 5, не 10 сервисов, а 1000-5000 на тот же размер кода. И все это независимо мастштабируется в контейнерах для полноценной утилизации ресурсов. На такую крайность мало кто идет.
              +4
              SOA и микросервисы практически ничем и не отличаются друг от друга. Никто в своем уме не может предложить адекватного определению микросервисов, потому что его не существует. Так же как не существует адекватных технических определений bigdata, nosql, data lake и прочего, что напридумывали. Единственное осязаемое отличие SOA и микросервисов культурное и организационное, но не техническое. И нет никаких жестких требований по количеству, когда SOA переходит в микросервисы. Все попытки показать отличия SOA и микросервисам выглядят довольно смешно, т.к. часто приводят в пример ESB, XML, SOAP, контейнеры. Как-будто смена протокола и шины обмена кардинально меняет парадигму. Как было распределенное приложение с асинхронной модель передачи информации, так и осталась. Просто пришел прогресс и появились технологии по-лучше, но сам подход не менялся и никуда не делся. Выросли только масштабы, до которых некоторые (и только некоторые) довели этот подход. Масштабы, которых раньше просто не было.
                0
                Никто в своем уме не может предложить адекватного определению микросервисов, потому что его не существует

                Почему? Микросервисы обычно подразумевают автоматический оркестратор (запуск и остановку инстансов в основном без участия человека), несколько экземпляров большинства инстансов, слабую связность (потенциально все инстансы должны работать в независимых виртуальных машиных или docker контейнерах).
                SOA может реализовываться как микросервисами, так и большими ручными сервисами-приложениями.
                  +1
                  И все это никак не противоречит SOA, потому что микросервисы всего лишь SOA. Люди пытаются выделить микросервисы во что-то свое уникальное, но оно таким не является, отчего адекватного определения и не видно. Поэтому люди и цепляются за всякие глупости вроде контейнеров, devops (еще одно бессмысленное нечто), протоколов обмена информацией, которые не означают ровно ничего, кроме того, что SOA сегодня делают на контейнерах и rest. И почему-то кому-то пришло в голову назвать это микросервисами.
                    0
                    потому что микросервисы всего лишь SOA

                    А разве кто-то с этим спорил? Однако обратное неверно — не всякая SOA архитектура это микросервисы.
                      +1

                      Есть же адекватное: должно хватить двух пицц, чтобы накормить команду, способную поддерживать один микросервис.

                        0

                        Две пиццы это на какой срок?
                        Какие именно пиццы? Диаметр? Вес? Калорийность?
                        Если это был сарказм, то я не понял)
                        А так… Смешивать техническое и человеческий фактор прожорливости — не самая лучшая идея.
                        Две пиццы 35-40см в диаметре я могу легко съесть за часов 5, хотя я не такой и большой (около 85кг).

                          0

                          За раз, за один приём пищи типа ланча, больших, видимо. Дословно не помню, но когда читал в голове чётко картинка сложилась — человек 6, 8 максимум. Если не справляются, то или микросервис надо дробить, или перестать называть его микро.

                –2
                Почему не разбивать приложения на естественные куски с минимальным числом связей
                … и все это внутри одного рантайма!

                Миллениалы изобрели модульность.
                +9
                My First Law of Distributed Object Design: Don't distribute your objects. Веб-сервисы показали себя с тяжелой стороны еще с 90-х годов. Если не можете коммуницировать асинхронно, то, возможно, в этом месте разделять сервисы не стоит.
                История Netflix по применению микросервисов вдохновила многих
                Это не значит, что
                1) Netflix и пр. отдельные игроки однозначно выиграли со своими микросервисными решениями
                2) Вы выиграете со своими микросервисными решениями
                То есть жить с несмертельно неудачными решениями можно, но необязательно.
                  +23

                  Микросервисы это отличный способ организовать работу огромной команды разработчиков (100+ человек) над одним продуктом. Если у вас гораздо меньше разработчиков, то микросервисная архитектура будет добавлять большой оверхед.

                    +6
                    добавлять большой оверхед

                    Как бы это еще донести до вышестоящих, погоня за «модностью» разбивает все обычные аргументы.
                      0
                      Может быть «вышестоящим» надоедает, что каждые три года ИС переписывается с нуля, с огромным расходом бюджета и кучей багов?! <:o)
                        +8
                        надоедает, что каждые три года ИС переписывается с нуля

                        Поэтому выбирают микросервисы? Чтобы за три года банально не успели ничего выпустить?
                          +2

                          Чтоб переписывать частями.

                            +1
                            переписывать частями

                            А переписывание частями как-то гарантирует ускорение разработки или меньшее количество багов?
                              0

                              Не гарантирует, но увеличивает вероятность

                                0
                                От многих людей слышал такое же мнение и даже сам, в своих логических рассуждениях приходил к нему.

                                Однако моя практика показывает обратное. Выборка у меня конечно небольшая, но уж какая есть.

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

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

                              Чтобы переписывать частями нужны микросервисы?
                              Как по мне (и исходя из опыта), если нормальная архитектура, то и монолит можно переписывать частями без проблем

                                +1
                                Где вы видели нормальную архитектуру в легаси проекте,
                                на котором потопталось 3-4 поколения программистов?!

                                Понятно, что «лучше быть богатым и здоровым», но обычно так не бывает.
                                  0

                                  Где вы увидели, что я писал про легаси?
                                  Где вы увидели несколько поколений, если сами писали про 3 года?


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


                                  Не понимаю почему вы пишите оффтоп

                                    0
                                    А мы говорим про легаси! :-)
                                    Кроме того «вышестоящим» уже несколько раз предлагали все переписать под «нормальную архитектуру». С неизменным результатом. :-)
                                      +2

                                      За три года как раз три поколения может смениться.

                                    0

                                    Микросервисы не прямо необходимы, но способствуют тому, чтобы нормальная архитектура была. В частности, чтобы общение модулей проходило через строго определенный API, через их фасады. Усиление сокрытия на уровне модуля, а в некоторых языках чуть ли не единственный способ получить технические гарантии того, что модули общаются друг с другом строго через фасады, отдающие/принимающие только скаляры и иммутабельные DTO.

                                      0

                                      То, что вы написали никак не отменят моего высказывания.
                                      Почему вы думаете, что использую микросервисы, вы получаете гарантии? Как только вы перестанете за этим следить, сразу всё пойдёт "естественным путем".

                                        0

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

                                          0

                                          Видимо, вы работали только с умными людьми)
                                          На моей практике было такое, что человек вместо написания пары строк кода пишет отдельный класс костылей

                                            0

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

                                              +2
                                              Со стороны ваше утверждение выглядит так:
                                              У нас есть сугубо организационная проблема ограничения совместного доступа к общему коду. Решим её организационными путями? Разобьём код на модули и сделаем git hook, который запрещает пушить в чужие модули или хотя бы оповещает владельца? Сделаем нормальное code review?

                                              Нет, давайте лучше потратим человеко-годы и кучу железа (т.к. у нас теперь всё взамодействует по сети) на переписывание всего на микросервисы. А потом ещё столько же на поддержку получившегося поделия.

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

                                              Ну и совершенно верно выше писали — по факту, миллениалы изобрели модульность :)

                                              Единственный конструктивный посыл от микросервисов — это раздельное масштабирование, но возникает такая проблема только на правда большом масштабе (как минимум, сотни и тысячи физических серверов, но и тут как правило хватает SOA).

                                              А истории «у нас CRM система на заводе, мы всё переписываем на микросервисы» — это классический пример, когда не очень толкового менеджера надурили не очень толковые программисты, которым скучно писать бизнес-логику, а амбициозных задач не предвидится — вот они их сами и придумывают за счет работодателя :)
                                                0

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


                                                Я не говорил "давайте лучше". Я сказал, что они работают в этом качестве. Это один из их "бесплатных" плюсов.

                                        +2
                                        Микросервисы никак не формируют и не защищают границы домена. А нарушенные границы домена создают кучу проблем с coupling с другими сервисами. И изменять эти границы намного сложнее, чем в монолите.

                                        Так что компании с низкой технической экспертизой показан монолит. Он явно дешевле в развитии и сопровождении (собственно, о таком очень часто говорится касательно SOA).
                                    0

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

                                      0
                                      Микросервисы энфорсят низкую связанность
                                      Только если запрещены синхронные коммуникации между ними, иначе это просто distributed objects. Но асинхронные коммуникации могут выполняться и в одном процессе, например (что не делает такую архитектуру менее сервис-ориентированной).

                                      Есть подешевле способы форсить связность на уровне кода, чем проблемные удалённые коммуникации.
                                        0

                                        А откуда возьмутся синхронные коммуникации по HTTP?


                                        Есть подешевле способы форсить связность на уровне кода, чем проблемные удалённые коммуникации.

                                        Наверное, Есть, но там по моему опыту всё скатывается в "залезть руками в БД другого сервиса".

                                          +1
                                          А откуда возьмутся синхронные коммуникации по HTTP?
                                          Request-response — природа HTTP. Когда один процесс ждёт завершения другого и его ответа.
                                            0

                                            Но он тем не менее асинхронный. Вы не путаете push/pull-based концепции? Потому что технически HTTP куда как асинхронный.

                                              +1

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

                                                0

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

                                                  +1
                                                  сокеты и всё остальное, ещё какой асинхронный
                                                  Но мы обсуждаем логический, верхний уровень. То есть сам протокол. Не транспортный уровень или что-то ниже.
                                                    +1

                                                    Вот на уровне протокола оно как раз синхронное. Выше и ниже может быть асинхронно, но протокола это не касается.

                                  –4

                                  Вся соль именно в цифрах. 100+, но почему именно столько? Почему не 10+ или 1000+. Я молу про более нежные случае, вроде 50+, 70+ или 130+, 200+. А что, если я скажу — что 99% современного веба уже лет сто в обед поклоняются микросервисной архитектуре? Четырьмя буквами: СУБД. Я уже молчу про стораж, аутентификацию, биллинг. Но у них же уважительная причина быть микросервисами?


                                  А теперь почему микросервисы это крутота и почти (почти!) всегда их стоит использовать. Это возможность мешать пайтоны с го, это возможность декларировать (!) внутренний (!) API ещё до первой строчки кода by design. Потому что http известен, он прост и удобен.


                                  Ко всему прочему микросервисы не означают REST, хотя программировать и забыть про состояние — это красота. Каждый раз, когда необходимо помнить про сотни строк кода выше — это боль и страдание. А если при этом глобальное состояние растеклось по кодовой базе — кому-то точно не стоило начинать этот проект.


                                  А вообще. У всего есть свои плюсы. И свои минусы. Микросервисы, конечно, очень плохо ложатся на UI. Ну, by design. И ладно, если вы огромный видеохостиг, которым есть хоть что-то разделять в UI, а если вы очередной интернет-магазин или государственная специализированная СУБД? Первый собирается как конструктор из готового, ко второму обычно заранее есть сборник сочинений в трёх томах разной степени упоротости. Хотя это не значит, что не стоит ~использовать~ ориентироваться на микросервисную архитектуру, но это так же совершенно не значит, что надо дробить функционал до 2+2 на отдельный C++ истанстанс — навроде так быстрее же? Крайности ужасны. А микросервисы прекрасны.


                                  И да. За оверхед их корят не во времени разработке, ни разу не видел, чтобы микросервисы проигрывали в написании. Если их правильно готовить, конечно. Оверхед по ресурсам — совсем другая история, но задумываться о них, когда ресурсы — операционные расходы, а удвоить RAM это совсем не тоже самое, что двойной прайс — ну. Немного не то, чего ждёт бизнес. Но это уже совсем другая история.

                                    +20
                                    «Это возможность мешать пайтоны с го» С каких пор зоопарк языков и фреймворков в проекте стал плюсом?
                                      –1
                                      С каких пор зоопарк языков и фреймворков в проекте стал плюсом?

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

                                        Ну, имхо, все же скоринговый движок датасайнетистов сбоку от какой-нибудь ИС — это не микросервисы, iOS приложение для этой же ИС — это тоже не микросервисы.


                                        Микросервисы с зоопарком языков — это когда у вас аутентификация в эту ИС на шарпе, авторизация на питоне, email шлюз на perl, а sms шлюз на php.

                                          +3
                                          … apigateway на node.js, rate limiter к нему на го
                                            +2

                                            Во-о-от, профессионалы подтягиваются :)

                                              0
                                              Однажды участвовал в проекте, в котором у разработчиков была полная свобода воли. Когда подключился я, проект работал так: запускалка — powershell, UI — angular, API — perl+mojo, DB — ms sql, backend — perl, node+express, java, c++/qt (в зависимости от функций). Обмен сообщениями, в зависимости, опять же, от функций, через: файлы, rabbitmq, DB, stdin/stdout, websocket'ы. Кажется, ничего не забыл. Проекту на тот момент был год.
                                                0
                                                Забыл. Там был ещё go.
                                                  0

                                                  С ангуляром не взлетит, реакт нужен :)

                                                  0
                                                  Готов поспорить, там где-то должен быть прикопан make.
                                                +1

                                                Было бы смешно, если бы этого не было у нас в проекте. Приправьте сверху еще gRPC вместо REST.

                                            +3

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

                                              0

                                              А может потому-что Васе было проще и быстрее на node.js прикрутить костыль и не заморачиваться

                                                +1

                                                "проще" и "быстрее" тоже критерии лучшести :)

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

                                                  Необязательно бездумное. Просто критерии выбора технологии могут быть неочевидными или несогласованные с бизнесом. Типа написали один сервис на Go, работает быстрее чем на Java на 10%, но стоило ли оно того непонятно.

                                                    0
                                                    стоило, потому что теперь можно взять сервер в 10 раз меньше :)
                                                      0

                                                      На 10% меньше )

                                                +2
                                                Как по мне то это логично, что на сколь нибудь серьезном проекте по любому получишь некий набор языков/фреймворков. Или вы предлагаете на фронте и бекенде использовать, например, c/c++?
                                                  0
                                                  а вы слышали, чтоб разный язык на фронте и бэке называли зоопарком?
                                                    +1

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

                                                  0
                                                  Запоздалый коммент, но UNIT Nginx это про микросервисы ОО?
                                                  +4
                                                  Могу я попридираться к словам немного?

                                                  А теперь почему микросервисы это крутота и почти (почти!) всегда их стоит использовать. Это возможность мешать пайтоны с го
                                                  Ух ты, то есть вместо одного ЯП со стремительно устаревающими зависисмосями (фреймворки, сторонние либы, etc.), регулярно всплывающими багами и неочевидными подводными камнями, которые требуют время на изучение, мы можем получить целых два ЯП за ту же зарплату! Действительно, как это кому-то может не нравиться?

                                                  это возможность декларировать (!) внутренний (!) API ещё до первой строчки кода by design
                                                  Вообще-то для этого уже давно изобрели UML, но это «некруто», поэтому давайте изобретём Open API и будем его лепить даже для внутренних сервисов — будем круто.

                                                  Так-то согласен, что правильное разделение обязанностей решает и надо обязательно понимать: что за сервис вы создаёте и какие у него потребности.
                                                    –3
                                                    Могу я попридираться к словам немного?

                                                    Конечно!


                                                    Ух ты, то есть вместо одного ЯП со стремительно устаревающими зависисмосями

                                                    Ух ты, вместо фиксирования зависимостей (фреймворки, либы, сниппеты, кор) мы можем получить перманентные out of service/maintance, deprecated и orphaned, с регулярно всплывающими новыми багами и неочевидными подводными камнями, которые требуют время на миграцию, реверсивное тестирование и dependency hell. За ту же зарплату! Как это вообще может не понравиться?


                                                    Вообще-то для этого уже давно изобрели UML, но это «некруто», поэтому давайте изобретём Open API и будем его лепить даже для внутренних сервисов — будем круто.

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


                                                    Ну, надеюсь в целом то понятен был ироничный ключ? У каждой технологии есть плюсы и минус. У микросервисов по существу намного больше плюсов. Что уж до багов — то разворачивать клубок зависимостей в монолитном аде — это то ещё удовольствие. Единственный (достаточно объективный) плюс за монолит — это значительно более высокая производительность и требовательность к ресурсам в целом, которые сегодня стоят значительно дешевле часов программистов (к сожалению, в СНГ ещё не совсем так и это сильно бьёт по общей тенденции, в т.ч. в распространении микросервисов). Основные её положения (вернее даже следствия) — это абсолютно и ни за что нельзя их душить по ресурсам, это адекватно настроенная оркестрация и достаточно продвинутый и компетентный менеджемент (да, эти товарищи свои зарплаты имеют не просто так), а вот к программистам требования уже сильно падают. По простой причине — решаемые задачи уже не так сильно отличаются от лабораторных. И, к слову, вот здесь тоже есть неприятный момент связанный с нерепрезентативной выборкой — понятное дело, что когда кадры удушенны качеством качество продукта в любом случае стремительно падает.

                                                      +3
                                                      Все-таки, я позволю себе вас поправить: в микросервисах намного больше плюсов в тех проектах, для которых микросервисы подходят. А таких проектов — абсолютное меньшинство из-за того, что микросервисы помимо плюсов привносят и много минусов и на большинстве проектов минусы будут перевешивать.
                                                        –1

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

                                                          +2
                                                          Потому что ресурсы сегодня очень дешёвые
                                                          Это не так. Посмотрите, как изменилась пропускная способность сети за 20 лет (это то, как коммуницируют веб-сервисы, то есть их bottleneck). Она не сильно выросла. При этом объём данных сильно возрос.
                                                          +2

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

                                                          +4
                                                          Что уж до багов — то разворачивать клубок зависимостей в монолитном аде — это то ещё удовольствие.

                                                          Если ребята не смогли в монолит поиграть, тоже самое будет и с микросервисами.
                                                          Мне довелось выискивать баги в микросервисах и это то еще приключение.
                                                          В монолите мне хотябы инструментарий позволяет зависимосте находить, а с микросервисами… пока что — это такой дикий запад, дебажить приходится по логам, либо запуском половины системы у себя локально и дебажишь в итоге сразу 10 приложений.
                                                          И я согласен с тем, что у микросервисов много плюсов, особенно если они применяются в правильном месте, но выискивание ошибок, это, по моему мнению, один из главных минусов, тулинга по сути никакого нет.
                                                            0
                                                            Если ребята не смогли в монолит поиграть, тоже самое будет и с микросервисами.

                                                            И да, но не совсем. На самом деле микросервисы крайне лояльны к плохой документации, достаточно толерантны к плохим горизонтальным коммуникациям внутри команды, очень терпимы к относительной нестабильности ПО и низкой "грязной" производительности.


                                                            То, что их тяжело "чинить", скорее всего просто плохая архитектура. Если связность микросервисов такая, что они не могут работать "изолированно", то это очень, очень плохая история. Также, микросервисы практически вынуждают покрывать код тестами, причём юнит тесты практически из коробки конвертируются в функциональные, настолько всё замечательно, что юнит тесты можно даже просто игнорировать, заменив их полностью моками.


                                                            Ну и да. Как по мне, туловый дебагинг скорее признак как низкого качества кода, так и недостаточной квалификации. Сам немного страдаю от последнего, но это лишь повод развивать траблошутинг, а не жаловаться на отобранные F9-F12.

                                                              +4
                                                              На самом деле микросервисы крайне лояльны к плохой документации, достаточно толерантны к плохим горизонтальным коммуникациям внутри команды, очень терпимы к относительной нестабильности ПО и низкой «грязной» производительности.

                                                              Вот тут я вас совсем не понял. Это описание какой-то компании из ада, я даже в стартапах такого трэша не видел…

                                                              То, что их тяжело «чинить», скорее всего просто плохая архитектура.

                                                              Спасибо, буду знать! /сарказм

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

                                                              Это вы так пошутили?

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

                                                              Что такое «туловый дебаггинг»? Это когда я дебаггером дебажу?

                                                              Сам немного страдаю от последнего, но это лишь повод развивать траблошутинг, а не жаловаться на отобранные F9-F12.

                                                              Ну да, я о том же. Берем бубен и выполняем необходимые ритуалы.
                                                              Но тут проблема другая, если у вас лучилась бага, которая пролетела по нескольким микросервисам, и чинить трудно, и тесты писать придется дополнительно интеграционные, возможно не тривиальные. И ни дай бог это публичный апи затронет. Ну и скоординировать деплой будет весело.
                                                                +2
                                                                если у вас лучилась бага, которая пролетела по нескольким микросервисам, и чинить трудно, и тесты писать придется дополнительно интеграционные, возможно не тривиальные
                                                                И не только баг. При волатильных бизнес-требованиях придётся постоянно либо переделывать boundaries между сервисами с огромными трудозатрами, либо лепить костыли и технический долг.
                                                                  +1
                                                                  При волатильных бизнес-требованиях

                                                                  Я с вами на 100% согласен.
                                                                  Эти волатильные требония, как раз и являются той самой главной причиной почему у нас в монолитах появляется то, что мы называем плохой архитектурой и костылями. Все меняется очень быстро.

                                                                  И в микросесвисах получается тоже самое. Только теперь зависимости становятся неявными и отслеживать эти зависимости мы должны логированием и мониторингом. Но в итоге какой-нибудь микросервис который запускается только в новый год, каждый новый год будет падать, т.к. про него все забыли.
                                                                    0

                                                                    При волатильных бизнес-требованиях или мы делаем очередной интернет-магазин или пора бить ~серпами~ документами по ~яйцам~ по заказчикам. Некоторые вещи по аджайлу не делаются. Те, которые делаются, обычно достаточно простые для планирование. Если есть возможность заранее спланировать достаточный API для взаимодействия достаточного количества сервисов — это абсолютно не проблема. Причин для изменений boundaries должно быть больше, чем "ну, мы тут захотели красную кнопку, а не зелёную". А если продукт внезапно делает сальтуху с разворотом с переобувкой в полёте — это проблема инвесторов, учредителей и топ-менеджемента. Не ваша.

                                                                    0
                                                                    Спасибо, буду знать! /сарказм

                                                                    Половина моего изначального комментария сарказм. Сказка, да в ней намёк.


                                                                    Это вы так пошутили?

                                                                    Да ну? Правда что ли? Честно, я не отвечал несколько дней потому что устал, простите.


                                                                    Берем бубен и выполняем необходимые ритуалы.

                                                                    Ну. Если логическое мышление, общее владение кодом и архиектурное понимание — для вас это бубен. Простите. Почти любую ошибку можно решить без дебаггера. Вернее — только лишь и можно, очень часто дебаггер лишь усугубляет поиск, прочёсывая совершенно ненужные места. Более того, сам подход микросервисной архиектуры сулит такое блаженство, как максимально объективное взаеимодействие. Жаль только, что люди не умирают от неправильных концептуальных решений, простите мне сие лицемерие. Избыточное API — мёртв. Сломанная аутентификация — мёртв. Поломал наследственность — мёртв. Расплодил костылей — мёртв.


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


                                                                    И ни дай бог это публичный апи затронет.

                                                                    Эм… Причём здесь, к чёртовой бабушке, публичиный API? Смешались, кони люди. Ага. Если публичный API работает — зачем менять внутренний? Если публичный API не работает — каким образом изменения не затронут публичный? Вот здесь я прям поломался.


                                                                    Ну и скоординировать деплой будет весело.

                                                                    Если вы тимлид и у вас не получается — вы плохой тимлид. Если вы менеджер и у вас не получается — пора искать другие сферы деятельности. Если вы (хоть сеньёр) программист — это не ваша проблема, при условии, конечно, что вы не саботируете разработку.

                                                            +6
                                                            Я, как тим-лид, примерно считал оверхед по времени разработки в микросервисной архитектуре. Он был от 30%. Это время только разработчиков. Про дополнительные затраты на инфраструкту и CI/CD вообще молчу. Также, появляется больше багов, т.к. распределенная система сложнее и делается больше ошибок, усложняется отладка и очень сильно усложняется тестирование.

                                                            Так что для себя вывод сделал однозначный — если в команде человек 10, максимум, разрабов, то о микросервисах даже и говорить не надо.
                                                              –7

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

                                                                +2
                                                                в который вы не впихнете новую версию библиотеки или какую нибудь реактивщину

                                                                а зачем?
                                                                  –3

                                                                  а затем :)

                                                                    +1
                                                                    «Стильно, модно, молодежно» или есть бизнес-велью выраженное в цифрах?
                                                                      0

                                                                      Что вы в цифрах хотите померять? Или вы хотите, чтобы я описал все случаи когда нам может понадобиться использовать новую версию какой либо библиотеки?
                                                                      П.С. Попробуйте найти людей кто захочет идти на легаси проект с ангулар v1

                                                                    +1

                                                                    Пара кейсов:


                                                                    • Была использована среденей популярности система каких-нибудь учётов рабочего взаимодействия, которая нашла в себе какие-нибудь security issues, а на вашу версию не прилетает security update. Не бывает?


                                                                    • Какой-нибудь неназванный javascript framework стал отваливаться на некоторых браузерах в силу особого положения луны, однако его поддержка не включает конкретно эти луны в конкретно этих положениях браузера, посему единственные варианты — миграция на другой framework или посылание конкретно этих лунных особенностей на йух. Не бывает? Совсем-совсем?



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


                                                                    foo<2.71 depends on doo<3.14
                                                                    bar>8.31 depends on doo>3.14

                                                                    И тут только c'est la vie. Ну, вернее можно, конечно, разнести их в разные сабмодули, бинарно несовместимы, но получим те же микросервисы, только в профиль. Можно вообще отказаться от foo или bar в пользу moo или oink, но это абсолютно не значит, что эти решения окажутся дешевле, чем якобы некоторый оверхед на микросервисы.

                                                                      +2
                                                                      Ну, вернее можно, конечно, разнести их в разные сабмодули, бинарно несовместимы, но получим те же микросервисы, только в профиль

                                                                      Ну, не совсем.

                                                                      Не будет затрат на разработку (и отладку) асинхронности, конвертацию в json (или другой формат) и обратно, вызовов http, обработку http ошибок и таймуатов, правильную авторизацию и безопасность внутренних вебсервисов, задержек на сетевое взаимодействие, совместимость интерфейсов будет гарантироваться на уровне компиляции, развертывание будет одним приложением.

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

                                                                      В целом, могут быть ситуации когда плюсы микросервисов перевесят минусы, но далеко не всегда.
                                                                        –2
                                                                        Не будет затрат на разработку (и отладку) асинхронности

                                                                        Простите, а какие там затраты окромя заранее правильного подхода? К тому же, если в микросервисах нужна реальная асинхронность (на долгие таски) — почему в монолите можно обойтись без неё? Даже более того, разве в монолите подход не более сложный, связанный с тасками/тредами, семафорами/мьютексами и общими ресурсами? В общем, выстрелить себе в ногу — простейшая задача.


                                                                        конвертацию в json (или другой формат) и обратно

                                                                        С каких пор на каком-то более менее популярном в продакте языке программирования не подвезли библиотек для сериализации в json, или, допустим, protobuf?


                                                                        вызовов http,

                                                                        О да, вызов http внезапно стал рокетсайнсом посильнее RPC.


                                                                        обработку http ошибок и таймуатов

                                                                        А коды возвратов функции или обрабатывать исключения?


                                                                        правильную авторизацию

                                                                        Это такая уж проблема? Ничего здесь изобретать не надо.


                                                                        безопасность внутренних вебсервисов

                                                                        То есть безопасность внутреннего кода не несёт оверхедов? И даже больше, а разве изоляция на уровне сервисов одного класстера не безопаснее, чем изоляция собственными силами в рамках одного монолита? Не, конечно, можно изобрести и process isolation и даже machine isolation, но вопрос — а оно будет дешевле в итоге? Во всех смыслах.


                                                                        задержек на сетевое взаимодействие

                                                                        Ага. Там та-акие задержки, что некоторые "монолиты" на php работают в сотни раз медленнее гугловых поисков по кластерам из сотен нод. Может стоит тогда делать как в google?


                                                                        совместимость интерфейсов будет гарантироваться на уровне компиляции

                                                                        Она бы гарантировалась, если бы разговор был про Java, C# или C++, может немного и Go, и то. С оговорками. Можно вспомнить про строгого Haskell, но… Не будем. Вообще, совместимость интерфейсов — это медаль с двумя сторонами, вы как бы гарантировали совместимость, но ценой жёсткой привязки к декларированному интерфейсу, который потом тащите через весь проект. А duck typing даст гарантий не больше, чем декларированный API на микросервисе. И вообще, это если язык компилируемый.


                                                                        развертывание будет одним приложением

                                                                        А сегодня проблема развернуть кластер? Когда есть docker, kubernetes, terraform, aws cloudformation. Да и потом, с чего бы это проблема? Если при разворачивании у нас отвалился модуль авторизации, например, (правильно спроектированный) микросервес может работать без этого функционала (из коробки), а вот монолиту придётся дополнительно продумывать данную возможность.


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

                                                                    0
                                                                    Новую версию библиотеки — легко, если есть хорошее покрытие.

                                                                    Другую парадигму — да, очень тяжело. Но проблема в том, что и другую парадигму и на микросервисах впихнуть не так просто, как кажется. Есть много не самых очевидных проблем, которые так или иначе всплывут:
                                                                    • Обучение разработчиков
                                                                    • Грань между свободой выбора технологии и хаосом очень тонка и будет потрачено крайне много времени на ее очерчивание
                                                                    • Асинхронный код, если же мы заговорили о нем, часто требует и других настроек auto scaling'а
                                                                    • Выплывает куча разных болячек, если использовать не проверенный временем стек технологий


                                                                    Казалось бы, не так и страшно, но в реальном проекте, при минимальном наличии бюрократии/замороченных архитекторах, будет плохо. Большинству бизнесов надо фичи деливерить, а не хотелки разрабов удовлетворять.

                                                                    CI/CD — это не только Jenkins (или альтернативу) поставить. Это и подходы к тестированию, и правильная реализация этих тестов. К примеру, в случае микросервисов без контрактного тестирования проблемы интеграции будут всплывать постоянно. End-to-end тестов необходимо будет больше, а их делать сложнее.

                                                                    Кроме тестов, есть еще куча других процедур и проверок: всякие проверки на обратную совместимость API, создание документации, настройки zipkin/jaegor'ов, настройки сетевого стека и т.п. и т.д.

                                                                    Кроме того, в нормальных ситуациях у микросервисов свои хранилища данных. Их тоже надо обслуживать, мигрировать, реплицировать и т.д. Затраты на это огромны.

                                                                    Ну и последнее — про scaling. Все так часто его приводят, но почему мало кто вспоминает, что на большинстве проектов большинство сервисов зависят от неких хранилищ данных. И масштабирование зачастую упирается в эти хранилища, а не в инстансы stateless сервисов.
                                                                      +1

                                                                      Переход на микросервисы предполагает обычно, что единое хранилище разбивается на несколько. Уже какое-то масштабиррвание. А микросервисы позволяют ещё и сменить хранилище на более подходящее для конкретной задачи.

                                                                        +3
                                                                        Новую версию библиотеки — легко, если есть хорошее покрытие.

                                                                        нет — потому что окажется, с новым подходом идет библиотека v2, у вас используется v1 и пока вы весь монолит не перенесете вы не сможете мигрировать на нее. А чтобы перенести надо чтобы все люди которые пилят свои модули взяли и нашли для этого время одновременно. И как показывает практика это очень тяжело выполнимое условие.


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

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


                                                                        Большинству бизнесов надо фичи деливерить, а не хотелки разрабов удовлетворять.
                                                                        Вы передергиваете. Почему вы например считаете что переход например с мемкеша на редис который уменьшил в несколько раз время ответа это хотелки девелоперов?
                                                                        Или изменения архитектуры и уход с стандартной thread per action на реактивный стек позволил уменьшить потребляемую память с 5Гб до 1Гб тем самым экономя деньги на каждом инстансе плюс всплески трафика обрабатываются без проблем это тоже хотелки девелоперов?

                                                                        Их тоже надо обслуживать, мигрировать, реплицировать и т.д. Затраты на это огромны.

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


                                                                        И масштабирование зачастую упирается в эти хранилища

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

                                                                          0

                                                                          Простите, а каким образом при переходе к nio потребление памяти в 5 раз сократилось? Можно конкретику — на каких именно объектах?


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


                                                                          В общем-то, я за МАКРОсервисы/soa или как там оно называется. Пихать все в один процесс, действительно, очень часто неразумно. Но большинству проектов очень долгое время будет прекрасно на модульном монолите житься.

                                                                            0
                                                                            Простите, а каким образом при переходе к nio потребление памяти в 5 раз сократилось? Можно конкретику — на каких именно объектах?
                                                                            Там только пару Гигабайт ушло потому что было несколько тысяч потоков :)
                                                                            –1
                                                                            нет — потому что окажется, с новым подходом идет библиотека v2, у вас используется v1 и пока вы весь монолит не перенесете вы не сможете мигрировать на нее

                                                                            Если эта библиотека используется только внутри модулей, а не между ними — можно и сразу две версии использовать.

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

                                                                          Вы в вашей компании серьёзно не будете против, если я свой микросервис сделаю на хаскеле или на идрисе?

                                                                            0

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

                                                                              +2

                                                                              Вы же только что говорили, что я могу делать что угодно, пока публичный контракт сохраняется. Мы публичный контракт обговорили, и я иду делать на произвольном языке, разве нет?


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

                                                                                +1

                                                                                Публичный контракт может включать и требование типа "мэйнстрим ЯП" :)

                                                                                  0

                                                                                  Это уже какой-то притянутый за уши контракт, ИМХО.


                                                                                  Впрочем, ладно. Тогда выкидываем идрис и оставляем хаскель.

                                                                                    0

                                                                                    Вполне нормальный организационный контракт.

                                                                                      +2

                                                                                      Я так понял, что публичный контракт выше — это API.


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

                                                                                        0

                                                                                        Это не только API. Поведение тоже контракт, не просто сигнатуры методов или ендпоинтов, но и их семантика. Инфраструктурные соглашения типа "логи пишем в stderr/stdout", "несекретные данные конфигурации передаём через env, секретные через vault" — контракт с девопсами, например. Пишем микросервисы только на A, B и C версии -1 от последней минорной на момент старта — контракт со всем отделом разработки.

                                                                                          0

                                                                                          У меня, кстати, есть два забавных опыта.


                                                                                          1. Работа в большой организации, с отдельными девопсами, SRE и прочими замечательными людьми. А ещё там была SOA, но не было угара по микросервисам (особенно уровня «сервис для инкремента числа в редисе», как тут рядом предлагают). Основной язык — плюсы.
                                                                                            Я был довольно близок к спонтанно возникшей Haskell infra team из любителей хаскеля, и хоть самой инфрой и не занимался особо, мог наблюдать, как и сколько сил на что тратится. Короче, поддержка логгинга, поддержка общекомпанейских feature flag'ов, общекомпанейской шины для общения сервисов друг с другом, и так далее, реализовывалась очень быстро силами практически пары человек (по факту, почти всю работу по куче разных вопросов и APIшек сделал интерн за два с половиной месяца). При этом с результатом было работать удобнее, чем с плюсовым, поддерживавшимся официально, а ресурсов на это было затрачено меньше, чем на поддержку питона (на который была официально выделена целая команда из кучи человек, которые за год что-то там как-то там сделали).
                                                                                          2. Работа в мелком полустартапе (тот C++-шоп, о котором я говорил ниже). Там вот вообще был трэш, угар и содомия, и были вещи на перле и старой джаве, были вещи на руби, были вещи на скале, ну и появились (стараниями вашего покорного слуги) вещи на хаскеле. Тоже всё норм.
                                                                                            0

                                                                                            Есть компании, которые не просто не против зоопарка, а даж поощряют его, если хоть какие-то плюсы компании даёт. Может даже не технические, а чисто мотивационные для разработчиков: попробовать запустить в продакшене что-то на платформе, которая нравится/хочется. Даже если уйдёт разработчик, выбравший экзотику (по крайней мере в рамках компании), то микросервис можно просто выкинуть и написать новый в рамках того же контракта, когда понадобится его развить. А пока работает — прсто не трогают.

                                                                                  +1
                                                                                  Вы же только что говорили, что я могу делать что угодно, пока публичный контракт сохраняется.

                                                                                  Да, только когда у вас инфраструктура на джава и пхп то запилить сервис на хаскеле выйдет времени ого-го как больше. Посколько в джаве у вас уже есть готовое ядро которое и логирует куда надо и авторизация прикручена. А в хаскеле это все придется реализовывать. Соответственно вам надо будет убедить остальных членов команды и бизнес, что вместо Х времени и понятный язык остальным членам команды, вам надо будет 5Х времени и хаскель на который потом никого не найти. И если вы это сделаете, то конечно пишите на хаскеле.

                                                                                    0
                                                                                    Да, только когда у вас инфраструктура на джава и пхп то запилить сервис на хаскеле выйдет времени ого-го как больше. Посколько в джаве у вас уже есть готовое ядро которое и логирует куда надо и авторизация прикручена. А в хаскеле это все придется реализовывать.

                                                                                    Я всё равно не до конца понимаю.


                                                                                    Если у вас есть код на условной джаве, питоне, жс и го, то это означает, что логирование и авторизация (а что за авторизация в микросервисах, кстати?) сделаны уже в четырёх экземплярах. Что принципиально меняет пятый?


                                                                                    Более того, у вас ведь не было кодовой базы изначально на всех четырёх языках. Когда-то кодовая база начиналась заведомо с одного языка. Значит, вы и тогда потратили время на логирование и авторизацию.


                                                                                    хаскель на который потом никого не найти.

                                                                                    Вот, кстати, на последнем месте работы (почти чистый плюсокодинг) людей с хаскелем в резюме я видел куда чаще, чем людей с Go в резюме.

                                                                                      0
                                                                                      Что принципиально меняет пятый?

                                                                                      Потратили уже условно 4*N денег на одно и тоже, а тут вы предлагаете потратить ещё N, не объясняя зачем :)


                                                                                      (почти чистый плюсокодинг) людей с хаскелем в резюме я видел куда чаще, чем людей с Go в резюме.

                                                                                      Бытует мнение, что с Go или Rust на плюсы не переходят, не видят смысла :)

                                                                                        0
                                                                                        Потратили уже условно 4*N денег на одно и тоже, а тут вы предлагаете потратить ещё N, не объясняя зачем :)

                                                                                        Я вот что-то думаю, что трудоёмкость написания и отладки кода на разных языках всё-таки немножко не равна.


                                                                                        Бытует мнение, что с Go или Rust на плюсы не переходят, не видят смысла :)

                                                                                        Изящно, одобряю!


                                                                                        А с JS и питона, получается, переходят? Кстати, раст я в резюме тоже видел.

                                                                                          0
                                                                                          Я вот что-то думаю, что трудоёмкость написания и отладки кода на разных языках всё-таки немножко не равна.

                                                                                          Я "условно" написал.


                                                                                          А с JS и питона, получается, переходят?

                                                                                          Угу, когда скорости, например, не хватает. Или динамика достаёт.

                                                                                            0

                                                                                            Для этого логичнее менять один лишь язык, а не работу целиком.

                                                                                        0
                                                                                        Что принципиально меняет пятый?

                                                                                        ничего — как сказал выше — вам всего лишь надо убедить, что хаскель того стоит.


                                                                                        а что за авторизация в микросервисах, кстати?

                                                                                        что запрос действительно пришел от указанного микросервиса, а не кто то подделал запрос. Что у него есть права на доступ к этому ендпоинту.


                                                                                        Когда-то кодовая база начиналась заведомо с одного языка. Значит, вы и тогда потратили время на логирование и авторизацию.

                                                                                        Совершенно верно, а теперь вам надо продать идею с хаскелем :)))

                                                                                          0
                                                                                          что запрос действительно пришел от указанного микросервиса, а не кто то подделал запрос. Что у него есть права на доступ к этому ендпоинту.

                                                                                          А зачем? Я не шарю в микросервисах, но зачем это делать, если вся сеть подконтрольна вам? Вы же не выставляете все эти микросервисы голым задом в интернет?


                                                                                          Совершенно верно, а теперь вам надо продать идею с хаскелем :)))

                                                                                          Ну это просто, ведь всем известно, какие люди на нём производительные, и как там все безопасно и безотказно!

                                                                                            0
                                                                                            А зачем? Я не шарю в микросервисах, но зачем это делать, если вся сеть подконтрольна вам? Вы же не выставляете все эти микросервисы голым задом в интернет?

                                                                                            Но проблемы то могут прийти не только от тех кто снаружи :)
                                                                                            Плюс есть еще заморочки связанyые с SOX control


                                                                                            Ну это просто, ведь всем известно, какие люди на нём производительные, и как там все безопасно и безотказно!

                                                                                            Мне кажется на текущем этапе самые производительные люди это на пхп, ЖС, Джава, С# если мы говорим за что то обыкновенные сервисы, где надо писать бизнес логику и куда то ходить за данными. А с хаскелем вы к примеру к AWS сервисам будете ходить через имплементацию сторонних людей, а не Амазона. И никто не знает, где вы уткнетесь что такой то метод не реализован или к сервису вообще sdk нет. Вот мне нравится Раст, я начал пет проект писать на нем под AWS и внутренн.ю кухню, в результате набил шишок плюнул и взял официальные TypeScript SDKs.

                                                                                              0
                                                                                              Но проблемы то могут прийти не только от тех кто снаружи :)

                                                                                              А зачем защищаться от тех, кто внутри? Опять же, я, скорее всего, работал над теми проектами, где это просто нерелевантно, поэтому мне интересно.


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

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


                                                                                              А с хаскелем вы к примеру к AWS сервисам будете ходить через имплементацию сторонних людей, а не Амазона.

                                                                                              Конкретно в хаскеле оно кодогенерится из тех же описаний API, из которых оно генерится под поддерживаемые языки.


                                                                                              У меня, кстати, в своё время ушёл ровно день на то, чтобы разобраться, что вообще за AWS (как-то далёк я от всего этого хайпа), и наваять там тулзу для оптимизированного параллельного скачивания с S3. По-моему, норм.


                                                                                              И это я уж не говорю о каких-то сложных вещах. Сейчас пишу кое-что, что на питоне, го или джаве я писать бы точно не стал.

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

                                                                                    Ну это тоже бизнес-модель, в принципе.


                                                                                    Хотя от компании и задач зависит. Знаю места, где люди первый год вообще не приносят прибыли, а только въезжают.

                                                                                      0
                                                                                      Хорошее замечание, да, это был стартап в первые 3 года жизни.
                                                                                +2
                                                                                При 20+человеках на монолите которуму 10+ лет начинается ад.
                                                                                Микросервисы проще перписать/обновить на новый стек/новую архитектуру. С монолитами иногда это бывает физически невозможно(цена равна цене всех вложенных челвоеко-лет в этот проект)
                                                                                Но если у вас один разработчик делает микросервсиы которые связаны между собой то да, оверхед может быть и больший.
                                                                                CI/CD — зависит от проекта, я видел ситуации где он упрощался, так и те где он значительно усложнялся.
                                                                                Распределенная система часто гораздо проще в тестирвоании, сильно зависит от их связанности сервисов т.к. каждая комнада тестирует только свой микросервис. Часто при любом изменении в монолите требуется полная регрессия, которая занимает дни, а с микросервисам достоаточно легко тестируется только один небольшой кусок и покрывается 100% кейсов.
                                                                                По-моему как и везде-главное разумно делить сервисы и понимать где нужен монолит, а где лучше подойдут микросервисы. А плюсы/минусы есть у обоих подходов и в любом из них можно наломать дров.
                                                                                  +2
                                                                                  Вы говорите про те проекты, где микросервисы спроектированы хорошо. Так скажем, «по стандарту». Лично я таких проектов не видел. В реальности у меня жизнь всегда вносила коррективы, и микросервисы раз за разом предлагались в проекты не по правильному балансу плюсов и минусов, а из-за хайпа.

                                                                                  Что мешает тестировать монолит теми же подходами, что и микросервисы, — для меня загадка. Если это не жуткое легаси, то я от монолита ровно также ожидаю модульного подхода с нормальной пирамидой тестирования.
                                                                                  –1

                                                                                  Что. Где. Как? Если микросервис нельзя расписать на пальцах даже дошкольнику — то это НЕ микросервис. Вот буквально — доходит до того, что на пайтоне едва ли не однострочником поднимается веб-сервер, единственная задача которого в редис (или постгри) записывать единственное число — инкрементальный номер билда. И это ну настолько простая задача, что на неё даже покрытие тестами становится ненужными.


                                                                                  Суть микросервисов, если что, не в децентрализации, это лишь выгодный бонус, но не более. Самый смак — в тотальной декомпозиции. И для каждой задачи можно выбрать свой идеальный инструмент. С этим ведь тяжело поспорить? Какая-нибудь бизнеслогика на Java, стат. анализ на Python, прикрученные графики вообще на бинарях dotviz (спасибо ахуенному линуксоиду, который умеет это дерьмо варить =) — и всё это не просто крутится, оно ахуенно работает.

                                                                                    +3
                                                                                    Вы, наверное, говорите о той ситуации, где микросервисов владеет выделенная команда? Где независимая разработка и деплой? Где зависимости и зависимые четко известны и предсказуемы?

                                                                                    Потому что если нет, то объяснять надо не только сам микросервис, а еще кучу всего, начиная с предметной области. И чтобы понять как работают некие комплексные бизнес сценарии в микросервисах в какой-нибудь банковской сфере, надо упороться. С монолитом тоже надо будет упарываться, но там IDE еще сильно поможет.

                                                                                    А если же ответ — «да», то я вас огорчу — таких проектов очень мало.

                                                                                    Я прекрасно знаю о тотальной декомпозиции. Был такой опыт и неоднократно. И опыт это был крайне негативный. Начиная от постоянных срачей какие технологии и как использовать, чтобы «свобода выбора технологий» не превратилась в «неподдерживаемый хаос» и кончая тем, что такие вещи, как «независимая разработка» и «независимые релизы» становились просто невозможными. Я уж молчу, что набирать разрабов под разные стеки технологий (Java, Python, бинари и т.п.) — тот еще геморрой.

                                                                                    Еще раз: можно ли построить хорошую микросервисную архитектуру, чтобы проект от этого выиграл? Да, конечно. Подходят ли микросервисы большинству проектов — нет.
                                                                                +1

                                                                                Как вариант, это еще возможность довольно просто привлекать аутсорс. Или распределять работу между разработчиками разного уровня.

                                                                                –24
                                                                                Удивительно читать такие статьи, ещё недавно из каждого утюга за микросервисы голосили. А каждый вонючий джун норовил наплодить их штук по 5 даже в пределах одного физического сервера, а потом есно засунуть в докер, вместе с субд. Попутно по тупости высунув в инет без авторизации )

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

                                                                                Bare metal + java EE форева )
                                                                                  +5
                                                                                  Удивительно читать такие статьи
                                                                                  А я вот почему то не верю что вы статью прочитали. Разве что заголовок…
                                                                                  +9
                                                                                  Праздники кончились, наступает микросервисное похмелье…
                                                                                    +3

                                                                                    На прошлой работе был сравнительно небольшой сервис на java EE микросервисах. Я, правда, тогда был не разработчиком, а сис. админом. Программные коды почти не читал, но по логам баги с программерами отлавливал.


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


                                                                                    Слабым местом считаю, что если создавать распределенные и отказоустойчивые микросервисы в вакууме, то сервера начнут работать на 80℅ на обслуженивание инфраструктуры в которой крутится приложение и на 20% на само приложение.
                                                                                    Когда у нас это все крутилось в датацентре и там было запущено 20 виртуальных машин, каждая из которых крутила полноценный линукс и микросервис на 500кб, было терпимо. А потом переехали в AWS, и оказалось, что чтобы запустить средний сервис надо платить за 20 виртуалок.
                                                                                    "Отказоустйчивость" ушла на второй план, оказалась, что одна виртуалка может вместить в 2-3 раза больше сервисов.


                                                                                    И все же в современных реалиях микросервисы рулят, позволяя использовать serverless архитектуру и гибко масштабируясь в условиях облаков. Хотя и требуют больше навыков в разработке.

                                                                                      +4
                                                                                      оказалось, что чтобы запустить средний сервис надо платить за 20 виртуалок.
                                                                                      «Отказоустйчивость» ушла на второй план, оказалась, что одна виртуалка может вместить в 2-3 раза больше сервисов.


                                                                                      Docker?
                                                                                        +1

                                                                                        Логичное и ожидаемое замечание, но так как это была java EE, то проще было засунуть два томката с разных серверов в один, без добавления ненужных уровней сложности.


                                                                                        Кстати из докера я, наоборот, вынул пару сервисов на glassfish и положил прямо в папку рядом с tomcat.
                                                                                        Мало того, что сэкономил на ресурсах, так еще и обслуживать меньше пришлось, потому что под докером все постоянно падает.
                                                                                        И вообще я не понимаю как микросервисная java ee может работать адекватно в докере.
                                                                                        Сервер приложений (glassfish, tomcat, jboss etc) занимает 99% вычислительных ресурсов, если на нем крутится единственный распределенный микросервис.

                                                                                          +1
                                                                                          как микросервисная java ee может работать адекватно в докере

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

                                                                                          А вообще, проще, конечно, перевести чистое java ee на spring/spring boot при переходе в микросервисы, это получиться почти тот же EE но намного более легковесный.
                                                                                            0
                                                                                            Это с чего бы вдруг? Я не защищаю EE — это уже мертвец. Просто у меня есть большой опыт работы с ним. Там, благодаря архитектуре, тоже сервисы. При правильном написании вполне изолированные.
                                                                                            Если просто использовать WebSphere Liberty Profile или Wildfly — все будет очень даже легковесным. Вполне сопоставимо с разворачиванием spring контейнера.
                                                                                            0
                                                                                            И вообще я не понимаю как микросервисная java ee может работать адекватно в докере.

                                                                                            А зачем сервер приложений запихивать в докер, если есть Spring?

                                                                                              0

                                                                                              Чем сервера приложений лучше докера? В докере запускается просто java app.jar

                                                                                                +1
                                                                                                Чем сервера приложений лучше докера? В докере запускается просто java app.jar

                                                                                                Эээ, ну наверное тем что в них можно хоть как-то контролировать внутренние процессы, без гемороя деплоить артефакты (или как там называются *.war архивы), настраивать connection pools. Все это можно делать через web интерфейс, можно готовый xml файл настроек закинуть.
                                                                                                Ну и самое главное, не надо менять всю логику, архитектуру, способ отслеживания падения сервисов, городить костыли для докера, которые в сервере приложений есть из коробки.


                                                                                                Если в одном предложении, то лучше тем же, чем apache лучше запущенного чере $ php -S девелоперского standalone php сервера

                                                                                          +1
                                                                                          А видь можно совместить микросервисы с моделью акторов. Тогда большинство ваших проблем решится сама собой. К примеру есть готовый кроссплатформенный Open Source Framework proto.actor
                                                                                            +1

                                                                                            Я так понимаю до первого момента, когда одно атомарное изменение должно аффектить несколько независимых акторов.

                                                                                            +3
                                                                                            [Микро]сервисы — это всего лишь инструмент, который пригоден для определенного и конечного множества случаев. Например, в нашей системе — изменение состояния вызывает кучу нотификаций и вторичных изменений, часть которых вообще не относится к ядру и делаются под заказчика.
                                                                                            Все эти вторичные изменения не являются транзакционными — поэтому архитектура event-ориентированных микросервисов для нас работает неплохо. Если бы нужна была consistency — мы бы делали все иначе.
                                                                                              +1
                                                                                              Не делайте микросервисы, не используйте ООП
                                                                                              Пишите на чистом C. Без ошибок. И тратьте кучу денег.
                                                                                                0
                                                                                                А потом у вас случатся 29 клиентов — и у каждого своя версия, и для каждого апгрейда нужны подписи двух VP (из реальной жизни).
                                                                                                +3
                                                                                                Если бы платили за каждый срач по микросервисам с монолитчиками, я бы был богат.
                                                                                                Не буду растекаться мыслью, опишу неоспоримые плюсы микросервисной архитектуры, которые компенсируют стоимость владения ей:

                                                                                                1. Возможность развивать продукт независимыми сегментами. Т.е. сегодня вы захотели впилить новый сегмент, который потенциально может дать вам прибыль. Вы берете отдельную команду, ставите задачу и она уходит в запил со своим стеком технологий (в разумных пределах). Он максимально адаптирован для нужд субпродукта. На выходе вы получаете результат, который интегрируете в уже существующую АС. Если не выстрелило — сервис выпиливаться без лишних страдений.
                                                                                                2. Адекватное масштабирование микросервисов. Пример — микросервис авторизации, который эмитирует JWT, допустим. Вероятность атаки на него крайне высока. В момент DDoS мы можем масштабировать только этот микросервис, что позволит справиться с атакой. При этом не нужно будет разворачивать кучу нод полноценной АС, как в случае с монолитом.
                                                                                                3. Независимая релизность. Зачастую, чтобы выкатить релиз монолита нужно провести грандиозный регресс. Релиз раз от раза откладывается из-за обнаруженных багов в различных областях монолита. Это неадекватно задерживает выпуск нужных фич из-за багов в каких-то мелочах. Не будем забывать, что разработка не прекращается. И разрыв между версиями с каждым часом прирастает. Микросервисы позволяют выпуск дробить. И выкатывать сегменты системы независимо.
                                                                                                4. Управление контурами безопасности. Монолит имеет доступ ко всем данным. Это грандиозная дыра. Контролировать контуры безопасности с микросервисной архитектурой гораздо проще и надежнее. Тот же сервис авторизации может находиться в отдельной подсети к которой доступ будет иметь ограниченный круг лиц. Я имею ввиду прямой и косвенный (через кодовую базу монолита).


                                                                                                По сути, эти 4 пункта дают те основные профиты, ради которых и внедряются микросервисы. Есть еще масса профитов но они уже мельче.

                                                                                                Что же касается распеределнных транзакций, то это заведение «рака за камень». Никакая вменяемая АС не будет работать без кластеризации. В том числе и монолитная. И любой инсерт в БД будет приводить к тому, что по тем же проводам будут разливаться те же транзакции. Консистентность может быть потеряна в монолите запросто. Достаточно, чтобы одна нода оказалась изолирована.
                                                                                                  +5
                                                                                                  микросервисов

                                                                                                  Монолит

                                                                                                  А почему только две крайности рассматриваются? Почему просто «сервисы», которые совсем не «микро» не имеют право на жизнь. Или в Вашей терминологии, все что не «монолит» — то микросервис?
                                                                                                  Вот раньше было — отдельно сервис авторизации, отдельно какой-нибудь UI на MVC, отдельно службы по каждому продукту, отдельно сервер отчетов — и вроде работало/работает.
                                                                                                  А то иногда посмотришь на некоторых проектах — каждая отдельная таблица в общей базе должна обслуживаться отдельным microservice и быть мигрированна на другую базу (состоящую из одной таблицы).
                                                                                                    0
                                                                                                    По сути, разделение монолита хотя бы на 2 сегмента делает из него уже «плохую» микросервисную АС. Рамки микросервиса вопрос архитектурный. Дробление системы на микросервисы, естественно, должно быть осмысленным и необходимым.
                                                                                                      +2
                                                                                                      осмысленным и необходимым

                                                                                                      Вот я и о том же, может к микросервисной архитектуре нужно приходить постепенно по мере развития продукта, а не сразу клепать все направо и налево?
                                                                                                      Идеальным случаем я вижу — следующее: пишем модульно код, который в рамках одного процесса работает изолированно, а потом, просто разносим сложившиеся модули по разным процессам, изменяя транспорт взаимодействия — Http, очереди и т.д.
                                                                                                        –2
                                                                                                        Т.е. постепенно приходить к тому, что бизнесу нужно развиваться не упираясь в технические ограничения заложенные командой которая знала только PHP, допустим? Постепенно приходить к тому, что релизы должны быть своевременными? Что сливы баз это плохо?

                                                                                                        Я думаю, что тут вопрос не в постепенном развитии продукта. А в осмыслении целей продукта и выборе архитектуры для него. Если масштаб продукта не подразумевает высоких требований безопасности, своевременности релизов и всех тех профитов который описаны выше — микросервисы будут излишними.
                                                                                                          +5
                                                                                                          Вы наивно полагаете, что бизнес умирает изза того, что упирается в технические ограничения? Вы видели, хоть один бизнес проект, который закрылся, из-за того, что на php написан?

                                                                                                          Зато я видел пять проектов, которые закрылись потому что там два десятка программистов с невменяемыми зарплатами, делали проект безопасным, расширяемым, микросервисным и т.д.
                                                                                                            +1
                                                                                                            Давайте диалог продолжим после того как:
                                                                                                            1. Вы укажите, где я говорил о закрытии бизнеса из-за технических ограничений
                                                                                                            2. Вы будете контраргументировать, а не выражать субъективное мнение. Я могу напридумывать кучу спасительных случаев микросервисов и страшных историй с монолитами. Но, как видите, придерживаюсь аргументов.
                                                                                                              0

                                                                                                              Я видел проект, который закрылся из-за того, что был написан на плюсах. Видел другой проект, который не взлетел по похожим причинам.

                                                                                                                0
                                                                                                                Он был бешено популярен, пользователи туда ломились, а основатели закрыли его несмотря на то, что он приносил прибыль?
                                                                                                                  +1

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

                                                                                                              0
                                                                                                              бизнесу нужно развиваться не упираясь в технические ограничения заложенные командой которая знала только PHP, допустим?

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

                                                                                                              Я больше встречал примеров, когда релизы микросервисов очень задерживались и мешали другим. Я понимаю, что вы скажите — о неумении готовить микросервисы.
                                                                                                              Что сливы баз это плохо?

                                                                                                              Это больше безопасность и совершенно другой разговор. На некоторых СУБД, можно одну базу разбить логически на несколько (путем тех же схем) и работать независимо с разными уровнями привилегий.
                                                                                                                +1
                                                                                                                Коллеги, то, что у вас есть субъективный, негативный опыт ровным счетом ничего не значит. Как и обратное. Это лишь опыт, который можно зарабатывать по разному. Даже не буду вдаваться в подробности. Это очевидно.

                                                                                                                Сравниваются архитектурные модели. Загубить реализацию можно везде. А уж сколько монолитов загнулось из-за корявого использования ООП…
                                                                                                                  0
                                                                                                                  Это больше безопасность и совершенно другой разговор. На некоторых СУБД, можно одну базу разбить логически на несколько (путем тех же схем) и работать независимо с разными уровнями привилегий.


                                                                                                                  И как это устраняет возможность разработчика через кодовую базу получить доступ к данным этой схемы? Или к переменным окружения с паролями?
                                                                                                                    0
                                                                                                                    Или к переменным окружения с паролями?

                                                                                                                    Например на запрет простым разработчикам доступа в Production сервер с базами данных реальных пользователей или к виртулкам, где эти переменные находятся?
                                                                                                                    Если у меня есть доступ к Production системе я и с микросервисами умыкну данные. Просто буду делать это несколько дольше.
                                                                                                                      0
                                                                                                                      Вопрос доступа к прод серверам даже не поднимается. Это аксиома — отсутствие доступа к проду у разработчика.

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

                                                                                                                      Любой разработчки в монолите может влиять на любой сегмент кодовой базы. Да, можно говорить о том, что для исключения этого есть код-ревью. Но код-ревью, это человеческий фактор. Пропустить неявный бэкдор можно. А отсюда, вся система под угрозой.

                                                                                                                      Далее, алгоритмический ошибки, способные влиять на безопасность системы. Например кто-то писал бизнес-логику, хотел чтобы все работало очень быстро и поэтому зафигачил все на RAW SQL. Но забыл экранирование… и вот, уже в монолите дыра по доступу почти ко всему.

                                                                                                                      При микросервисной архитектуры, выделение, например, сервиса авторизации, автоматически блокирует доступ разработчика этого сервиса к бизнес-логике. Как и в обратную сторону.

                                                                                                                      А если и то и то пилят одни и те же разработчики? А вот тут нужно говорить еще об одной штуке, которую девелоперы как бы не учитывают и не обсуждают. Но она ключевая — микросервисная архитектура отражается не только в реализации кода, а еще и в административной схеме компании. Микросервисы это не столько для девелоперов, сколько для бизнеса.
                                                                                                                        +1
                                                                                                                        Как минимум он может получать ценную информацию о реализации алгоритмов безопасности.

                                                                                                                        Security through obscurity. В идеале, знание как работает тот или иной метод, не должно уменьшать безопасность системы в целом.

                                                                                                                        RAW SQL. Но забыл экранирование… и вот, уже в монолите дыра по доступу почти ко всему.

                                                                                                                        Я же говорил про схемы — к ним отдельные connection strings и каждая часть макросервиса или монолита имеет доступ только к определенной части в единой базе данных.

                                                                                                                        автоматически блокирует доступ разработчика этого сервиса к бизнес-логике.

                                                                                                                        С этим согласен, добавить dependency в монолите гораздо проще, чем вызвать другой отдельный сервис.
                                                                                                                        Микросервисы это не столько для девелоперов, сколько для бизнеса

                                                                                                                        Значит мы с вами с разными бизнесами встречались. Как по мне (и я считаю это идельным случаем), когда каждый член команды может независимо пилить фичи, которые могут затронуть разное количество микросервисов, поэтому должен обладать большой компетенцией.

                                                                                                                          0
                                                                                                                          когда каждый член команды может независимо пилить фичи, которые могут затронуть разное количество микросервисов


                                                                                                                          Я бы сказал, что это антипаттерн микросервисной архитектуры.

                                                                                                                          Я же говорил про схемы — к ним отдельные connection strings и каждая часть макросервиса или монолита имеет доступ только к определенной части в единой базе данных.

                                                                                                                          Ну я повторяюсь, доступ ко всем connection strings у монолита есть. Великого смысла делить БД на схемы для безопасности в случае с монолитом — нет.

                                                                                                                          Security through obscurity.

                                                                                                                          Все верно. Основная идея заключается в том, чтобы скрыть внутреннее устройство системы или реализацию для обеспечения безопасности. Это точно сделает систему более защищенной. Нежели сферический конь в вакууме, коим можно представить идеальную систему.
                                                                                                                            0
                                                                                                                            антипаттерн микросервисной архитектуры.

                                                                                                                            Впервые встречаю такое мнение, и как это может быть антипаттерном, когда очень удобно и выгодно бизнесу. Да и разработчику позволяет расширить кругозор и мыслить бизнес задачами, а не узким миром своей кодовой базы.
                                                                                                                              0
                                                                                                                              Очень удобно чем? Что один разраб делает все? Одинаково плохо? Боюсь, что бизнесу это не выгодно. Но… часто он этого не понимает. Это вопрос другой.

                                                                                                                              Разработчику расширить кругозор? А затем ему нужно зп поднять, потому, что он теперь знает (он так думает) go, C++, 1C и немного Java? Потому, что на Java получают 350К? Это выгодно бизнесу? напомню, за одинаково плохо сделанную работу во всем стеке.

                                                                                                                              У вас все сервисы на одном стеке, поэтому разработчиков можно перекидывать и они развиваются? Выход… только тогда нужно обнулять профит №4. Выгодно это бизнесу? Не думаю.

                                                                                                                              А то, что теперь во всем зоопарке микросервисов нужно ждать одного разработчика, который блочит выпуск 2, 3 или 26 сервисов? Потому, что то там попилил, его перекинули в другое место, то там… а потом релиз а у него не там не там… это выгодно бизнесу?
                                                                                                                                0
                                                                                                                                напомню, за одинаково плохо сделанную работу во всем стеке.

                                                                                                                                Если вы так заочно считаете, что человек не может делать работу хорошо (но не отлично) выбирая различные инструменты — мне точно Вас не переубедить.
                                                                                                                              0
                                                                                                                              Ну я повторяюсь, доступ ко всем connection strings у монолита есть. Великого смысла делить БД на схемы для безопасности в случае с монолитом — нет

                                                                                                                              Почему? У монолита может быть пять разных модулей и пять разных команд.

                                                                                                                              Основная идея заключается в том, чтобы скрыть внутреннее устройство системы или реализацию для обеспечения безопасности. Это точно сделает систему более защищенной

                                                                                                                              Кто мешает скрывать это в монолите? Делайте столько же репозиторией и команд, сколько в микросервисах, собирайте все для интеграционного тестирования только на серверах где у рядового разработчика не будет доступа, но api используйте обычный для данного языка, а не http c rest'ом.

                                                                                                                              Вы ровно так же не сможете запустить все микросервисы у себя на локальном компе.
                                                                                                                                0
                                                                                                                                Вы ровно так же не сможете запустить все микросервисы у себя на локальном компе.

                                                                                                                                Так это и не нужно. В общем-то на то оно и делалось. В DEV контуре ты имеешь DEV релизы с которыми интегрируешься. Их кто-то релизит, ты потребляешь. И это нормально.

                                                                                                                                Кто мешает скрывать это в монолите?

                                                                                                                                Давайте ближе к реальной жизни. Проект на Symfony, кастомный модуль эмиссии JWT. Как скрыть его реализацию от всех, за исключения 5 человек.

                                                                                                                                собирайте все для интеграционного тестирования только на серверах где у рядового разработчика не будет доступа

                                                                                                                                Ранее уже написал. Это боль, страдания и вечно падающий релиз. Потому, что нужно еще дождаться деплоя на DEV. А потом все это понять… потом попробовать вот так… и опять ждать деплоя. Это работает только в теории.
                                                                                                                                  +1
                                                                                                                                  Давайте ближе к реальной жизни. Проект на Symfony, кастомный модуль эмиссии JWT. Как скрыть его реализацию от всех, за исключения 5 человек.

                                                                                                                                  Я очень далек от Symfony и PHP, так что несмогу вам сказать за Symfony.

                                                                                                                                  Но ближе к реальной жизни в Java есть несколько вариантов:

                                                                                                                                  1. Оформить в виде подключаемого модуля (например, на C++, Java с серьезной обфускацией или преобразованием в exe файл) — нет в теории, разработчик может раскурочить его в дебагере, но это мягко говоря не самое простое занятие. В теории, он и вебсервис взломать может.

                                                                                                                                  2. Сделать в maven (менеджер зависимостей) отдельные зависимости для интерфейса и два проекта реализации — одна реальная с секретным кодом на стайджинг и прод., другая простая для дев.тестирования. Так как интерфейс один и нарушить его нельзя, никаких ломающих обратную совместимость изменений в модуле эмиссии JWT быть не может.

                                                                                                                                  3. Сделать локальное отдельное приложение с которым будет основное приложение общаться по RMI (метод локальных вызовов). В отличии от микросервисов второе приложение будет жить на том же сервере и передавать сериализованные данные в обычном формате Java. И нет просто взять и перенести второе приложение на другой сервер — не всегда возможно, учитывая небоходимость учитывать ассинхроность, таймауты и т.п.

                                                                                                                                  Это боль, страдания и вечно падающий релиз. Потому, что нужно еще дождаться деплоя на DEV. А потом все это понять… потом попробовать вот так… и опять ждать деплоя. Это работает только в теории

                                                                                                                                  Если версии публичных интерфейсов известны и не меняются просто так (что в Java определяется номером версии модуля), то сломаться может только внутреняя реализация независимого сервиса, но эта реализация может сломаться и у микросервиса.

                                                                                                                                  Странная логика, то есть для микросервисов:
                                                                                                                                  В DEV контуре ты имеешь DEV релизы с которыми интегрируешься. Их кто-то релизит, ты потребляешь. И это нормально.

                                                                                                                                  Это нормально, а для отдельных модулей-сервисов монолита, где версии нужно менять руками и где при изменнии публичного интерфейса все упадет сразу при сборке (а не на тестах или вообще будет не заметным) — не нормально.
                                                                                                                                  Хотя там действует ровно тоже правило и более того согласованность определяется компилятором — нельзя просто переименовать поле или изменить его тип без того чтобы все не упало на стадии сборки.
                                                                                                                                    +1
                                                                                                                                    Давайте ближе к реальной жизни. Проект на Symfony, кастомный модуль эмиссии JWT. Как скрыть его реализацию от всех, за исключения 5 человек.

                                                                                                                                    дать доступ к репозиторию этого модуля 5 людям, остальным не давать. Ваш кэп.
                                                                                                                                  –1
                                                                                                                                  Это точно сделает систему более защищенной.

                                                                                                                                  Это точно ухудшает безопасность системы. Программист — ленив. Если он считает, что исходники не видит маньяк, который знает, где программист живет, программист начинает слезать углы. Сначала безобидно типа if ( v == 1 ) вместо if ( v != 0 ) а потом… Сам факт существования SQL injection один большой пример почему исходники скрывать нельзя.
                                                                                                                                0
                                                                                                                                Вопрос в другом, любой разработчик в монолите имеет доступ к любой области кодовой базы. Как минимум он может получать ценную информацию о реализации алгоритмов безопасности. И использовать ее в своих целях.

                                                                                                                                А вот не обязательно. Никто не мешает сделать отдельные модули и отдельные репозитории у которых будет доступ только у членов команды. Скажем, все алгоритмы безопасности лежат в отдельной библиотеки, к которой есть доступ только на тестовом/прод.сервере, а для дев.тестирования используется заглушка (если вы боитесь декомпиляции).

                                                                                                                                Вообще монолит это только про общие сервера и общее развертывания, фронтэнд на JS и каком-нибудь Vue.js, тонкий бекэнд на PHP и толстый бекэнд на Java + бизнес логика на хранимках в SQL сервере это 4 разных команды и 4 репозитория, но все еще монолит по большому счету (по крайне мере, не микросервисы).
                                                                                                                                  0
                                                                                                                                  Никто не мешает сделать отдельные модули и отдельные репозитории у которых будет доступ только у членов команды.


                                                                                                                                  Теоретически. Практически, поддерживать работу этого монстра будет затруднительно. Те же заглушки (моки) нужно будет актуализировать, постоянно. Выявление интеграционных багов будет только после деплоя на DEV. понеслось… сидишь и пялишься в свой код, не понимая… почему у тебя это работает на на DEV падает.

                                                                                                                                  Я видел в жизни такие реализации. В конце они приходили к тому, что часть функционала жила на DEV. Т.е. были не заглушки, а проксирование на DEV. В целом как-то это даже жило. И по сути, это не что иное как выделение части кода в микросервис…

                                                                                                                                  Вообще монолит это только про общие сервера и общее развертывания


                                                                                                                                  Микросервис это выделенный функциональный блок в отдельную кодовую базу. Если мы говорим о фронте и бэке, то это не микросервисы. Это слои. Фронт, в данном случае — представление функций бэка. Если же бэк поставляет, к примеру, API которые обслуживают две или более изолированных кодовых базы, то это уже микросервисы. То, что они деплоятся вместе на одни и те же сервера, это просто административное решение. Ведь они могут жить и на разных?

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

                                                                                                                                  это речь про программирование в 90х? уже в начале двухтысячных модульную архитектуру развивали. пилишь свой модуль и к полной кодовой базе доступ не имеешь.
                                                                                                                                    +1
                                                                                                                                    Подумал тут что-то ответить, потом решил, что нафига только время терял?

                                                                                                                                    Решения для этих проблем есть, решений много, рекомендую сменить пару «скучных» и «серьезных» организаций где бизнес не крутится вокруг IT-специалистов. Будет много интересного и это снимет розовые очки.
                                                                                                                              +1
                                                                                                                              Ну если учесть, что большинство сливов баз — это смотрящие в открытую в интернет еластики/монго, то не понятно, почему тут это упоминается
                                                                                                                        +7
                                                                                                                        1.Если все просто, то это просто встроить и в монолит и микросервисом. А если вам надо впиливать чтото в самый центр, то вы натрахаетесь вся микросервисами гораздо больше по мясу выдирать функционал. Двухкоммитные транзакции, идемпотентность — кушать гуано подано!
                                                                                                                        2. УГУ DDOS атака на большинстве проектов раз в год. Проще упасть и встать. А с миркосервисами вы намучитесь.
                                                                                                                        3.Угу-угу. Если у вас монолит и вы сигнатуры методов поменяли, nо он просто не скомпилируется, а если рестный микросервис поменяли контракты, то вы узнаете об этом в момент падения.
                                                                                                                        4.Поржал, да но при условии квалифицированного дорогого персонала. А в реалиях, наоборот все наружу торчит в микросервисах, потмоу что про секьюрность думают в последнюю очередь.
                                                                                                                          +2
                                                                                                                          УГУ DDOS атака на большинстве проектов раз в год. Проще упасть и встать. А с миркосервисами вы намучитесь.
                                                                                                                          Кому как везёт. Часто просто упасть не разрешают. Бизнес требует чтобы работало. С микросервисами можно отмасштабировать нагруженную атакой часть.

                                                                                                                          Угу-угу. Если у вас монолит и вы сигнатуры методов поменяли, nо он просто не скомпилируется,
                                                                                                                          Чудеса случаются и оно вполне себе, но как-то компилируется. И потом чудеса не спешат исчезать.

                                                                                                                          А в реалиях, наоборот все наружу торчит в микросервисах, потмоу что про секьюрность думают в последнюю очередь.
                                                                                                                          Периодически проскакивают новости, что найдена торчащая в сеть база данных с дефолтными настройками безопасности. Опыт показывает, что о безопасности редко думают вообще.
                                                                                                                          +7
                                                                                                                          Возможность развивать продукт независимыми сегментами.

                                                                                                                          Это в идеале. Реально же практически каждая новая фича затрагивает сразу кучу микросервисов и требует доработки процессов, изменения многих API и координации цикла разработки. Причем как ни организуй архитектуру — все-равно всплывет задача, которая не ляжет ровно на ваш шедевр.


                                                                                                                          Адекватное масштабирование микросервисов.

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


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

                                                                                                                          Фактически то же самое, что и 1. Координирование изменений в микросервисной архитектуре на порядки сложнее, чем в монолите. Пример: если надо поменять сервис в монолите, берем IntelliJ Idea и по Alt-F7 получаем все места, где он используется. В микросервисной же архитектуре сделать impact analysis — это настоящая головная боль.


                                                                                                                          Управление контурами безопасности. Монолит имеет доступ ко всем данным. Это грандиозная дыра.

                                                                                                                          Да вот нифига подобного. Микросервисы общаются при помощи API, которые требуют постоянного контроля за доступом (и постоянно где-то выявляется дыра). Монолит же въявную экспортирует только те API, которые будут использоваться извне, и со всеми необходимыми привилегиями и контролем.


                                                                                                                          Вобщем, на мой взгляд микросервисы хороши, если у вас:


                                                                                                                          • система натурально может быть разделена на относительно независимые компоненты, сильно отличающиеся по функционалу, каждый из которых участвует во многих бизнес процессах
                                                                                                                          • компоненты поддерживаются и разрабатываются разными командами и имеют разный релизный цикл
                                                                                                                            0
                                                                                                                            (del)
                                                                                                                              +4
                                                                                                                              первый и третий пункт модульная структура вполне покрывает и микросервисы там не нужны.
                                                                                                                                +1
                                                                                                                                5. Добавление функциональности к древнему, но работающему монолиту. Часто достаточно вывести наружу какие-то события — а отчеты, уведомления и т.п. делать уже отдельными сервисами. Такой подход часто более выгоден и безопасен — по сравнению с «впиливанием» внутрь всего нового функционала с риском что-то важное поломать.
                                                                                                                                  0
                                                                                                                                  Особенно про независимые релиз циклы расскажите когда ваш сервис решил поменять выходной формат. И не просто поменять а поменять по просьбе downstream системы. Да не в случайный момент а согласованый. И на той стороне тоже, что удивительно все готово в срок. Да только в тот самый момент, когда все уже настроились пропить премию в downstream находят несвязанную с этим изменением ошибку и откатывают релиз. Или еще веселее — и у вас все хорошо и у них все хорошо и выкатили все вовремя и работает как надо. Да вот незадача — кто-то о ком вы оба ни сном не духом уже к старой версии присосался и вы его разумеется поломали. А поствить паралельно старую и новую версию… можно конечно, но это в два раза больше поддеживать. Ну или вообще невозможно потому, что у вас база 3 терабайта на SSD. Ну вы поняли идею.
                                                                                                                                  +1
                                                                                                                                  Статья из надёрганных чужих мыслей. Автор — простей