Микросервисы
или
Монолит
 Публичный пост    19 июня 2020  551

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

3 аргумента и 14 плюсиков
за «Микросервисы»
10 аргументов и 89 плюсиков
за «Монолит»
за «Монолит»
Проще распиливать, чем собирать в кучу
Аватар Андрей Черных Андрей Черных

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

за «Монолит»
Вы сначала внятно придумайте как распилить
Аватар Anatoly Shipitsin Anatoly Shipitsin

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

за «Монолит»
Хуяк хуяк и в продакшен
Аватар Semen Starostin Semen Starostin

Все зависит от вашего продукта и нагрузки. Основной плюс микросервисной архитектуры — это ее масштабируемость.

Плюсы (если приготовили правильно):

  • Можете масштабировать хоть до бесконечности, вас ограничивает только железо и ширина канала
  • Доработка\создание одного микросервиса занимает не больше недели силами 1 разработчика , относительно просто покрывать тестами ибо их мало (у нас же небольшие микросервисы с небольшим количеством бизнес логики).

Минусы микросервисной архитектуры:
— Это дорого. Рили, когда у вас 30+ микросервисов вам нужно 3-5 разработчиков не ниже уровня middle что бы все это дело развивать, так же нужен грамотный архитектор что бы все это не превратилось в систему которая живет сама по себе, и при которой изменив 1 сервис только сам Аллах будет знает как она будет работать дальше. Далее вам нужна инфраструктура под это все , докеры , кубернетисы, cicd, elk и еще куча народа которое умеет все это сопровождать и настраивать так что прибаьте к тем 3-5 разрабам еще 1-3 девопса, не забывайте что все это надо где то хостить , и вот тут вам уже нужен хороший такой сервак да подороже , а лучше два (отказоустойчивость вся херня), ну и да это для прода...но у нас же еще есть среда разработки, тестовая среда, прелайв среда и интеграция.....На все это вы конечно можете положить болт , сэкономив на средах например, ну или чо пусть разрабы будут еще и девопсерами итд итп. Но как правило все это ведет не к очень хорошим последствиям в долгосрочной перспективе.
— Это сложно готовить правильно. Я знаю только один проект у нас в банке, который можно считать относительно каноничным в плане микросервисной архитектуры, начинался он как монолит и в течении 2 лет стал микросервисным. Парни за эти 2 года минимум 2 раза меняли подходы к архитектуре, словили кучу нетривиальных проблем (например проблема логирования и сериализации десиреализации когда у вас по 10млн сообщений в минуту летит в шину). Если ваш проект подразумевает какую-либо транзакционность, вы весело проведете время думая, как реализовать откат транзакции если что-то пошло не так... Только сейчас у продукта перестала гореть жопа в связи с периодическими дефектами на бою (их стало намного меньше).

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

Плюсы монолита:

  • Вы можете сделать это быстро, на начальном этапе, когда проект только стартовал, а результат нужен уже "вчера". Плюс вам нужно меньше ресурсов.
  • Проще дебажить. Просто, потому что вы запускаете одно приложение, а не ворох из 10 микросервисов засылая в шину проблемное сообщения и копаясь потом в логах в каком сервисе что пошло не так
  • Проще раскатывать\откатывать...вы даже можете обойтись без cicd (что не есть хорошо) и катить этот навозный шарик на продакшен своими силами
  • Значительно проще реализовывать разного рода стратегии отката
  • Проще мониторить

Минусы монолита:

  • Рано или поздно все это скатится в легаси говно с которым мало кто будет хотеть работать, а те кто захотят выставят такой ценник что вы задумаетесь о том что идея продавать не продукт, а “подписку" не такая уж и плохая.
  • Как правило на таких проектах в команде сильная текучка не основных разработчиков, и причин тут море, начиная от того же легаси и заканчивая тем, что старые разрабы настолько привыкли к существующему положению дел, что принципиально не будут что-либо менять (подходы, архитектуру, стек технологий). Немаловажен тот факт, что теперь мы ОЧЕНЬ сильно начинаем зависеть от "старых" разработчиков, они теперь и наставники, и имеют наибольшую компетенцию (еще бы они же сами все это писали) и еще куча всего, со временем управлять такими людьми становиться сложнее.
  • Если монолит написан говено, и проекту уже 2+ лет , смиритесь с большей долей вероятности проект будет прибывать в таком виде до своей смерти, нужны просто нереально титанические усилия что бы его отрефачить, при этом бизнесу будет пофиг, потому что функцию проект свою выполняет. Работа как правило на таких проектах состоит в постоянных фиксах багах, потом релизим небольшую новую фичу, и начинаем фиксить баги от этого релиза, повторять сей цикл до смерти продукта.

