Комментарии 249
Если вы предложите просто «разбить приложения на естественные куски с минимальным числом связей» — то вам покажут 100500 незакрытых фич-реквестов и никто ничего разбивать не будет.
А вот если вы покажете решение, которой может решить сразу все мировые проблемы сразу и будуте говорить достаточно убедительно — ресурсы, может быть, и удастся получить…
Вероятно, потому что «не модно». Сам задаюсь этим вопросом пару лет.
Нормальные микросервисы — это когда не 5, не 10 сервисов, а 1000-5000 на тот же размер кода. И все это независимо мастштабируется в контейнерах для полноценной утилизации ресурсов. На такую крайность мало кто идет.
Никто в своем уме не может предложить адекватного определению микросервисов, потому что его не существует
Почему? Микросервисы обычно подразумевают автоматический оркестратор (запуск и остановку инстансов в основном без участия человека), несколько экземпляров большинства инстансов, слабую связность (потенциально все инстансы должны работать в независимых виртуальных машиных или docker контейнерах).
SOA может реализовываться как микросервисами, так и большими ручными сервисами-приложениями.
потому что микросервисы всего лишь SOA
А разве кто-то с этим спорил? Однако обратное неверно — не всякая SOA архитектура это микросервисы.
Есть же адекватное: должно хватить двух пицц, чтобы накормить команду, способную поддерживать один микросервис.
Две пиццы это на какой срок?
Какие именно пиццы? Диаметр? Вес? Калорийность?
Если это был сарказм, то я не понял)
А так… Смешивать техническое и человеческий фактор прожорливости — не самая лучшая идея.
Две пиццы 35-40см в диаметре я могу легко съесть за часов 5, хотя я не такой и большой (около 85кг).
Почему не разбивать приложения на естественные куски с минимальным числом связей… и все это внутри одного рантайма!
Миллениалы изобрели модульность.
История Netflix по применению микросервисов вдохновила многихЭто не значит, что
1) Netflix и пр. отдельные игроки однозначно выиграли со своими микросервисными решениями
2) Вы выиграете со своими микросервисными решениями
То есть жить с несмертельно неудачными решениями можно, но необязательно.
Микросервисы это отличный способ организовать работу огромной команды разработчиков (100+ человек) над одним продуктом. Если у вас гораздо меньше разработчиков, то микросервисная архитектура будет добавлять большой оверхед.
добавлять большой оверхед
Как бы это еще донести до вышестоящих, погоня за «модностью» разбивает все обычные аргументы.
надоедает, что каждые три года ИС переписывается с нуля
Поэтому выбирают микросервисы? Чтобы за три года банально не успели ничего выпустить?
Чтоб переписывать частями.
переписывать частями
А переписывание частями как-то гарантирует ускорение разработки или меньшее количество багов?
Чтобы переписывать частями нужны микросервисы?
Как по мне (и исходя из опыта), если нормальная архитектура, то и монолит можно переписывать частями без проблем
на котором потопталось 3-4 поколения программистов?!
Понятно, что «лучше быть богатым и здоровым», но обычно так не бывает.
Где вы увидели, что я писал про легаси?
Где вы увидели несколько поколений, если сами писали про 3 года?
Мой коммент был направлен именно на утверждение, что для переписывания частями не нужны микросервисы, для возможности переписывать частями нужна нормальная архитектура.
Не понимаю почему вы пишите оффтоп
Микросервисы не прямо необходимы, но способствуют тому, чтобы нормальная архитектура была. В частности, чтобы общение модулей проходило через строго определенный API, через их фасады. Усиление сокрытия на уровне модуля, а в некоторых языках чуть ли не единственный способ получить технические гарантии того, что модули общаются друг с другом строго через фасады, отдающие/принимающие только скаляры и иммутабельные DTO.
То, что вы написали никак не отменят моего высказывания.
Почему вы думаете, что использую микросервисы, вы получаете гарантии? Как только вы перестанете за этим следить, сразу всё пойдёт "естественным путем".
Потому что разные процессы у микросервиса и клиента, чаще всего на разных хостах. Сложно "естественным путём" дернуть класс, расположенный в совершенно другом процессе, передать значение по ссылке, использовать глобальные переменные — очень сильно надо будет постараться.
Видимо, вы работали только с умными людьми)
На моей практике было такое, что человек вместо написания пары строк кода пишет отдельный класс костылей
Да вот как раз микросервисы как защита от дурака, решившего, что границы модулей не для него, вполне нормально работают.
У нас есть сугубо организационная проблема ограничения совместного доступа к общему коду. Решим её организационными путями? Разобьём код на модули и сделаем git hook, который запрещает пушить в чужие модули или хотя бы оповещает владельца? Сделаем нормальное code review?
Нет, давайте лучше потратим человеко-годы и кучу железа (т.к. у нас теперь всё взамодействует по сети) на переписывание всего на микросервисы. А потом ещё столько же на поддержку получившегося поделия.
Тут по-моему очевидно, что если у вас был плохой и корявый монолит, то получатся такие же микросервисы, вопрос исключительно инженерной культуры в компании.
Ну и совершенно верно выше писали — по факту, миллениалы изобрели модульность :)
Единственный конструктивный посыл от микросервисов — это раздельное масштабирование, но возникает такая проблема только на правда большом масштабе (как минимум, сотни и тысячи физических серверов, но и тут как правило хватает SOA).
А истории «у нас CRM система на заводе, мы всё переписываем на микросервисы» — это классический пример, когда не очень толкового менеджера надурили не очень толковые программисты, которым скучно писать бизнес-логику, а амбициозных задач не предвидится — вот они их сами и придумывают за счет работодателя :)
Так что компании с низкой технической экспертизой показан монолит. Он явно дешевле в развитии и сопровождении (собственно, о таком очень часто говорится касательно SOA).
Микросервисы энфорсят низкую связанность. Конечно, можно и без сети тем же самым заниматься, но обычно у людей для этого не хватает дисциплины.
Микросервисы энфорсят низкую связанностьТолько если запрещены синхронные коммуникации между ними, иначе это просто distributed objects. Но асинхронные коммуникации могут выполняться и в одном процессе, например (что не делает такую архитектуру менее сервис-ориентированной).
Есть подешевле способы форсить связность на уровне кода, чем проблемные удалённые коммуникации.
А откуда возьмутся синхронные коммуникации по HTTP?
Есть подешевле способы форсить связность на уровне кода, чем проблемные удалённые коммуникации.
Наверное, Есть, но там по моему опыту всё скатывается в "залезть руками в БД другого сервиса".
А откуда возьмутся синхронные коммуникации по HTTP?Request-response — природа HTTP. Когда один процесс ждёт завершения другого и его ответа.
Но он тем не менее асинхронный. Вы не путаете push/pull-based концепции? Потому что технически HTTP куда как асинхронный.
Протокол синхронный. Клиент устанавливает соединение, отправляет запрос и ждёт ответа. Что некоторые платформы допускают отправить запрос, а потом заняться другими делами, пока платформа не обнаружит ответ и не дернёт колбэк, зарезолвит промис или возобновит корутину, не делает протокол синхронным.
Вся соль именно в цифрах. 100+, но почему именно столько? Почему не 10+ или 1000+. Я молу про более нежные случае, вроде 50+, 70+ или 130+, 200+. А что, если я скажу — что 99% современного веба уже лет сто в обед поклоняются микросервисной архитектуре? Четырьмя буквами: СУБД. Я уже молчу про стораж, аутентификацию, биллинг. Но у них же уважительная причина быть микросервисами?
А теперь почему микросервисы это крутота и почти (почти!) всегда их стоит использовать. Это возможность мешать пайтоны с го, это возможность декларировать (!) внутренний (!) API ещё до первой строчки кода by design. Потому что http известен, он прост и удобен.
Ко всему прочему микросервисы не означают REST, хотя программировать и забыть про состояние — это красота. Каждый раз, когда необходимо помнить про сотни строк кода выше — это боль и страдание. А если при этом глобальное состояние растеклось по кодовой базе — кому-то точно не стоило начинать этот проект.
А вообще. У всего есть свои плюсы. И свои минусы. Микросервисы, конечно, очень плохо ложатся на UI. Ну, by design. И ладно, если вы огромный видеохостиг, которым есть хоть что-то разделять в UI, а если вы очередной интернет-магазин или государственная специализированная СУБД? Первый собирается как конструктор из готового, ко второму обычно заранее есть сборник сочинений в трёх томах разной степени упоротости. Хотя это не значит, что не стоит ~использовать~ ориентироваться на микросервисную архитектуру, но это так же совершенно не значит, что надо дробить функционал до 2+2 на отдельный C++ истанстанс — навроде так быстрее же? Крайности ужасны. А микросервисы прекрасны.
И да. За оверхед их корят не во времени разработке, ни разу не видел, чтобы микросервисы проигрывали в написании. Если их правильно готовить, конечно. Оверхед по ресурсам — совсем другая история, но задумываться о них, когда ресурсы — операционные расходы, а удвоить RAM это совсем не тоже самое, что двойной прайс — ну. Немного не то, чего ждёт бизнес. Но это уже совсем другая история.
С каких пор зоопарк языков и фреймворков в проекте стал плюсом?
Согласен, надо отлучить дата сайнтистов от их любимого пайтона, пусть свой скоринговый движок на си шарпе пишу, и что бы все пакеты математические с пайтона на си шарп портируют, а у айосников надо отобрать их макбуки и раздать виндабуки — пусть на ксамарине пишут у нас же си шарп везде. А мы с Вами возьмем отпуск за свой счет на пол года и перепишем эту ужасную старую админку с визуал бейсика на си шарп.
Ну, имхо, все же скоринговый движок датасайнетистов сбоку от какой-нибудь ИС — это не микросервисы, iOS приложение для этой же ИС — это тоже не микросервисы.
Микросервисы с зоопарком языков — это когда у вас аутентификация в эту ИС на шарпе, авторизация на питоне, email шлюз на perl, а sms шлюз на php.
Во-о-от, профессионалы подтягиваются :)
Было бы смешно, если бы этого не было у нас в проекте. Приправьте сверху еще gRPC вместо REST.
С таких как под одну задачу одни языки и фреймворки стали подходить лучше, а другие хуже.
А теперь почему микросервисы это крутота и почти (почти!) всегда их стоит использовать. Это возможность мешать пайтоны с гоУх ты, то есть вместо одного ЯП со стремительно устаревающими зависисмосями (фреймворки, сторонние либы, etc.), регулярно всплывающими багами и неочевидными подводными камнями, которые требуют время на изучение, мы можем получить целых два ЯП за ту же зарплату! Действительно, как это кому-то может не нравиться?
это возможность декларировать (!) внутренний (!) API ещё до первой строчки кода by designВообще-то для этого уже давно изобрели UML, но это «некруто», поэтому давайте изобретём Open API и будем его лепить даже для внутренних сервисов — будем круто.
Так-то согласен, что правильное разделение обязанностей решает и надо обязательно понимать: что за сервис вы создаёте и какие у него потребности.
Могу я попридираться к словам немного?
Конечно!
Ух ты, то есть вместо одного ЯП со стремительно устаревающими зависисмосями
Ух ты, вместо фиксирования зависимостей (фреймворки, либы, сниппеты, кор) мы можем получить перманентные out of service/maintance, deprecated и orphaned, с регулярно всплывающими новыми багами и неочевидными подводными камнями, которые требуют время на миграцию, реверсивное тестирование и dependency hell. За ту же зарплату! Как это вообще может не понравиться?
Вообще-то для этого уже давно изобрели UML, но это «некруто», поэтому давайте изобретём Open API и будем его лепить даже для внутренних сервисов — будем круто.
Вобще-то, для этого давно уже изобрели графы зависимостей, и не одним UML единым. Но это слишком круто, давайте не будет вакцинироваться от детских болезней и вообще — тру стори это когда проросло мхом? Ой, как это взаимоисключающие параграфы?
Ну, надеюсь в целом то понятен был ироничный ключ? У каждой технологии есть плюсы и минус. У микросервисов по существу намного больше плюсов. Что уж до багов — то разворачивать клубок зависимостей в монолитном аде — это то ещё удовольствие. Единственный (достаточно объективный) плюс за монолит — это значительно более высокая производительность и требовательность к ресурсам в целом, которые сегодня стоят значительно дешевле часов программистов (к сожалению, в СНГ ещё не совсем так и это сильно бьёт по общей тенденции, в т.ч. в распространении микросервисов). Основные её положения (вернее даже следствия) — это абсолютно и ни за что нельзя их душить по ресурсам, это адекватно настроенная оркестрация и достаточно продвинутый и компетентный менеджемент (да, эти товарищи свои зарплаты имеют не просто так), а вот к программистам требования уже сильно падают. По простой причине — решаемые задачи уже не так сильно отличаются от лабораторных. И, к слову, вот здесь тоже есть неприятный момент связанный с нерепрезентативной выборкой — понятное дело, что когда кадры удушенны качеством качество продукта в любом случае стремительно падает.
Могу сказать так — если захотеть, то микросервисы заработают абсолютно на любом проекте. А вот умение в декомпозицию — это уже отдельная история (или истерия, у кого как), от которой зависит успешность применения микросервисов. И да, оверхед по ресурсам в двое, а то и в трое для микросервисов это нормально. Потому что ресурсы сегодня очень дешёвые и это операционные расходы, которые легко контролировать и масштабировать.
Не знаю, у нас десяток разрабов, и с микросервисами у нас все очень хорошо работает. Минусы разве что в сетевой задержке, но тут уже как вы написали, большинству проектов пофиг, за 100мс или за 200 отрисуется страница, все равно ощущаетяс как "мгновенно".
Если ребята не смогли в монолит поиграть, тоже самое будет и с микросервисами.
И да, но не совсем. На самом деле микросервисы крайне лояльны к плохой документации, достаточно толерантны к плохим горизонтальным коммуникациям внутри команды, очень терпимы к относительной нестабильности ПО и низкой "грязной" производительности.
То, что их тяжело "чинить", скорее всего просто плохая архитектура. Если связность микросервисов такая, что они не могут работать "изолированно", то это очень, очень плохая история. Также, микросервисы практически вынуждают покрывать код тестами, причём юнит тесты практически из коробки конвертируются в функциональные, настолько всё замечательно, что юнит тесты можно даже просто игнорировать, заменив их полностью моками.
Ну и да. Как по мне, туловый дебагинг скорее признак как низкого качества кода, так и недостаточной квалификации. Сам немного страдаю от последнего, но это лишь повод развивать траблошутинг, а не жаловаться на отобранные F9-F12.
если у вас лучилась бага, которая пролетела по нескольким микросервисам, и чинить трудно, и тесты писать придется дополнительно интеграционные, возможно не тривиальныеИ не только баг. При волатильных бизнес-требованиях придётся постоянно либо переделывать boundaries между сервисами с огромными трудозатрами, либо лепить костыли и технический долг.
При волатильных бизнес-требованиях или мы делаем очередной интернет-магазин или пора бить ~серпами~ документами по ~яйцам~ по заказчикам. Некоторые вещи по аджайлу не делаются. Те, которые делаются, обычно достаточно простые для планирование. Если есть возможность заранее спланировать достаточный API для взаимодействия достаточного количества сервисов — это абсолютно не проблема. Причин для изменений boundaries должно быть больше, чем "ну, мы тут захотели красную кнопку, а не зелёную". А если продукт внезапно делает сальтуху с разворотом с переобувкой в полёте — это проблема инвесторов, учредителей и топ-менеджемента. Не ваша.
Спасибо, буду знать! /сарказм
Половина моего изначального комментария сарказм. Сказка, да в ней намёк.
Это вы так пошутили?
Да ну? Правда что ли? Честно, я не отвечал несколько дней потому что устал, простите.
Берем бубен и выполняем необходимые ритуалы.
Ну. Если логическое мышление, общее владение кодом и архиектурное понимание — для вас это бубен. Простите. Почти любую ошибку можно решить без дебаггера. Вернее — только лишь и можно, очень часто дебаггер лишь усугубляет поиск, прочёсывая совершенно ненужные места. Более того, сам подход микросервисной архиектуры сулит такое блаженство, как максимально объективное взаеимодействие. Жаль только, что люди не умирают от неправильных концептуальных решений, простите мне сие лицемерие. Избыточное API — мёртв. Сломанная аутентификация — мёртв. Поломал наследственность — мёртв. Расплодил костылей — мёртв.
Да, единственная проблема, которую решают дебаггеры — это исполняет код построчно вместо вас и (относительно) неплохо ищет очепятки. Но первое — это ваша проблема, не моя. Второе — для этого есть линтеры и статические анализаторы, постфактум очепятки исправлять слишком бесполезно.
И ни дай бог это публичный апи затронет.
Эм… Причём здесь, к чёртовой бабушке, публичиный API? Смешались, кони люди. Ага. Если публичный API работает — зачем менять внутренний? Если публичный API не работает — каким образом изменения не затронут публичный? Вот здесь я прям поломался.
Ну и скоординировать деплой будет весело.
Если вы тимлид и у вас не получается — вы плохой тимлид. Если вы менеджер и у вас не получается — пора искать другие сферы деятельности. Если вы (хоть сеньёр) программист — это не ваша проблема, при условии, конечно, что вы не саботируете разработку.
Так что для себя вывод сделал однозначный — если в команде человек 10, максимум, разрабов, то о микросервисах даже и говорить не надо.
Вообще не согласен с вами. Наоборот оверхед есть на монолите, в который вы не впихнете новую версию библиотеки или какую нибудь реактивщину, посколько другие модули за которе ответственны другие разработчики просто либо заняты либо ленивые.
Вы можете делать что угодно в рамках своего микросервиса если это не меняет публичный контракт и это действительно классно и только ускоряет разработку из моего опыта.
CI/CD будет потреблять меньше тк в случае изменения в одном сервисе не надо заново пересобирать и тестировать весь проект. По инфраструктуре вы можете поднять много инстансов сервиса который потребляет много ресурсов, а другие пусть живут на двух инстансах с небольшим кол-ом ресурсов. В то время как на монолите вы будете плодить инстансы для всего сервиса целиком.
в который вы не впихнете новую версию библиотеки или какую нибудь реактивщину
а зачем?
а затем :)
Пара кейсов:
Была использована среденей популярности система каких-нибудь учётов рабочего взаимодействия, которая нашла в себе какие-нибудь 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, но это абсолютно не значит, что эти решения окажутся дешевле, чем якобы некоторый оверхед на микросервисы.
Ну, вернее можно, конечно, разнести их в разные сабмодули, бинарно несовместимы, но получим те же микросервисы, только в профиль
Ну, не совсем.
Не будет затрат на разработку (и отладку) асинхронности, конвертацию в json (или другой формат) и обратно, вызовов http, обработку http ошибок и таймуатов, правильную авторизацию и безопасность внутренних вебсервисов, задержек на сетевое взаимодействие, совместимость интерфейсов будет гарантироваться на уровне компиляции, развертывание будет одним приложением.
Из минусов — несколько более низкая надежность из-за общего рантайма (что правда слегка уменьшит за счет нескольких инстансов монолита и резервных инстансов со старыми версиями), плюс невозможность гибкой маштабируемости отдельных компонентов (но сохраняется маштабируемость на уровне целого монолита и баз данных).
В целом, могут быть ситуации когда плюсы микросервисов перевесят минусы, но далеко не всегда.
Не будет затрат на разработку (и отладку) асинхронности
Простите, а какие там затраты окромя заранее правильного подхода? К тому же, если в микросервисах нужна реальная асинхронность (на долгие таски) — почему в монолите можно обойтись без неё? Даже более того, разве в монолите подход не более сложный, связанный с тасками/тредами, семафорами/мьютексами и общими ресурсами? В общем, выстрелить себе в ногу — простейшая задача.
конвертацию в 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. Да и потом, с чего бы это проблема? Если при разворачивании у нас отвалился модуль авторизации, например, (правильно спроектированный) микросервес может работать без этого функционала (из коробки), а вот монолиту придётся дополнительно продумывать данную возможность.
Единственное, на чём оверхед есть — это ресурсы. Их тратится ощутимо больше. И да, в том числе сетевой трафик значительно забивается, но на лупбеке хоста его хоть жопой жуй, а внешнего даже в кластерах, его не так много.
Другую парадигму — да, очень тяжело. Но проблема в том, что и другую парадигму и на микросервисах впихнуть не так просто, как кажется. Есть много не самых очевидных проблем, которые так или иначе всплывут:
- Обучение разработчиков
- Грань между свободой выбора технологии и хаосом очень тонка и будет потрачено крайне много времени на ее очерчивание
- Асинхронный код, если же мы заговорили о нем, часто требует и других настроек auto scaling'а
- Выплывает куча разных болячек, если использовать не проверенный временем стек технологий
Казалось бы, не так и страшно, но в реальном проекте, при минимальном наличии бюрократии/замороченных архитекторах, будет плохо. Большинству бизнесов надо фичи деливерить, а не хотелки разрабов удовлетворять.
CI/CD — это не только Jenkins (или альтернативу) поставить. Это и подходы к тестированию, и правильная реализация этих тестов. К примеру, в случае микросервисов без контрактного тестирования проблемы интеграции будут всплывать постоянно. End-to-end тестов необходимо будет больше, а их делать сложнее.
Кроме тестов, есть еще куча других процедур и проверок: всякие проверки на обратную совместимость API, создание документации, настройки zipkin/jaegor'ов, настройки сетевого стека и т.п. и т.д.
Кроме того, в нормальных ситуациях у микросервисов свои хранилища данных. Их тоже надо обслуживать, мигрировать, реплицировать и т.д. Затраты на это огромны.
Ну и последнее — про scaling. Все так часто его приводят, но почему мало кто вспоминает, что на большинстве проектов большинство сервисов зависят от неких хранилищ данных. И масштабирование зачастую упирается в эти хранилища, а не в инстансы stateless сервисов.
Переход на микросервисы предполагает обычно, что единое хранилище разбивается на несколько. Уже какое-то масштабиррвание. А микросервисы позволяют ещё и сменить хранилище на более подходящее для конкретной задачи.
Новую версию библиотеки — легко, если есть хорошее покрытие.
нет — потому что окажется, с новым подходом идет библиотека v2, у вас используется v1 и пока вы весь монолит не перенесете вы не сможете мигрировать на нее. А чтобы перенести надо чтобы все люди которые пилят свои модули взяли и нашли для этого время одновременно. И как показывает практика это очень тяжело выполнимое условие.
Но проблема в том, что и другую парадигму и на микросервисах впихнуть не так просто, как кажется.
Это просто было бы желание. В чем есть наглядный пример на текущей работе.
Большинству бизнесов надо фичи деливерить, а не хотелки разрабов удовлетворять.
Вы передергиваете. Почему вы например считаете что переход например с мемкеша на редис который уменьшил в несколько раз время ответа это хотелки девелоперов?
Или изменения архитектуры и уход с стандартной thread per action на реактивный стек позволил уменьшить потребляемую память с 5Гб до 1Гб тем самым экономя деньги на каждом инстансе плюс всплески трафика обрабатываются без проблем это тоже хотелки девелоперов?
Их тоже надо обслуживать, мигрировать, реплицировать и т.д. Затраты на это огромны.
Я не знаю откуда вы набрались таких сказок, я лично делал миграцию без даунтайма с монги в постгрес, с динамодб в постгрес. А в монолите вы фиг это сделаете легко для кого то одного модуля посколько окажется что Хибернейт решение автоматически сохраняет связи, все завязано на одну большую транзакции и тд.
И масштабирование зачастую упирается в эти хранилища
ну так и будете маштабировать высоко нагруженную Базу на отдельный большой инстанс а остальные будут себе спокойно жить в общем сервере на разным schemas.
а если что то легко выносится схема на свой инстанс и никто не замечает разницы.
Простите, а каким образом при переходе к nio потребление памяти в 5 раз сократилось? Можно конкретику — на каких именно объектах?
В остальном же, да, у монолитов есть свои минусы. Но это также не означает, что микросервисы автоматом решают все проблемы и что с ними будет сильно лучше. Серебрянной пули нет.
В общем-то, я за МАКРОсервисы/soa или как там оно называется. Пихать все в один процесс, действительно, очень часто неразумно. Но большинству проектов очень долгое время будет прекрасно на модульном монолите житься.
нет — потому что окажется, с новым подходом идет библиотека v2, у вас используется v1 и пока вы весь монолит не перенесете вы не сможете мигрировать на нее
Если эта библиотека используется только внутри модулей, а не между ними — можно и сразу две версии использовать.
А почему бы и нет если покажете почему его надо делать на хаскеле, а так же заинтегрируетесь в существующую архитектуру — например логи, авторизации и тд.
И вы понимаете, что ваш вопрос простая провокация, тк одно то, что пойди найди людей на Хаскель уже заводит компанию в тупик.
Публичный контракт может включать и требование типа "мэйнстрим ЯП" :)
Вполне нормальный организационный контракт.
Это не только API. Поведение тоже контракт, не просто сигнатуры методов или ендпоинтов, но и их семантика. Инфраструктурные соглашения типа "логи пишем в stderr/stdout", "несекретные данные конфигурации передаём через env, секретные через vault" — контракт с девопсами, например. Пишем микросервисы только на A, B и C версии -1 от последней минорной на момент старта — контракт со всем отделом разработки.
Есть компании, которые не просто не против зоопарка, а даж поощряют его, если хоть какие-то плюсы компании даёт. Может даже не технические, а чисто мотивационные для разработчиков: попробовать запустить в продакшене что-то на платформе, которая нравится/хочется. Даже если уйдёт разработчик, выбравший экзотику (по крайней мере в рамках компании), то микросервис можно просто выкинуть и написать новый в рамках того же контракта, когда понадобится его развить. А пока работает — прсто не трогают.
Вы же только что говорили, что я могу делать что угодно, пока публичный контракт сохраняется.
Да, только когда у вас инфраструктура на джава и пхп то запилить сервис на хаскеле выйдет времени ого-го как больше. Посколько в джаве у вас уже есть готовое ядро которое и логирует куда надо и авторизация прикручена. А в хаскеле это все придется реализовывать. Соответственно вам надо будет убедить остальных членов команды и бизнес, что вместо Х времени и понятный язык остальным членам команды, вам надо будет 5Х времени и хаскель на который потом никого не найти. И если вы это сделаете, то конечно пишите на хаскеле.
Что принципиально меняет пятый?
Потратили уже условно 4*N денег на одно и тоже, а тут вы предлагаете потратить ещё N, не объясняя зачем :)
(почти чистый плюсокодинг) людей с хаскелем в резюме я видел куда чаще, чем людей с Go в резюме.
Бытует мнение, что с Go или Rust на плюсы не переходят, не видят смысла :)
Что принципиально меняет пятый?
ничего — как сказал выше — вам всего лишь надо убедить, что хаскель того стоит.
а что за авторизация в микросервисах, кстати?
что запрос действительно пришел от указанного микросервиса, а не кто то подделал запрос. Что у него есть права на доступ к этому ендпоинту.
Когда-то кодовая база начиналась заведомо с одного языка. Значит, вы и тогда потратили время на логирование и авторизацию.
Совершенно верно, а теперь вам надо продать идею с хаскелем :)))
А зачем? Я не шарю в микросервисах, но зачем это делать, если вся сеть подконтрольна вам? Вы же не выставляете все эти микросервисы голым задом в интернет?
Но проблемы то могут прийти не только от тех кто снаружи :)
Плюс есть еще заморочки связанyые с SOX control
Ну это просто, ведь всем известно, какие люди на нём производительные, и как там все безопасно и безотказно!
Мне кажется на текущем этапе самые производительные люди это на пхп, ЖС, Джава, С# если мы говорим за что то обыкновенные сервисы, где надо писать бизнес логику и куда то ходить за данными. А с хаскелем вы к примеру к AWS сервисам будете ходить через имплементацию сторонних людей, а не Амазона. И никто не знает, где вы уткнетесь что такой то метод не реализован или к сервису вообще sdk нет. Вот мне нравится Раст, я начал пет проект писать на нем под AWS и внутренн.ю кухню, в результате набил шишок плюнул и взял официальные TypeScript SDKs.
Микросервисы проще перписать/обновить на новый стек/новую архитектуру. С монолитами иногда это бывает физически невозможно(цена равна цене всех вложенных челвоеко-лет в этот проект)
Но если у вас один разработчик делает микросервсиы которые связаны между собой то да, оверхед может быть и больший.
CI/CD — зависит от проекта, я видел ситуации где он упрощался, так и те где он значительно усложнялся.
Распределенная система часто гораздо проще в тестирвоании, сильно зависит от их связанности сервисов т.к. каждая комнада тестирует только свой микросервис. Часто при любом изменении в монолите требуется полная регрессия, которая занимает дни, а с микросервисам достоаточно легко тестируется только один небольшой кусок и покрывается 100% кейсов.
По-моему как и везде-главное разумно делить сервисы и понимать где нужен монолит, а где лучше подойдут микросервисы. А плюсы/минусы есть у обоих подходов и в любом из них можно наломать дров.
Что мешает тестировать монолит теми же подходами, что и микросервисы, — для меня загадка. Если это не жуткое легаси, то я от монолита ровно также ожидаю модульного подхода с нормальной пирамидой тестирования.
Что. Где. Как? Если микросервис нельзя расписать на пальцах даже дошкольнику — то это НЕ микросервис. Вот буквально — доходит до того, что на пайтоне едва ли не однострочником поднимается веб-сервер, единственная задача которого в редис (или постгри) записывать единственное число — инкрементальный номер билда. И это ну настолько простая задача, что на неё даже покрытие тестами становится ненужными.
Суть микросервисов, если что, не в децентрализации, это лишь выгодный бонус, но не более. Самый смак — в тотальной декомпозиции. И для каждой задачи можно выбрать свой идеальный инструмент. С этим ведь тяжело поспорить? Какая-нибудь бизнеслогика на Java, стат. анализ на Python, прикрученные графики вообще на бинарях dotviz (спасибо ахуенному линуксоиду, который умеет это дерьмо варить =) — и всё это не просто крутится, оно ахуенно работает.
Потому что если нет, то объяснять надо не только сам микросервис, а еще кучу всего, начиная с предметной области. И чтобы понять как работают некие комплексные бизнес сценарии в микросервисах в какой-нибудь банковской сфере, надо упороться. С монолитом тоже надо будет упарываться, но там IDE еще сильно поможет.
А если же ответ — «да», то я вас огорчу — таких проектов очень мало.
Я прекрасно знаю о тотальной декомпозиции. Был такой опыт и неоднократно. И опыт это был крайне негативный. Начиная от постоянных срачей какие технологии и как использовать, чтобы «свобода выбора технологий» не превратилась в «неподдерживаемый хаос» и кончая тем, что такие вещи, как «независимая разработка» и «независимые релизы» становились просто невозможными. Я уж молчу, что набирать разрабов под разные стеки технологий (Java, Python, бинари и т.п.) — тот еще геморрой.
Еще раз: можно ли построить хорошую микросервисную архитектуру, чтобы проект от этого выиграл? Да, конечно. Подходят ли микросервисы большинству проектов — нет.
Как вариант, это еще возможность довольно просто привлекать аутсорс. Или распределять работу между разработчиками разного уровня.
Осталось дождаться когда доцкер и прочие кубер-монстры на помойку отправят.
Bare metal + java EE форева )
На прошлой работе был сравнительно небольшой сервис на java EE микросервисах. Я, правда, тогда был не разработчиком, а сис. админом. Программные коды почти не читал, но по логам баги с программерами отлавливал.
В общем мне понравилась микросервисная аритектура. Думаю, что её можно успешно внедрять даже на небольших программных продуктах.
Слабым местом считаю, что если создавать распределенные и отказоустойчивые микросервисы в вакууме, то сервера начнут работать на 80℅ на обслуженивание инфраструктуры в которой крутится приложение и на 20% на само приложение.
Когда у нас это все крутилось в датацентре и там было запущено 20 виртуальных машин, каждая из которых крутила полноценный линукс и микросервис на 500кб, было терпимо. А потом переехали в AWS, и оказалось, что чтобы запустить средний сервис надо платить за 20 виртуалок.
"Отказоустйчивость" ушла на второй план, оказалась, что одна виртуалка может вместить в 2-3 раза больше сервисов.
И все же в современных реалиях микросервисы рулят, позволяя использовать serverless архитектуру и гибко масштабируясь в условиях облаков. Хотя и требуют больше навыков в разработке.
оказалось, что чтобы запустить средний сервис надо платить за 20 виртуалок.
«Отказоустйчивость» ушла на второй план, оказалась, что одна виртуалка может вместить в 2-3 раза больше сервисов.
Docker?
Логичное и ожидаемое замечание, но так как это была java EE, то проще было засунуть два томката с разных серверов в один, без добавления ненужных уровней сложности.
Кстати из докера я, наоборот, вынул пару сервисов на glassfish и положил прямо в папку рядом с tomcat.
Мало того, что сэкономил на ресурсах, так еще и обслуживать меньше пришлось, потому что под докером все постоянно падает.
И вообще я не понимаю как микросервисная java ee может работать адекватно в докере.
Сервер приложений (glassfish, tomcat, jboss etc) занимает 99% вычислительных ресурсов, если на нем крутится единственный распределенный микросервис.
как микросервисная java ee может работать адекватно в докере
Ну микросервис не обязательно должен быть именно микро. Если есть огромное приложение на сотни тысяч строк кода и множество сложной логики, его можно разбить на пяток «макросервисов», при этом каждый будет достаточно тяжелым, чтобы расходы на сервис приложений были в рамках погрешности.
А вообще, проще, конечно, перевести чистое java ee на spring/spring boot при переходе в микросервисы, это получиться почти тот же EE но намного более легковесный.
Если просто использовать WebSphere Liberty Profile или Wildfly — все будет очень даже легковесным. Вполне сопоставимо с разворачиванием spring контейнера.
И вообще я не понимаю как микросервисная java ee может работать адекватно в докере.
А зачем сервер приложений запихивать в докер, если есть Spring?
Чем сервера приложений лучше докера? В докере запускается просто java app.jar
Чем сервера приложений лучше докера? В докере запускается просто java app.jar
Эээ, ну наверное тем что в них можно хоть как-то контролировать внутренние процессы, без гемороя деплоить артефакты (или как там называются *.war архивы), настраивать connection pools. Все это можно делать через web интерфейс, можно готовый xml файл настроек закинуть.
Ну и самое главное, не надо менять всю логику, архитектуру, способ отслеживания падения сервисов, городить костыли для докера, которые в сервере приложений есть из коробки.
Если в одном предложении, то лучше тем же, чем apache лучше запущенного чере $ php -S девелоперского standalone php сервера
Все эти вторичные изменения не являются транзакционными — поэтому архитектура event-ориентированных микросервисов для нас работает неплохо. Если бы нужна была consistency — мы бы делали все иначе.
Пишите на чистом C. Без ошибок. И тратьте кучу денег.
Не буду растекаться мыслью, опишу неоспоримые плюсы микросервисной архитектуры, которые компенсируют стоимость владения ей:
- Возможность развивать продукт независимыми сегментами. Т.е. сегодня вы захотели впилить новый сегмент, который потенциально может дать вам прибыль. Вы берете отдельную команду, ставите задачу и она уходит в запил со своим стеком технологий (в разумных пределах). Он максимально адаптирован для нужд субпродукта. На выходе вы получаете результат, который интегрируете в уже существующую АС. Если не выстрелило — сервис выпиливаться без лишних страдений.
- Адекватное масштабирование микросервисов. Пример — микросервис авторизации, который эмитирует JWT, допустим. Вероятность атаки на него крайне высока. В момент DDoS мы можем масштабировать только этот микросервис, что позволит справиться с атакой. При этом не нужно будет разворачивать кучу нод полноценной АС, как в случае с монолитом.
- Независимая релизность. Зачастую, чтобы выкатить релиз монолита нужно провести грандиозный регресс. Релиз раз от раза откладывается из-за обнаруженных багов в различных областях монолита. Это неадекватно задерживает выпуск нужных фич из-за багов в каких-то мелочах. Не будем забывать, что разработка не прекращается. И разрыв между версиями с каждым часом прирастает. Микросервисы позволяют выпуск дробить. И выкатывать сегменты системы независимо.
- Управление контурами безопасности. Монолит имеет доступ ко всем данным. Это грандиозная дыра. Контролировать контуры безопасности с микросервисной архитектурой гораздо проще и надежнее. Тот же сервис авторизации может находиться в отдельной подсети к которой доступ будет иметь ограниченный круг лиц. Я имею ввиду прямой и косвенный (через кодовую базу монолита).
По сути, эти 4 пункта дают те основные профиты, ради которых и внедряются микросервисы. Есть еще масса профитов но они уже мельче.
Что же касается распеределнных транзакций, то это заведение «рака за камень». Никакая вменяемая АС не будет работать без кластеризации. В том числе и монолитная. И любой инсерт в БД будет приводить к тому, что по тем же проводам будут разливаться те же транзакции. Консистентность может быть потеряна в монолите запросто. Достаточно, чтобы одна нода оказалась изолирована.
микросервисов
Монолит
А почему только две крайности рассматриваются? Почему просто «сервисы», которые совсем не «микро» не имеют право на жизнь. Или в Вашей терминологии, все что не «монолит» — то микросервис?
Вот раньше было — отдельно сервис авторизации, отдельно какой-нибудь UI на MVC, отдельно службы по каждому продукту, отдельно сервер отчетов — и вроде работало/работает.
А то иногда посмотришь на некоторых проектах — каждая отдельная таблица в общей базе должна обслуживаться отдельным microservice и быть мигрированна на другую базу (состоящую из одной таблицы).
осмысленным и необходимым
Вот я и о том же, может к микросервисной архитектуре нужно приходить постепенно по мере развития продукта, а не сразу клепать все направо и налево?
Идеальным случаем я вижу — следующее: пишем модульно код, который в рамках одного процесса работает изолированно, а потом, просто разносим сложившиеся модули по разным процессам, изменяя транспорт взаимодействия — Http, очереди и т.д.
Я думаю, что тут вопрос не в постепенном развитии продукта. А в осмыслении целей продукта и выборе архитектуры для него. Если масштаб продукта не подразумевает высоких требований безопасности, своевременности релизов и всех тех профитов который описаны выше — микросервисы будут излишними.
Зато я видел пять проектов, которые закрылись потому что там два десятка программистов с невменяемыми зарплатами, делали проект безопасным, расширяемым, микросервисным и т.д.
- Вы укажите, где я говорил о закрытии бизнеса из-за технических ограничений
- Вы будете контраргументировать, а не выражать субъективное мнение. Я могу напридумывать кучу спасительных случаев микросервисов и страшных историй с монолитами. Но, как видите, придерживаюсь аргументов.
бизнесу нужно развиваться не упираясь в технические ограничения заложенные командой которая знала только PHP, допустим?
И? Упрутся в технические ограничения, тогда воспользуются другим инструментом и вынесут его в другой сервис. Вопрос в том, что этот момент может наступить завтра или через год, а может и вовсе не наступить.
Постепенно приходить к тому, что релизы должны быть своевременными?
Я больше встречал примеров, когда релизы микросервисов очень задерживались и мешали другим. Я понимаю, что вы скажите — о неумении готовить микросервисы.
Что сливы баз это плохо?
Это больше безопасность и совершенно другой разговор. На некоторых СУБД, можно одну базу разбить логически на несколько (путем тех же схем) и работать независимо с разными уровнями привилегий.
Сравниваются архитектурные модели. Загубить реализацию можно везде. А уж сколько монолитов загнулось из-за корявого использования ООП…
Это больше безопасность и совершенно другой разговор. На некоторых СУБД, можно одну базу разбить логически на несколько (путем тех же схем) и работать независимо с разными уровнями привилегий.
И как это устраняет возможность разработчика через кодовую базу получить доступ к данным этой схемы? Или к переменным окружения с паролями?
Или к переменным окружения с паролями?
Например на запрет простым разработчикам доступа в Production сервер с базами данных реальных пользователей или к виртулкам, где эти переменные находятся?
Если у меня есть доступ к Production системе я и с микросервисами умыкну данные. Просто буду делать это несколько дольше.
Вопрос в другом, любой разработчик в монолите имеет доступ к любой области кодовой базы. Как минимум он может получать ценную информацию о реализации алгоритмов безопасности. И использовать ее в своих целях.
Любой разработчки в монолите может влиять на любой сегмент кодовой базы. Да, можно говорить о том, что для исключения этого есть код-ревью. Но код-ревью, это человеческий фактор. Пропустить неявный бэкдор можно. А отсюда, вся система под угрозой.
Далее, алгоритмический ошибки, способные влиять на безопасность системы. Например кто-то писал бизнес-логику, хотел чтобы все работало очень быстро и поэтому зафигачил все на RAW SQL. Но забыл экранирование… и вот, уже в монолите дыра по доступу почти ко всему.
При микросервисной архитектуры, выделение, например, сервиса авторизации, автоматически блокирует доступ разработчика этого сервиса к бизнес-логике. Как и в обратную сторону.
А если и то и то пилят одни и те же разработчики? А вот тут нужно говорить еще об одной штуке, которую девелоперы как бы не учитывают и не обсуждают. Но она ключевая — микросервисная архитектура отражается не только в реализации кода, а еще и в административной схеме компании. Микросервисы это не столько для девелоперов, сколько для бизнеса.
Как минимум он может получать ценную информацию о реализации алгоритмов безопасности.
Security through obscurity. В идеале, знание как работает тот или иной метод, не должно уменьшать безопасность системы в целом.
RAW SQL. Но забыл экранирование… и вот, уже в монолите дыра по доступу почти ко всему.
Я же говорил про схемы — к ним отдельные connection strings и каждая часть макросервиса или монолита имеет доступ только к определенной части в единой базе данных.
автоматически блокирует доступ разработчика этого сервиса к бизнес-логике.
С этим согласен, добавить dependency в монолите гораздо проще, чем вызвать другой отдельный сервис.
Микросервисы это не столько для девелоперов, сколько для бизнеса
Значит мы с вами с разными бизнесами встречались. Как по мне (и я считаю это идельным случаем), когда каждый член команды может независимо пилить фичи, которые могут затронуть разное количество микросервисов, поэтому должен обладать большой компетенцией.
когда каждый член команды может независимо пилить фичи, которые могут затронуть разное количество микросервисов
Я бы сказал, что это антипаттерн микросервисной архитектуры.
Я же говорил про схемы — к ним отдельные connection strings и каждая часть макросервиса или монолита имеет доступ только к определенной части в единой базе данных.
Ну я повторяюсь, доступ ко всем connection strings у монолита есть. Великого смысла делить БД на схемы для безопасности в случае с монолитом — нет.
Security through obscurity.
Все верно. Основная идея заключается в том, чтобы скрыть внутреннее устройство системы или реализацию для обеспечения безопасности. Это точно сделает систему более защищенной. Нежели сферический конь в вакууме, коим можно представить идеальную систему.
антипаттерн микросервисной архитектуры.
Впервые встречаю такое мнение, и как это может быть антипаттерном, когда очень удобно и выгодно бизнесу. Да и разработчику позволяет расширить кругозор и мыслить бизнес задачами, а не узким миром своей кодовой базы.
Разработчику расширить кругозор? А затем ему нужно зп поднять, потому, что он теперь знает (он так думает) go, C++, 1C и немного Java? Потому, что на Java получают 350К? Это выгодно бизнесу? напомню, за одинаково плохо сделанную работу во всем стеке.
У вас все сервисы на одном стеке, поэтому разработчиков можно перекидывать и они развиваются? Выход… только тогда нужно обнулять профит №4. Выгодно это бизнесу? Не думаю.
А то, что теперь во всем зоопарке микросервисов нужно ждать одного разработчика, который блочит выпуск 2, 3 или 26 сервисов? Потому, что то там попилил, его перекинули в другое место, то там… а потом релиз а у него не там не там… это выгодно бизнесу?
Ну я повторяюсь, доступ ко всем connection strings у монолита есть. Великого смысла делить БД на схемы для безопасности в случае с монолитом — нет
Почему? У монолита может быть пять разных модулей и пять разных команд.
Основная идея заключается в том, чтобы скрыть внутреннее устройство системы или реализацию для обеспечения безопасности. Это точно сделает систему более защищенной
Кто мешает скрывать это в монолите? Делайте столько же репозиторией и команд, сколько в микросервисах, собирайте все для интеграционного тестирования только на серверах где у рядового разработчика не будет доступа, но api используйте обычный для данного языка, а не http c rest'ом.
Вы ровно так же не сможете запустить все микросервисы у себя на локальном компе.
Вы ровно так же не сможете запустить все микросервисы у себя на локальном компе.
Так это и не нужно. В общем-то на то оно и делалось. В DEV контуре ты имеешь DEV релизы с которыми интегрируешься. Их кто-то релизит, ты потребляешь. И это нормально.
Кто мешает скрывать это в монолите?
Давайте ближе к реальной жизни. Проект на Symfony, кастомный модуль эмиссии JWT. Как скрыть его реализацию от всех, за исключения 5 человек.
собирайте все для интеграционного тестирования только на серверах где у рядового разработчика не будет доступа
Ранее уже написал. Это боль, страдания и вечно падающий релиз. Потому, что нужно еще дождаться деплоя на DEV. А потом все это понять… потом попробовать вот так… и опять ждать деплоя. Это работает только в теории.
Давайте ближе к реальной жизни. Проект на Symfony, кастомный модуль эмиссии JWT. Как скрыть его реализацию от всех, за исключения 5 человек.
Я очень далек от Symfony и PHP, так что несмогу вам сказать за Symfony.
Но ближе к реальной жизни в Java есть несколько вариантов:
1. Оформить в виде подключаемого модуля (например, на C++, Java с серьезной обфускацией или преобразованием в exe файл) — нет в теории, разработчик может раскурочить его в дебагере, но это мягко говоря не самое простое занятие. В теории, он и вебсервис взломать может.
2. Сделать в maven (менеджер зависимостей) отдельные зависимости для интерфейса и два проекта реализации — одна реальная с секретным кодом на стайджинг и прод., другая простая для дев.тестирования. Так как интерфейс один и нарушить его нельзя, никаких ломающих обратную совместимость изменений в модуле эмиссии JWT быть не может.
3. Сделать локальное отдельное приложение с которым будет основное приложение общаться по RMI (метод локальных вызовов). В отличии от микросервисов второе приложение будет жить на том же сервере и передавать сериализованные данные в обычном формате Java. И нет просто взять и перенести второе приложение на другой сервер — не всегда возможно, учитывая небоходимость учитывать ассинхроность, таймауты и т.п.
Это боль, страдания и вечно падающий релиз. Потому, что нужно еще дождаться деплоя на DEV. А потом все это понять… потом попробовать вот так… и опять ждать деплоя. Это работает только в теории
Если версии публичных интерфейсов известны и не меняются просто так (что в Java определяется номером версии модуля), то сломаться может только внутреняя реализация независимого сервиса, но эта реализация может сломаться и у микросервиса.
Странная логика, то есть для микросервисов:
В DEV контуре ты имеешь DEV релизы с которыми интегрируешься. Их кто-то релизит, ты потребляешь. И это нормально.
Это нормально, а для отдельных модулей-сервисов монолита, где версии нужно менять руками и где при изменнии публичного интерфейса все упадет сразу при сборке (а не на тестах или вообще будет не заметным) — не нормально.
Хотя там действует ровно тоже правило и более того согласованность определяется компилятором — нельзя просто переименовать поле или изменить его тип без того чтобы все не упало на стадии сборки.
Давайте ближе к реальной жизни. Проект на Symfony, кастомный модуль эмиссии JWT. Как скрыть его реализацию от всех, за исключения 5 человек.
дать доступ к репозиторию этого модуля 5 людям, остальным не давать. Ваш кэп.
Это точно сделает систему более защищенной.
Это точно ухудшает безопасность системы. Программист — ленив. Если он считает, что исходники не видит маньяк, который знает, где программист живет, программист начинает слезать углы. Сначала безобидно типа if ( v == 1 ) вместо if ( v != 0 ) а потом… Сам факт существования SQL injection один большой пример почему исходники скрывать нельзя.
Вопрос в другом, любой разработчик в монолите имеет доступ к любой области кодовой базы. Как минимум он может получать ценную информацию о реализации алгоритмов безопасности. И использовать ее в своих целях.
А вот не обязательно. Никто не мешает сделать отдельные модули и отдельные репозитории у которых будет доступ только у членов команды. Скажем, все алгоритмы безопасности лежат в отдельной библиотеки, к которой есть доступ только на тестовом/прод.сервере, а для дев.тестирования используется заглушка (если вы боитесь декомпиляции).
Вообще монолит это только про общие сервера и общее развертывания, фронтэнд на JS и каком-нибудь Vue.js, тонкий бекэнд на PHP и толстый бекэнд на Java + бизнес логика на хранимках в SQL сервере это 4 разных команды и 4 репозитория, но все еще монолит по большому счету (по крайне мере, не микросервисы).
Никто не мешает сделать отдельные модули и отдельные репозитории у которых будет доступ только у членов команды.
Теоретически. Практически, поддерживать работу этого монстра будет затруднительно. Те же заглушки (моки) нужно будет актуализировать, постоянно. Выявление интеграционных багов будет только после деплоя на DEV. понеслось… сидишь и пялишься в свой код, не понимая… почему у тебя это работает на на DEV падает.
Я видел в жизни такие реализации. В конце они приходили к тому, что часть функционала жила на DEV. Т.е. были не заглушки, а проксирование на DEV. В целом как-то это даже жило. И по сути, это не что иное как выделение части кода в микросервис…
Вообще монолит это только про общие сервера и общее развертывания
Микросервис это выделенный функциональный блок в отдельную кодовую базу. Если мы говорим о фронте и бэке, то это не микросервисы. Это слои. Фронт, в данном случае — представление функций бэка. Если же бэк поставляет, к примеру, API которые обслуживают две или более изолированных кодовых базы, то это уже микросервисы. То, что они деплоятся вместе на одни и те же сервера, это просто административное решение. Ведь они могут жить и на разных?
Вопрос в другом, любой разработчик в монолите имеет доступ к любой области кодовой базы. Как минимум он может получать ценную информацию о реализации алгоритмов безопасности. И использовать ее в своих целях.
это речь про программирование в 90х? уже в начале двухтысячных модульную архитектуру развивали. пилишь свой модуль и к полной кодовой базе доступ не имеешь.
Решения для этих проблем есть, решений много, рекомендую сменить пару «скучных» и «серьезных» организаций где бизнес не крутится вокруг IT-специалистов. Будет много интересного и это снимет розовые очки.
2. УГУ DDOS атака на большинстве проектов раз в год. Проще упасть и встать. А с миркосервисами вы намучитесь.
3.Угу-угу. Если у вас монолит и вы сигнатуры методов поменяли, nо он просто не скомпилируется, а если рестный микросервис поменяли контракты, то вы узнаете об этом в момент падения.
4.Поржал, да но при условии квалифицированного дорогого персонала. А в реалиях, наоборот все наружу торчит в микросервисах, потмоу что про секьюрность думают в последнюю очередь.
УГУ DDOS атака на большинстве проектов раз в год. Проще упасть и встать. А с миркосервисами вы намучитесь.Кому как везёт. Часто просто упасть не разрешают. Бизнес требует чтобы работало. С микросервисами можно отмасштабировать нагруженную атакой часть.
Угу-угу. Если у вас монолит и вы сигнатуры методов поменяли, nо он просто не скомпилируется,Чудеса случаются и оно вполне себе, но как-то компилируется. И потом чудеса не спешат исчезать.
А в реалиях, наоборот все наружу торчит в микросервисах, потмоу что про секьюрность думают в последнюю очередь.Периодически проскакивают новости, что найдена торчащая в сеть база данных с дефолтными настройками безопасности. Опыт показывает, что о безопасности редко думают вообще.
Возможность развивать продукт независимыми сегментами.
Это в идеале. Реально же практически каждая новая фича затрагивает сразу кучу микросервисов и требует доработки процессов, изменения многих API и координации цикла разработки. Причем как ни организуй архитектуру — все-равно всплывет задача, которая не ляжет ровно на ваш шедевр.
Адекватное масштабирование микросервисов.
Не факт. Отмасштабированный монолит на каждом узле содержит полный функционал системы. Другое дело будете ли вы его использовать весь, или же только часть...
Независимая релизность. Зачастую, чтобы выкатить релиз монолита нужно провести грандиозный регресс.
Фактически то же самое, что и 1. Координирование изменений в микросервисной архитектуре на порядки сложнее, чем в монолите. Пример: если надо поменять сервис в монолите, берем IntelliJ Idea и по Alt-F7 получаем все места, где он используется. В микросервисной же архитектуре сделать impact analysis — это настоящая головная боль.
Управление контурами безопасности. Монолит имеет доступ ко всем данным. Это грандиозная дыра.
Да вот нифига подобного. Микросервисы общаются при помощи API, которые требуют постоянного контроля за доступом (и постоянно где-то выявляется дыра). Монолит же въявную экспортирует только те API, которые будут использоваться извне, и со всеми необходимыми привилегиями и контролем.
Вобщем, на мой взгляд микросервисы хороши, если у вас:
- система натурально может быть разделена на относительно независимые компоненты, сильно отличающиеся по функционалу, каждый из которых участвует во многих бизнес процессах
- компоненты поддерживаются и разрабатываются разными командами и имеют разный релизный цикл
Вы берете отдельную команду, ставите задачу и она уходит в запил со своим стеком технологий
А когда она возвращается - уже поменяли API, разделили/слили какие-то сервисы - и все надо переделывать.
Но война «за или против» микросервисов подталкивает многих участвовать в обсуждении этого пустопорожнего текста. То есть читаемость получаем из-за спорности темы, а не из-за хоть сколько-нибудь полезной информации.
Ну и по теме сервисов и прочего — тут надо уметь. А если не уметь — да, получается боль. Но крупный бизнес не видит в этом проблемы, ведь его расходы на ИТ практически не меняются, ну а то, что какие-то сроки сдвигаются в заоблачную даль, так это для крупного бизнеса самое обычное явление. Поэтому так и будут резвиться, не умеючи и не понимая смысла.
Господа, о чем это здесь?
Применение микросервисов требует прокачать мозг? Ну так любые асинхронные, параллельные, многоядерные разработки требуют повышения квалификации персонала. А какая альтернатива? Линейное программирование в одном потоке с оператором goto? Кому этого достаточно, ну счастья вам. А мы пойдем упражнять мозг, ломать очередной раз свой майнд и строить крутые масштабируемые системы.
асинхронные, параллельные, многоядерные
Справедливости ради, они могут быть и в монолите.
А можно пример крутых масштабируемых систем, а то с опратором goto у меня как то ассоциируются системы управления атомными станциями, баллистическими ракетами и вот этот весь racket scince из 70х, а с микросервисами, очередное тв от netflix.
Альтернатива микросервисному подходу — не использовать его, и оставить сервисы довольно крупными. И причин на это может быть море.
1. Проще ничего не менять, чем что либо менять (при прочих равных)
2. Проще деплоить 1 компоненту чем 50, особенно если это какой-нибудь .NET FW на IIS
3. Проще поддерживать транзакционность в одном процессе.
4. Проще делать join'ы и любые аггрегации данных
5. Проще troubleshooting, так как не нужно собирать логи с 50 разных систем чтобы отследить проблему. Все локально, все единообразно
6. Проще сделать 1 PullRequest чем 5
>> А мы пойдем упражнять мозг, ломать очередной раз свой майнд и строить крутые масштабируемые системы.
Удачи. Через пару лет ждем статью от тех кто вас сменит про то какой там ад поддержки, и какие монструозные штуки напилены ради 20RPS.
Но одно можно сказать точно — нельзя поддерживать и управлять микросервисами без команды DevOps.
Это что ещё за команда такая?
Вдобавок пытаются повесить на нас еще и проблемы плохой архитектуры.
Мне особенно нравится, когда монолитные куски вдруг нельзя поднять в 2-15 датацентрах, потому что там есть такая-то часть, которая…
И кода все медным тазом накрывается(и всегда же ночью), то релизится такой адовый воркароунд, что потом с сервера только пылинки сдувать и «нельзя его потерять „
И девопсы все испортили
Копипаста?
И их поддерживать легче, так как можно на больше комманд распилить
И зависимостями проще управлять.
Не-не-не, это объяснило бы, почему для микросервисов график растет медленнее, чем для монолита, но не почему он падает. Почему в монолите написать сотую тысячу строк может быть вдесятеро сложнее, чем пятидесятую тысячу — понятно. Но почему в микросервисе написание десятой тысячи строк оказывается вдесятеро легче, чем написание пятой тысячи — совсем неочевидно, тут я солидарен с le1ic
Интересно, кто топит за монолит, вы так же обожаете работать с monorepo :)
Не, монорепо это кошмар. Сперва все распилим, а потом свяжем в один репозиторий и получим опять монолит.
ну да ну да :)
у нас есть N микро сервисов а чтобы собрать один надо собрать все.
Меняешь зависимость, она меняется глобально во всех сервисах и потом сиди и ковыряй все модули.
Один сервис при тестах упал — все забудь про релиз своего сервиса.
чтобы собрать один надо собрать всеНе нужно. Собираете то, что изменилось.
Меняешь зависимость, она меняется глобально во всех сервисахСмотря как подключать зависимость, если прямо из соседнего файла, то да. Можно делать релиз и без VCS, и зависеть от этого релиза, например.
Но по идее такие зависимости кода не должны быть частой нормой.
Один сервис при тестах упал — все забудь про релиз своего сервиса.Не забудь. Нужно запускать CI для того сервиса, который изменился. Для остальных можно запустить что-нибудь интеграционно-функциональное, если есть и если надо.
Недостатки у монореп есть, но не те, о которых вы пишете.
Не нужно. Собираете то, что изменилось.
а ты жил с монорепо или это чисто теоретическое? А так чтобы еще и несколько языков в этом монорепо было?
Можно делать релиз и без VCS, и зависеть от этого релиза, например.
опять таки — насколько эти слова сочетаются с практикой? Потому что иначе это уже не монорепо.
Для остальных можно запустить что-нибудь интеграционно-функциональное, если есть и если надо.
слишком много слов если есть и если надо. кто решает?
Вот статья про монорепо: https://medium.com/@mattklein123/monorepos-please-dont-e9a279be011b
опять таки — насколько эти слова сочетаются с практикой?Релизы целую эпоху делались без VCS. Связь VCS (в основном git) и версионирования — довольно недавно распространившаяся практика.
кто решает?Те же люди, кто это решает про интеграционные тесты при множестве репозиториев.
Какая разница, есть у меня опыт или нет, я же не буду это доказывать. На моих объёмах проблем нет. У крупных компаний их можно ожидать, но они тем не менее более склонны к монорепозиториям, чем мелкие.
К статье есть комментарии, оспаривающие её положения, не буду повторяться.
Релизы целую эпоху делались без VCS. Связь VCS (в основном git) и версионирования — довольно недавно распространившаяся практика.
Вот я дурак и не знал этого. И зачем то мучался на CSV еще :((
Те же люди, кто это решает про интеграционные тесты при множестве репозиториев.
если у вас люди решают что то мы запускаем тесты то нет, то запускаем только эти а теперь вот эти — то у вас проблемы. CI тем и хорош что вы тестируете все и на раннем этапе видите где что сломалось.
Какая разница, есть у меня опыт или нет, я же не буду это доказывать.
Большая — одно дело рассуждать чисто теоретически, а другое дело набить шишек и точно знать, что теория хороша но на практике получается вот так то.
т, вы так же обожаете работать с monorepo
А вот как вы решаете такую проблему без монорепы?
В корне у нас лежит docker-compose и одной командой мы поднимаем локально все сервисы с тестовыми данными, т.е. локально у разработчика поднимается окружение без необходимости деплоя в тестовый контур. Т.е. любой может поднять у себя приложение 2 командами: git pull + docker-compose up А как в случае если у нас несколько репозиториев?
git pull
bin/up.sh — обходит все репы, обновляет до нужных веток (для каждого сервиса свою можно указать) и делает docker-compose up. Пробовал ещё git submodules не понравилось
Если вам для того чтобы протестировать локально что-то в одном микросервисе надо поднять все остальный так же локально, то у вас большие проблемы и неверная архитектура.
поднять все остальный так же локально
Если вы не можете поднять локально проект в докере, значит у вас
большие проблемы и неверная архитектура.
С оговоркой, что вы пишите не яндекс с гуглом.
нет — это всегда показатель неверного подхода.
У вас просто получается размазанный монолит.
Не факт. Варианты, когда особых проблем нет, но надо поднимать локально всё или даже больше (заглушки для внешних служб):
- e2e тесты, неважно автоматизированные или ручные
- протестировать интеграцию какого-то центрального сервиса типа авторизационного, api gateway или файлового хранилища со всеми его клиентами
- демо какое-то
Зачем локально надо иметь все сервисы для пунктов 1 и 2?
Тесты у вас должны бегаться в Дженкинсе каком то и у команды тестировщиков свои инеграционные тесты должны быть.
Демо какое то надо проводить в отдельной песочнике или замороженном на время стейджинге. Иначе что то происходит с ноутбуком и демо накрылось.
И как вы собираетесь локально подымать пару сотен микросервисов и все их датасорсы локально. У вас банально не хватит памяти на компьютере.
Нет ресурсов на отдельные енвы для каждой задачи и/или очень большой цикл обратной связи получается.
Пару сотен не пробовал, но под полсотни с десятком баз без учёта редисов-раббитов нормально работают на 4(8) ядрах (плюс IDE, Хром и т. п.) и 32 Гб оперативы. Не Java сервисы :)
Как-то всё притянуто в статье. Автор прям в каждом предложении старается отбить название. Как всегда, одни на "хайпе," другие на "хэйте", но в жизни оно всё-таки где-то посередине. Когда уже будет статья: "как я сочетаю разные архитектуры для разных задач", я бы такую почитал...
Каждая архитектура имеет свои сильные и слабые стороны. Хейтить и глорить ничего не надо, а выбирать инструменты с умом. Другое дело, что 90% новых проектов в наши дни это ничто иное, как попил бабла, а там, чем больше модных слов, тем выше шанс получить финансирование.
Если же вы пилите свой проект, то выбирайте то, что выгодно вам. И в большинстве случаев хороший монолит с выделенными сервисами будет лучшим решением на первые Н лет.
Нельзя говорить "в большинстве случаев". Выбор архитектуры (или тех. стэка) должен всегда исходить из поставленной задачи, а не из статистических данных.
Проблема в том, что к тем разрабам, "кто будет" могут придти заказчики, подверженные хайпу. Которые думают, что какая-то архитектура автоматом решит все их проблемы, хотя все их аргументы, если капнуть, сводятся к тому, что все вокруг просто об этом говорят.
А потом появляются архитекторы, которые, смотря на тренды, начинают пихать какой-то подход во все проекты подряд.
Если же вы пилите свой проект, то выбирайте то, что выгодно вам
К этому же статья и подводит, разве нет?
Очень токсичную и циничную вещь скажу. Я просто старый брюзга, не обращайте внимания.
Мне кажется основной "настоящий" бенефит микросервисной архитектуры как-то стыдливо замалчивают, а зря. Суть в том, что микросервисный код — относительно короткоживущий. Месяцы, но не годы. А значит можно не заморачиваться на многие вещи.
Т.е. раз в 9-12 месяцев каждый сервис выкинули и переписали под новый стек, требования, новые регуляции, изменившийся профиль нагрузки и т.д. Не надо сложной архитектуры, не надо переживать несколько эволюций рефакторинга, не надо оптимизировать, не надо долго и нудно тестировать. CI не свалился — выкатываем на blue-green через K8s/Helm/CloudFormation, смотрим на процент 500 в New Relic, если что-то закривело — откатываем, и по-новой. Как едко выразился мой коллега — "говнокод-ориентированная архитектура".
А теперь, внимание, жахнем теорией заговора. С точки зрения цинично-прагматичного VP of development, это дает две очень полезные вещи:
- разрабатывать можно дешевыми кодерами, которые умеют в CRUD + пакетную обработку запросов. Качество кода не особо важно, ибо живет все равно недолго. Оттуда и низкая стоимость поддержки: квалификация и зарплата ниже у "поддерживающих".
- дешевые кодеры и их линейный менеджмент отлично заменяются без ущерба для процесса. Потому что научить копипастить можно и за неделю. 20% attrition rate в год? Да фиолетово. Надо увеличить команду на треть и потом сократить на половину? Не вопрос. Можем еще недорогих контракторов привезти. И матричную занятость без трекинга времени. В таком раскладе можно выжимать людей до сухой кости в промышленных масштабах. Отсюда и увеличение скорости разработки.
Конечно, Netflix и Co не про это. Но, судя по нажитому опыту, шансов в среднестатистической интернет-конторе, приехать к такому порядку вещей довольно немало. Так что я бы проталкивал микросервисы с оглядкой. У нас вот завели платформенную команду, которая отвечает за стандартизацию, делает starter-проекты, есть утилиты для генерации кода, автоматизация review, и куча всего прочего. Спасет или нет — не знаю, думаю через пару лет будет ясно.
А ещё фронтэнд и бэкенд могут использовать общие стеки в нужным частях «монолита».
И регуляции легче внедрять под нужные компоненты
Правда то же самое делали и с монолитной архитектурой.
Вспомним вывод всей разработки в Индию, и к чему это привело. :-)
www.youtube.com/watch?v=y8OnoxKotPQ
С другой стороны, иногда чуть ли не единственный способ убедить бизнес вложиться в мониторинг, агрегацию логов, автотесты, blue/green, CI/CD и т. п. — это "продать" ему хайповые микросервисы. А потом бизнес считает это удачным вложением, потому что процессы явно ускорились и стали предсказуемей. Но ему и невдомёк, что кода по факту стало писаться больше на сопоставимые задачи, просто меньше времени уходит на тестирование и деплой, что большие "релизы" теперь они только для бизнеса, а так код какой-то фичи уже пару месяцев на проде, просто галочка не стоит. И даже, что отказов в обслуживании стало больше, просто большая часть перестала быть "ничего не работает" (после фильтрации первой линией саппорта, конечно :) )
Позволю себе вставить 5 копеек:
1. Монолит — не всегда так плох и имеет кучу профитов, особенно для начала работы.
2. Микросервисы — по своему хороши, но требуют «хореографии».
На мой взгляд — просто надо понимать какой инструмент когда доставать.
На Joker 2016 был замечательный доклад от Максима Сячина «Микросервисы: первая кровь», где он продемонстрировал интересный подход:
1. Пилим монолит
2. Пробуем компоненты монолита логически побить на куски логики, заменяя вызовы методов на REST вызовы (да, в рамках монолита)
3. Из получившегося можно вычленять какие-то куски в микросервисы, какие-то оставлять в монолите и ревертить назад REST вызовы
4. Можно заглянуть чуть дальше и, проанализировав метрики микросервисов, какие-то из них вынести в FaaS при помощи KNative поверх Kubernetes
Таким образом какие-то критичные вещи, например требующие низкой latency, останутся в виде ядра системы на IaaS, какие-то вещи уедут в Kubernetes, какие-то вещи уедут в FaaS.
В итоге получится распределённая система, требующая приличного уровня «хореографии», но в то же время достаточно гибкая для решения задач.
P.S. В сообщении всё, конечно, выглядит красиво, но на практике на мой взгляд такой подход также может показать себя с неплохой стороны, дав определённое время на размышления и площадку для экспериментов.
Есть желание использовать микросервисную архитектуру в будущем продукте, надо это как-то утвердить.
Это уже прекрасно, на мой взгляд. Думаю стоило тут уже проконсультироваться с теми, кто не только в целом понимает плюсы и минусы различных архитектур, но и уже имеет практический опыт, когда какой подход хорош или плох.
Других может быть много, возможно их код мог бы наносить непоправимый психологический ущерб при прочтении, а с сервисами ты можешь радостно и легко писать с нуля свою задачу и ни о чем не беспокоится!
Для разработчика это счастье
Остановитесь!!! Вам не нужны микросервисы