Комментарии 17
«Зачем мне многослойка для CRUD API, работающего с одним ресурсом?».
Хорошо, хотите микросервисы – получайте новый набор инструментов
Звучит как очень краткий пересказ сказки. Однажды, давным-давно, в тридевятом царстве, в превеликом государстве жил был дед. И вот, однажды, по усам текло, а в рот не попало.
Микросервисы появились не из-за проблем с многослойкой или нежеланием разделять, это не аналог или замена MVC. Как сравнивать теплое и мягкое, в общем.
Да здравствуют монолиты!
Монолиты никогда не был злом, им пугали менеджмент, что вот если оставим все как есть, то стоимость сопровождения и внедрения новых фич будет расти экспоненциально. У кого-то это было оправдано, кто-то выбивал / пилил бюджеты, кто-то хотел, потому что модно и нужно для резюме.
Монолиты никогда не был злом, им пугали менеджмент, что вот если оставим все как есть, то стоимость сопровождения и внедрения новых фич будет расти экспоненциально. У кого-то это было оправдано, кто-то выбивал / пилил бюджеты, кто-то хотел, потому что модно и нужно для резюме.
Поздравляю, вы кратко пересказали статью и её посыл
Проекты, в которых чек за логирование и трейсы стоит больше, чем вся остальная инфраструктура.
А еще мониторинг.
Сейчас очень популярен прометеус, но даже не половина, а 90% разработчиков понятия не имеют что в нем есть, и тупо кидают туда все подряд. Пользуясь максимум 5-10% метрик. А метрики эти надо собирать, хранить, надо возможно бэкапить, надо возможно даунсамплить. Возможно настраивать какие-то дашборды в прометеусе или графане. А их никто не смотрит, а еще возможно надо какой-то меш, чтобы не потерялись все эти микросервисы...
В то время как более простые варинаты мониторинга с ручной подкруткой требуют в разы меньше ресурсов.. Но их нужно сетапить, а прометеус говорит что "я все за вас сделаю"...
Справедливо:
вы собираетесь сказать, что какой-то инструмент плох, и готовы кричать
об этом, может быть, вы его не к тому или не так прикладываете? =)
Здесь бы я всплмнил необоснованную критику Ричардом Столлманом языка tcl/tk и слова Брайана Кернигана:
Удачным кажется и то, что разделение задач между Тсl и С/С++
осуществляется достаточно легко, надо только знать, какой инструмент
лучше справляется с задачей...
В своё время мне очень понравилась фраза Мартина Фаулера,
Которая оказалось не фразой а высказыванием. А так, аналогично анекдоту о молчащем мальчике, всё в замке нормально.
Я бы добавил, что механика динамики трендов двухфазная. Сначала у менеджмента возникает новая идея как сэкономить, а потом её копируют окружающе. Таким образом, мы имеем именно мартышку в квадрате.
Правильно относиться к феномену, то есть не ждать от гоминид иного вообще, может помочь, например, популяризаторская деятельность профессора Савельева, что на YouTube что через книги.
Никогда не думал что микросервисы можно рассматривать как средство борьбы со сложностью. Монолит проще всегда, а все архитектурыне преимущества декомпозиции в 10 раз проще реализовать внутри монолита абстрактно чем порезав систему физически на куски.
Преимущества микросервисов - независимый деплой и независимо работающие команды. По-моему только так отвечают даже на собесах.
Например, надо добавить новую фитчу. В монолите при этом может потребоваться несколько сквозных доработок на всех уровнях, начиная с одной на всех модели базы данных. В итоге нужно вовлечь много людей, кто-то занят, придется ждать.
Если же архитектура микросервисная - как правило команда ответственная за фитчу пилит и деплоит ее а другие команды даже ничего не знают. Это реально работает. Плата за такую архитекруру - адово нарушение DRY (нет крутой наработанной за годы платформы на все случаи жизни, каждая команда пилит ее элементы сама) и куча трудностей с агрегацией/синхронизацией данных из разных сервисов.
Микросервисы проще всегда, просто потому, что вы работаете с меньшим количеством кода и пилите конкретный проект, а с другим сервисом общаетесь через gateway.
Потому, очевидно, вам не надо разбираться, какая часть кода про этот функционал, а какая нет. Не надо раздумывать, не натворит-ли ваша фича что-то в другом функционале.
Так что единственное, что в монолите проще, это наговнокодить и поруинить всё, а вот разбираться с рукотворным памятником тараканам из головы конкретного разработчика, вот это куда сложнее, чем в микросервисах.
так что монолит это хорошо до определённого момента, пока есть ядро функционала. Когда фичи разбухают, есть смысл их выносить. Ну, прям как деление клетки
Микросервисы проще всегда, просто потому, что вы работаете с меньшим количеством кода и пилите конкретный проект, а с другим сервисом общаетесь через gateway.
Хм.. Не согласен. Был свидетелем частичного перехода продукта на 10 млин строк кода с монолита на микросервисы. Такое как вы пишете впечатление может создаться у человека который две недели в проекте, или если в этом монолите забили на любую архитектуру и затыкали дыры кто во что горазд. Но если монолит работоспособен и конкурентен, то обычно это означает что его проектировали далеко не дураки. В нем всегда будет совершенно ясное разделение на модули, слои, будут красивые эффективные концепции. Причем все это будет сделано лучше чем в микросервисах из за отсутствия дополнительных ограничений.
Если эта архитектура не выработана, то очень наивно надеятся, что просто выбор микросервисной архитектуры эту архитектуру внесет. Если компания не смогла нанять людей, которые могли бы сделать красивый монолит, она тем более не сможет сделать вменяемую микросервисную архитектуру.
В сущности микросервисную архитектуру со всеми ее концепциями примерно раз в 10 проще один в один воспроизвесити в монолите, чем в ее натуральном виде. Просто API сервисов превратятся в интерфейсы.
Если вам нужно добавить новую фитчу, в монолите вы попадаете в обсустроенный мир, где все уже предусмотрено, надо только посмотреть что он вам предоставляет и добавить свой код. В микросервисах конечно тоже подобное можно реализовать, но тогда это будет опять тот же монолит, только раз в 100 более медленный.
Суть микросервисов, как раз в том чтобы в каждом сервисе было намного больше кода чем нужно, что вам придется делать самостоятельно много вещей которые в монолите уже были бы из коробки. И соответственно придется иметь дело с большим количеством плохого кода чем в случае монолита. Но зато теперь команда может добавить в базу сущность или использовать любимый фреймворк не спрашивая главного архитектора компании. И не нужно идти на поклон к ведущему девелоперу, чтобы добавить мелкую фишку в платформу, потому что удобной и гибкой платформы больше никакой нет, а вместо нее локальный кривоватый кусочек кода, воспроизводящий то что было в платфонме в частном случае. Оно хуже чем было в платформе монолита, но зато ваше персональное решение, которое можно менять хоть каждый спринт.
Потому, очевидно, вам не надо разбираться, какая часть кода про этот функционал, а какая нет. Не надо раздумывать, не натворит-ли ваша фича что-то в другом функционале.
Ну нет, так не бывает. Я такого во всяком случае ни разу не видел. Так бывает если позволить рулить в проекте программистом с двумя годами опыта. Проблема когда у вас одна фитча ломает другие преодолевается любым девелопером после того как он запустил свои первые 30 000 строк кода. Если люди этого не умеют и вы поручите им проектировать микросервисную архитектуру, то результат буде точно таким же - непостижимо запутанная сеть микросервисов вместо непостижимого монолита.
Так что единственное, что в монолите проще, это наговнокодить и поруинить всё, а вот разбираться с рукотворным памятником тараканам из головы конкретного разработчика, вот это куда сложнее, чем в микросервисах.
Так в микросервисе как раз разработчик чувствует себя гораздо свободнее в плане говнокода. И потом с ним все равно придется разбираться.
Могу повториться, по моему мнению это очень наивная надежда. Если люди не умеют строить архитектуру в монолите (это относительно простой навык) и вы просто добавите им искуственные заборы, все станет только хуже, потому что работа с заборами требует больших навыков, чем без них.
Это примерно как задолбаться с процедурным говнокодом и заставить людей пользовать ООП и надеяться что теперь все станет лучше. Никогда в жизни не станет. Люди которые не научились писать понятный процедурный код точно не смогут написать понятный объектный.
так что монолит это хорошо до определённого момента, пока есть ядро функционала. Когда фичи разбухают, есть смысл их выносить. Ну, прям как деление клетки
Да, это совершенно верно. Но проблема не в запутанности монолита или говнокоде в нем. Проблема в том что монолит это идеальная архитектура для сольного разработчика, который в одиночку пилит весь проект. В случае если проект пилит 100 человек, возникют те самые проблемы о которых я писал. Вам нужно добавить фитчу, для этого нужно что-то поменять том самом удобном и универсальном окружении монолита, которое вы используете. И для этого становитесь в очередь к ведущему разработчику компании, чтобы он это сделал или согласовал, а потом ваш клиент будет ждать пол года пока будет очередной деплой монстра. С микросервисами пишем все самостоятельно, пусть кривее, пусть еще две команды делали почти то же самое, но зато прямо сегодня, отвечает за это конкретная команда и никто ей больше не нужен. И продукт идет вперед.
Микросервисы проще всегда, просто потому, что вы работаете с меньшим количеством кода и пилите конкретный проект, а с другим сервисом общаетесь через gateway.
Для этого необязательно физически разделять микросервисы, можно разделить на модули, как физические (отдельные библиотеки), так и, условно, на папки в репозитории.
Это работает пока не нужно пилить фичу, которая аффектит больше чем на одну команду, а таких фич довольно много. И как только такое случается проблем возникает сильно больше, чем если бы делали в модульном монолите, т.к. командам нужно взаимодействовать и нужен кто-то, кого будут все слушать в спорных ситуациях.
Дело не в цикличности, а в том, что новое не заменяе старое, а сосуществует с ним. Почти всегда. Другое дело, что есть тренды и им обычно следуют в большинстве случаев
Что касается проблем - так они почти все от ДНК, а он не меняется
Вот, кстати, согласен. Кажется основное, что плохо понимают люди, это то, что «одно другому не мешает». А людям надо постоянно всё друг другу противопоставить и обязательно занять сторону, а потом с пеной у рта доказывать, что их херня лучше, чем херня соседа.
Хотя практика показывает, что именно разнообразие подходов и грамотное их сочетание даёт отличный рост, что не надо пытаться решать все задачи одним, самым правильным способом
Тут скорее я пробовал описать проблему цикличности. А так да - дело совсем не в ней =)
Крылов писал так-сказать-микросервисы в виде басен, а Пушкин писал и так-сказать-микросервисы в виде стихов, и так-сказать-монолиты в виде например "Евгений Онегин". Вопрос: кто был-есть более успешен?
Мартышка и АйТи