Фуф чет много уже написал.

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

  Развернуть 1 комментарий

@rozhok, можно , но в большинстве случаев в монолите вы завязываетесь на БД, вы можете добавить ноду монолита и обе ноды будут смотреть на одну бд, она и станет вашим узким горлышком. В тру микросервисной архитектуре у вас 1 микросервис со своей отдельной бд которая в идеале не хранит информации о состоянии

  Развернуть 1 комментарий

@SAXER, БД можно масштабировать master-slave разнося запросы на чтение, запись, аналитику и т.д.

  Развернуть 1 комментарий
за «Монолит»
Потому что я не умею в микросервисы
Аватар Semyon Martynchik Semyon Martynchik

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

за «Монолит»
Начинать надо с продаж и MPV, а не вот это вот
Аватар Dmitry Gurinovich Dmitry Gurinovich

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

Техническое решение должно быть максимально дешёвым. Начать можно с говна и палок: NoCode, WordPress, etc.

Если девелопите сами - тоже максимально дешёво, поэтому - монолит.

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

Микросервисы - это всегда дополнительная сложность, дополнительная latency, компромиссы в согласованности данных и прочие "прелести". Все это требует дополнительного внимания и времени, чтобы все правильно обработать.

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

Но! Монолит не отменяет необходимость планирования и проектирования с учётом будущего перехода к микросервисам.

за «Микросервисы»
Масштабирование, тестирование и стабильность
Аватар Tim Reznichenko Tim Reznichenko

Как то незаслужено заговнили микросервисы.
Ясно что при ограниченых ресурсах проще хуйнуть шаблонный сервер на ноде.

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

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

Сложней сломать, проще поддерживать. Авторизационный микросервис может годами лежать и работать.

Можно масштабировать только узкие места.

У меня только один вопрос: откуда возьмется "хорошая микросервисная архитектура" в стартапе?

  Развернуть 1 комментарий

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

Разбивать монолит почти всегда боль.

  Развернуть 1 комментарий

@TimTimLead, я разве где-то говорил о плохой квалификации разработчиков? Это же не единственное требование для получения "хорошей архитектуры".

  Развернуть 1 комментарий
за «Монолит»
Стартап — это про «что», а не про «как»
Аватар Эдуард Суров Эдуард Суров

На этапе стартапа основная проблема - понять, что именно должно быть написано; причем это понимание постоянно дрейфует, а иногда и разворачивается на 180. Конпелировать чарты в "пятисотые" на этом этапе - удел идиотов.

Мне вот интересно: кто-нибудь пробовал применять микросервисный подход при лепке пельменей?..

Я сибиряк не настоящий, но... А что понимаешь под микросервисным подходом при лепке пельменей?

  Развернуть 1 комментарий

@madhead, ну как - берем и замешиваем тесто под один пельмень, потом крутим на него фарш. Гибкость просто запредельная, но и оверхед ого-го. Вот и в микросервисах так же.

  Развернуть 1 комментарий
за «Микросервисы»
Хуяк-хуяк и в продакшн
Аватар Siarhei Krukau Siarhei Krukau

Под микросервисами понимают много разного, я про API Gateway + кучу микросервисов за ним.

Начать можно с сервиса, скажем, про регистрацию профилей в системе. Далее - первая фича, собираете на коленке и бодро в прод. И вот за срок от нескольких часов до пары дней у вас какое-то MVP. Можно запускаться. Появились пользователи, вроде им всё нравится – прикручиваете точно так же платежи. По сервису на каждый стор или эквайринг. Вторая фича. Аналитика. Третья фича. Админка. Ещё аналитика. Ещё фичи. 🔁 Перегорел джавист? Продолжим на голанге.

Сложно уследить? Да камон, вообще не консёрн тут, я считаю. Сейчас, когда есть Docker, K8S, всякие infrastructure as code и serverless хуячить такие микросервиса не сложнее, а даже легче монолитов.

Из плюсов:

  • Реально простой и быстрый путь в прод
  • Минимальный риск поломать уже работающие фичи
  • Не нужно продумывать API – просто добавляй новые сервиса

Из минусов:

  • Получается говно

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

за «Монолит»
Быстрее и дешевле
Аватар Vladimir Rozhkov Vladimir Rozhkov

Реальная история из реальной жизни как можно просрать кучу времени на разработку стартапа с улиточной скоростью и потом всё выбросить: https://www.rozhkov.me/post/startup-swamp/

Нужна больше команда
Нужен отдельный человек который будет вязать инфраструктуру. Там выше сказали что "камон все просто" так вот нифига не просто, как только выходишь за пределы хелловорлда
Локально уже не подымешь свой зоопарк, потому что твой модный макбук имеет всего 8гб памяти и не потянет кучу контейнеров
Отдельная история это микрофронтенды и новомодное SPA-говно
Дороже инфраструктура
Отказоустойчивость системы меньше, потому что вместо одного сервера у тебя их десяток и между ними сложное взаимодействие
Мониторить это всё хозяйство тоже сложнее

Представьте вы стартап

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

Уж если надо будет где-то числодробилку то поставите сбоку "аванпост" на джаве и все будет хорошо.

Короче, я за монолит, за Ruby on Rails, за рендеринг на сервере и минимум джаваскрипта на клиенте. Это проще, быстрее, надёжнее и намного приятнее в разработке.

Вот статья от DHH хорошая: The Majestic Monolith can become The Citadel

Ну, я не по опыту с хелловордом писал "камон, всё просто".

Мой кейс (и, частично, ответ на этот аргумент и на аргумент про "3-5 человек"): я в одиночку на т.н. микросервисах (AWS API Gateway + Lambda) пишу и саппорчу бекенды для 4-х относительно разных мобильных аппликов средней паршивости. 2 года, полёт нормальный. Сложновато одному, но и 5 человек для такого не нужно. Прилаги — ничего особенного, рестики туда-сюда, но и не "ноукод на интегромате": есть и бизнес-логика часто меняющаяся (под ивенты и тренды выкатываем фичи постоянно); и аналитика в нескольких внешних сервисах (сейчас в мобильных аппликах тонны аналитики); и платёжки всякие; и админка. Есть ещё один девопс, относительно недавнее приобретение компании, он всё это дело сейчас ещё и затаскивает по красоте в ямлы всякие и дескрипторы (CDK) — так теперь вообще не приходя в сознание можно разворачивать это всё. К слову, и без него всё было завёрнуто в простейшие (CloudFormation) скрипты и работало, но он делает прям вообще хорошо. Ну и вот значит мы вдвоём вполне себе вытягиваем и разработку, и деплои, и мониторинг. Просто мы угадали с инструментом под задачу. Ну как, угадали, конечно это было осознанное решение, но — удачное.

До этого работал с одним монолитом (и коммандой 6-12 коллег) под джавовский сервер приложений и могу сказать, что было гораздо сложнее жить. Хотя сложность решаемых задач была такая же или даже ниже. Да там простое обновление XML парсера занимало месяц, потому что хрен пойми где он там ещё юзается.

Локально запустить целиком что то, что то не могу. Микросервиса нынешние — потому что у меня их буквально сотня на прилагу, да и рантайм не самый developer-friendly. А монолит поднять не мог потому что не хватало памяти. Но зато сейчас я могу-таки запустить один сервисок и погонять локально (пусть и с костылями), а вот с монолитом такое не прокатывало.

Не совсем HFT, но однажды довелось поработать с RTB, тоже требовательная к отклику вещь, там, конечно, только монолит, только на железо, а не серверлессы и кубернетесы. Но таких проектов видел мало. Но, да, в пропасти между распиздяйским серверлессом для игрулек и кровавым энтертпрайзом для банка есть куча проектов уровня RoR / Spring Boot, где монолит — самое оно.

  Развернуть 1 комментарий

@madhead, ну я робко выскажусь о том что после вашего ухода , компании которые всем этим владеют скорее всего оценят вашу реальную стоймость и поймут что вы тащили за 2-3 разрабов, ну либо не так уж много они действительно релизятся. Но опять же это мое ИМХО основанное сугубо на том что люди обладающие всеми скилами для поддержки такого типа архитектуры в одиночку - дорогое удовольствие.

  Развернуть 1 комментарий

@SAXER, вопрос моей реальной стоимости и проблемы компании после моего ухода не имеют отношения к сказанному, имхо. Частота релизов вообще-то тоже. У меня фичи релизяться по мере надобности. Физически релиз занимает 20 минут, во время которых я просто наблюдаю прогресс пайплайна и попивают чаёк.

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

  Развернуть 1 комментарий
за «Микросервисы»

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

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

Не надо изначально делать кубер, но и не надо использовать автоинкремент в БД.

Не надо неделю дизайнить gRPC между модулями, но хотя бы просто модули и DI а не tight coupling - надо.

за «Монолит»
Потому что микросервисы нужны далеко не всем и не всегда
Аватар Anton Ivanov Anton Ivanov

за «Монолит»
Я не против микросервисов, но…
Аватар Sergey Kapralov Sergey Kapralov

Если рассматривать вопрос с точки зрения дизайна, то... сюрприз! Разницы абсолютно никакой. Успех архитектуры всегда зависит исключительно от того, как качественно задача будет декомпозирована на абстракции, при этом принципы декомпозиции схожи везде - инвертируй зависимости, держи абстракции стабильными и ориентированными на бизнес цели. Монолит и микросервисы в этом отношении абсолютно идентичны.

А вот с технической и огранизационной точки зрения начинаются плюсы и минусы:

  • С одной стороны - декомпозиция на микросервисы открывает возможности для масштабирования, манипуляций со стеком технологий, дает ряд готовых решений по мониторингу и администрированию
  • С другой стороны, декомпозиция на микросервисы - это очень жирная декомпозиция. Там где в монолите, условно, вызов виртуального метода на классе, в микросервисах - вызов API, межпроцессное взаимодействие, что означает повышенный latency и нужду в fault tolerance. Микросервисы здорово поднимают порог входа - помимо самого сервиса, дополнительным головняком теперь идет инфраструктура с ее киберами и кафками. Повышенные накладные расходы на саппорт, повышенная стоимость ошибки.

И самое главное. Всратые микросервисы саппортить в разы больнее всратого монолита. А на раннем этапе (стартап же) архитектура будет всрата гарантированно, инфа 100%, это закон. Если пойти путем хайпа с самого начала, до реальных плюшек от микросервисов можно и не дожить.

за «Монолит»
Стартапу монолит, серьезным и большим ребятам SoA
Аватар Denis Lysenko Denis Lysenko

В стартапе главное – скорость разработки. Если стартап трушный, с какими-нибудь нагруженнами штуками, можно выделить именно эти куски в сервисы на условном go/elixir/erlang чтобы совладать с этим, а все остальное засадить в монолит на языке, где скорость разработки максимальная и большое количество доступных кадров на рынке (типа Ruby/PHP).

Этикет батлов:
  • 💣 Батл — это схватка двух крайностей. Мы пытаемся выделить аргументы каждой из сторон чтобы потом по ним составить свою картину мира. Рекомендуется избегать аргументов типа «каждый хорош для своего».
  • ☝️ Один аргумент — один комментарий. Не делайте списков, так сложнее вести дискуссию и подсчитывать статистику.
  • 😎 Можно топить как за одну, так и за обе стороны сразу. Просто выберите за кого вы при постинге.
  • 💬 На аргументы можно отвечать. Реплаи никуда не засчитываются и нужны только для срача.
  • 👮‍♀️ Авторам батлов нужно удалять повторы и комментарии не по формату.

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб