Видимо в вашем понимании в мире микросервисов все происходит легко, а если приложение монолитное, то все становится резко сложнее.
Слушайте, я занимаюсь "миром микросервисов и монолитов" уже более 8 лет, я сам пытался писать окрестратор на Ansible как раз для монолита, потому что руками его было раскатывать нереально в то время и я ленив. Так вот — там никогда не было легко, но сложность микросервисов компенсируется с лихвой их гибкостью, если вам это не надо, пользуйтесь монолитом, это не грех. Одно другого не исключает, даже гибриды есть, но это не значит, что монолит или микросервисы это плохо, они каждый для своего для своей архитектуры.
По факту, с точки зрения развертывания, монолит это один микросервис.
Точно? А не набор сильно связанных сервисов? Там немного другие техники развертывания, микросервисы я могу обновить покомпонентно, а монолит мне придется делать хотя бы green/blue чтобы не пятисотить пользователям. И это если у вас относительно простое приложение, а если там много частей и монолит монструозен?
Монолиты очевидно жрут меньше ресурсов.
Вообще ни в каком месте не очевидно. Для оптимальной работы монолита его наверное надо запускать с определенными лимитами/реквестами, если монолиты вы хостите на одном инстансе, либо монолит на инстанс. То есть вы заранее выделяете какое-то количество ресурсов, для того чтобы запустить все компоненты монолита (а представьте что у вас он при старте качает 1Gb инфы просто чтобы начать работать, например текущие схемы обсчета данных). И по итогу, если мне надо скейлить другой функционал, не связанный с данными, я вынужден буду держать часть ресурсов монолита вхолостую.
Скейлится монолит очень лего. Не хватает ресурсов — добавляем. Как я уже писал выше — сначала scale up, потом scale out. Да, вы будете скейлить одновременно и память и процессоры, потому что программа упрется во что-то одно. Так и хосты для кубера вы также будете скейлить одновременно и по памяти и по процессорам.
Я выше расписал, почему это не легко, если система относительно сложная и разные профили нагрузок. Вы будете скейлить монолит одновременно по всем метрикам, верно, в случае микросервисов вы можете задачам с высоким потреблением цпу дать машины с много цпу мало памяти, в случае с скейлингом по памяти дать memory-type машины, в результате вы не тратите лишние ресурсы там, где не надо.
У микросервисов есть одно неоспоримое преимущество перед монолитом — высокий темп релизов при больших командах, и то надо соблюдать немало условий чтобы он был достижим. В остальном недостатки.
А в маленьких все будет плохо? Возможность выкатывать изменения не ломая соседу жисть это только на больших объемах работает?
Во-первых это красивая байка, но во всех современных системах исключения перехватываются и логируются, а фронт продолжает отвечать на запросы, даже если какая-то фоновая задача падает.
Вообще ничего не понял, с каких пор "современные системы" стали свободны от ошибок реализации и логики? Утечка памяти тоже логируется? А логи кто вставляет в приложение? А исключений перехват и обработка? Не разработчик? Фронт отвечает — бэк нет, из-за паники в горутине. Вполне стандартная ситуация.
Во-вторых в монолитах самих очередей будет меньше, так как они просто не нужны. передача управления делается вызовом функции.
Простите, что? Для чего, по вашему, нужна очередь сообщений? Как вам передача управления посредством функции решит проблему доставки и хранения запросов? Давайте тогда через очередь пример — вы, например, чуть сложнее блога и у вас очередь запросов, ну например вы таки ее догадались внедрить после падений монолита и потери запросов, несмотря на красивую идею делать все через вызовы функций(кстати, а вы в монолите мгновенно все запросы обрабатываете, в отличие от микросервисов и запросы не копятся? а если копятся то где, в монолите?). Вы делаете в монолите изменения в части, не связанной с очередью и выкатываете на прод. Прод падает, с ним и обработка очереди. Вполне реальный пример. Что делать будете?
Ну да, снижение затрат в 10 это не преимущество, а фигня какая-то.
Слушайте, я верю, что они там снизили затраты в 10 раз, это не фигня, вопрос был — точно ли снижение затрат это следствие перехода с богомерзких микросервисов в православный монолит, или это результат переработки архитектуры и отказа от хранилища в качестве медиатора данных. Вот я это и пытаюсь выяснить, но пока что не удается
Вы с таким пафосом пишете "скейлить целый монолит"…
У нас "монолит" весит 120МБ (вместе с ресурсами, в общем всё что деплоится). Сколько весят образы ваших микросервисов суммарно без учёта дублирования слоёв?
Где вы пафос нашли — ума не приложу. Вы же скейлите монолит на инстанс и не пихаете кучу монолитов в одно место, верно? То есть для скейла монолита нужна целая машина, иначе смысла нет — оверхед на переключение контекста будет такой же как и на микросервисах, если не больше.
У нас монорепо, в один образ кладутся 20 бинарников, вес образа 100Мб, так как образ один, то и общий объем такой же.
У нас развёртывание от момента нажатия на кнопочку билда до того что пользователи (2.5млн в сутки, 25млн в месяц) видят новую версию делается меньше чем за 5 минут (blue/green deployment, основное время занимает сборка и доставка артефактов на целевые машины).
У нас пользователей от 700к до 3кк в день, сезонное. Примерно сравнимо. Раскатка всех микроосервисов (аналогично раскатке монолита, но не blue/green, обычный роллаут + канареечный деплой для вещей которые сложно проверить в тестах) — 3-4 минуты от пуша в репу до деплоя, сам роллаут занимает минут 10 на всю площадку этоо если все передоеплоивать, ибо мы делаем graceful shutdown. А вам для blue/green приходится поднимать копию прода, как я понимаю? И как по стоимости по сравнению с роллаутом, сравнимо? ) Про кваклификацию опущу пассаж — я придерживаюсь мнения, что девелоперы люди и могут ошибаться, поэтому я лучше с этим что-то буду делать для нивелирования ошибки а не вершать ярлыки
Дополнительный бонус — всё можно запустить на своём рабочем ноутбуке, без прыжков с Docker compose или недо-куберами типа k3s. Просто из среды разработки. Тестовая БД доступна через VPN, при желании и достаточной смелости можно подключиться и к продовой.
То же самое — можно запустить локально хоть часть, хоть все, БД, очереди и кеши доступны через впн. Компоуз файл написан один раз и используется всеми простой командой docker compose up, поднимая заодно и некоторые локальные зависимости. Что с этим не так?
Ошибки — опциональный откат на предыдущую версию (делается минуту), исключение проблемного коммита или коммитов, новый деплой. Можно уточнить кстати про пример с утечкой памяти? Это абстрактный или конкретный был пример, можно детали?
Учитывая, что у вас голубосиний деплой, вы все это время держите две продовые площадки, пока ищете ошибку, собираете и накатываете по новой, верно? Не очень выгодно. Пример не абстрактный, а вполне реальный — апдейт одной из гошных либ привела к утечке памяти под нагрузкой, просто откатили версию назад одного из микросервисов и разбирались с причиной, другие микросервисы и пользователей это не затронуло вообще. А в вашем варианте будет даунтайм, как думаете? Вы же уже переключите на, положим, блю, и течь будет везде по всему монолиту, верно?
Про "изолированно чинить микросервис" и "скейлить монолит", я бы хотел послушать не абстрактные измышления, а конкретные примеры.
Я в предыдущем комменте привел более чем конкретные примеры с разными типами задач для разных микросервисов, с разными типами нагрузок (burst load/spikes/plain). И выше привел пример как чинить микросервис(в кавычки взяли вы потому, что у вас как-то по другому это называется)? Эти разные типы задач скейлятся сильно по разному, и требуют даже иногда разных инстансов для оптимальной работы — некоторые жрут ЦПУ, некоторые память, некоторые коннекты, некоторые другие ограниченные ресурсы, например API ключи. А еще у нас декстоп клиенты под 60к в пике со своими фокусами, и под них тоже нужны свои прцедуры скейла.
Жизнь становится сильно интереснее, если у тебя не просто сайт с блогами и картинками, даже если это drive2.ru
Монолит, если его развёртывание автоматизировано, прекрасно масштабируется в обе стороны.
Я когда-то скейлил ворпресс, там да, хорошо мастабируется в обе стороны. Но далеко не кажды сайт или приложение в инете это простой вордпресс.
Если вам нужна ETL-задача (2 часа в сутки), её можно назначить на отдельную группу экземпляров монолитов, которая масштабируется по другим правилам.
Конечно можно. А можно на каждую задачу по своей группе экземпляров монолита со своими скейл-правилами, хотя постойте, чем это будет отличаться от микросервисов, ну кроме межсервисного взаимодействия?
Вместо того чтобы делать RPC между каждым из компонентов с кучей "клея" в виде кубера, service mesh и т.д., на содержание которого нужен целый отдел. Не вопрос, этим всем может быть интересно заниматься, опять же за "микросервисный девопс" хорошо платят.
http вызовы это RPС, как думаете? Кубер это не клей, это оркестратор, я им и монолиты успешно скейлил простые, а вы чем их скейлите, руками или скриптом?
service mesh отдельный разговор, он не всегда нужен, но там где нужен — в сложных распределенных системах, там он очень помогает в плане visibility & management. Нам на всю нашу платформу хватает трех человек, которые занимаются всеми инфрастуктурными вещами. Зачем вам отдел под "клей" — ума не приложу.
Микросевисного девопса не бывает, девопс это методология и она включает разные варианты — от простейшего веб-сайта, до ML/AI. Вообще за девопс неплохо платят, да, думаете зря? )
С умным видом рассказывать что ты не JSON-ы из БД в HTTP перекладываешь, а настраиваешь Cilium и оркестрируешь контейнеры =)
Перекладыванием json занимаются разработчики, я им предоставляю платформу для максимально удобной работы. Контейнеры у меня оркестрирует кубер, а у вас? что касается CNI, я уж не помню, когда последний раз в его настройки залазил, последние 5 лет все работает из коробки.
В общем, я думаю у нас просто разные подходы к devops, поэтому вам кажется что я придумываю проблемы на пустом месте, а мне кажется, что ваш специфический опыт подходит далеко не всем.
пс. было бы любопытно встретиться на собеседовании, я бы поспрашивал вас по нюансам скейлинга монолитов =)
В этом конкретном случае: стоимость передачи данных между микросервисами оказалась слишком высока, что увеличивало стоимость решения до неприемлемого уровня.
Это как? За счет чего? Бакет убрали из архитектуры? Так его и из микросервисов можно было убрать
Как его скейлить?
Также как микросервисы — увеличивать количество инстансов. Вообще горизонтально масштабирование придумали сильно раньше, чем микросервисы.
Отлично, а по какой метрике? Вот представьте себе сферическое приложение — качает данные из сети, принимает запросы от пользователей в очередь, при этом еще делает выгрузку в БД периодически и отдает ее по запросу. При микросервисах это отдельные компоненты и скейлятся по разному — кач из сети скейлится по памяти, обработчик очереди скейлится по цпу, выгрузка в БД скейлится по коннектам а отдача по кастомной метрике например количеству юзеров. А монолит вы по чему скейлить будете?
мне нужно скейлить весь монолит, оставляя обработчик данных и вывод работать вхолостую?
При правильной архитектуре у тебя не создаются объекты если нет запросов. Поэтому простаивающие части приложений будут жрать ничего. В отличие от простаивающих микросервисов.
Из предыдущего примера — я правильно понимаю, что мне нужно будет скейлить целый монолит просто потому, что выросло количество пользователей, а все остально не выросло, но у нас же монолит?
Это как? Масштабирование хранилища в монолите и микросервисах никак не отличается. Масштабирование вычислений в микросервисах делается также как в монолите — вы просто увеличиваете количество узлов. Монолит в свою очередь экономит вычислительные ресурсы, так как не занимается перекладыванием данных через хранилище. (пример из статьи amazon prime)
Опят же, из примера — мне нужно много памяти для закачки данных, в микросервисах мне нужно увеличить память именно для него, но я в монолите скейлю вообще все и остальные компоненты тоже, в том числе ненужные и это даст мне экономию? Может проще с бакетом было решить проблему, см первый пункт
Сначала scale up, потом scale out. Это все делалось задолго до изобретения микросервисов
Что делать, если в монолите выгрузка в БД, причем 2 часа в сутки, а остальное время не работает — зажимать выгрузку, чтобы не держать монолит вхолостую или наоборот? Может есть какой-то фреймворк или библиотека, о которой я не знаю и которая делает вышеуказанное вами из коробки и правильно?
как этот монолит перезапускать без потери качества и данных?
Как обычно one node at a time.
Ухх, ну давайте. У нас 10 монолитов, мы неспеша раскатываем релиз по вашему алгоритму. Кстати, почему по одной ноде, а не по две или не по пять? Ну ок, мы по одной их раскатываем, раскатывается долго, это же монолит. Приходит разраб и говорит — у меня хотфикс, надо срочно накатить. Но пусть подождет окончания раскатки, там миграция и все такое, хотя хотфикс с миграцией не связан, но у нас монолит. Окончив релиз, начинаем раскатывать хотфикс, по одному, на все 10 нод(при микросервисах было бы 2 инстанса). И тут прибегает еще один разраб и говорит — у нас память течет после релиза в месте, не связанном с БД, надо откат делать всего для регрессии. А мы не можем, у нас деплой идет да и миграция уже была, в общем, подождут пусть пользователи, пока мы тут все раскатаем, зато монолит!
что делать если он упадет?
Поднимать. Опять-таки задолго до изобретения микросервисов изобрели feature flags, VIP switch и другие технологии zero-downtime деплоймента.
Не очень понятно, как относится фича флаги и прочее что вы указали к zero-time deployment, но допустим — у вас в монолите в обработчике очереди паника, сервисы валятся и лежит весь монолит. Микросервис можно было бы изолированно чинить, а так приходится дергать весь монолит, и боюсь тут ни фича-флаги ни VIP switch, ни каким-то боком приплетенный zero-time deployment не помогут.
имхо самое глупое — это обвинять в ошибках проектирования архитектурный паттерн.
В данном случае вполне оправдано.
Лично мне неочевидно, имхо тут просто избавились от бакета как промежуточного хранилища и это дало буст по стоимости и скорости. У меня тут недавно случай был — бакет s3 смонтировали как nfs диск и при количестве данных в смешные 10Гб счет выходил за $1к, потому что стоимость операций с бакетом при работе как с диском на порядки больше стоимости самого хранилища.
Так что я пока не увидел преимущества монолита перед микросервисом, по крайней мере с эксплуатационной точки зрения
Все, разобрался, спасибо! Статья вида "что такое докер и с чем его едят" в 2023.
Я думал пропустил чего или не понял, так как тема монолит vs микросервисы интересна именно в плане эксплуатации монолита, но увы, ничего в статье этого нет
Вопросы скучные, для мидлов на знание документации и кругозор.
Мне больше сеньорные вопросы нравятся, типа "а расскажи как ты делал то то и то то и почему" и сидишь перетираешь, заодно софт скиллы оценить можно
Тогда я не очень понимаю, о чем статья?
О том, что не надо везде пихать микросервисы? Так это известно с начала их появления.
Что надо начинать с монолита? Спорно, зависит от задач и связности команд, но допустим среднестатистический проект принято начинать с монолита, хорошо.
Если разработкой архитектуры занимаются маркетологи, то и результат будет соответствующий.
У меня на проекте есть и NoSQL и GraphQL и микросервисы и все это еще и в кубе, прости господи. И все хорошо и довольно дешево работает. Я пытался представить себе весь наш проект из 30 микросервисов в монолите, представил сборку и тестирование этого монстра, (не считая деплоя и инцидентов) и проснулся в холодном поту.
Я даже не знаю, что лучше уже — хайп или хейт, можно я просто буду выбирать архитектуру по задаче, а не по отзывам "самого Амазона".
Хорошо, мои неправильные вопросы вы перефразировали в постулаты известных проблем монолита, на которых нет ответа.
Может, давайте начнем сперва с моих "легких вопросов"? Пусть и неправильных
Так и не понял, в чем беда микросервисов и выгода монолита?
Вот собрал я свои глупые микросервисы(ввод данных, обработка, вывод) в один сияющий монолит, хорошо. Как его скейлить? микросервисы я мог скейлить независимо друг от друга, а монолит? ради увеличения мощности одного компонента, например ввода данных, мне нужно скейлить весь монолит, оставляя обработчик данных и вывод работать вхолостую? что делать, когда данных много и в один монолит не вмещается? увеличивать количество монолитов(ой, не это же первый шаг к микросервисам) или раздувать саму машину? как этот монолит перезапускать без потери качества и данных? что делать если он упадет?
иихо самое глупое - это обвинять в ошибках проектирования архитектурный паттерн.
как то вы усложняете все. Там же проще можно - создаешь ЧВК 'Кобальт' из жителей неблагополучных регионов разваливающейся империи, они отжимают шахты у аборигенов, а на вопросы всегда можно сказать 'настамнет'
И вы будете абсолютно правы! Во-первых, используя докер, во-вторых нанимая дев-опс инженера, правда, а не менеджера, вам же делать что-то надо, правильно? Только обычно девопс нужен тогда, когда уже есть команда а то и несколько и которым нужны площадки для разработки и тестирования. По опыту могу сказать, что при должном планировании и квалификации девопс инжененера вы получите: - решение задач SRE - устойчивость продакшн системы, мониторинг-алертинг (работающие!), снижение затрат на инфрастуктуру и развертывание, улучшение качества услуг клиентам - решение задач разработки - добавление новых сервисов быстрее и безболезненнее, минимизирован человеческий фактор, ваши сервера переходят из pet-режима (любимец, не трогать иначе боль!) в cattle (жги ломай все равно новые за минуты поднимаются а вся инфа в gitops и видны все изменения). - ваши инженеры повышают техуровень, осваивая к8с и новые тулзы, с удовольствием тыкают на трейсы и залипают на графики. Они видят результаты работы и изменений и это мотивирует! Нет рутины и у них, они делают свою работу а не ждут пока что-то там настроится и починится из-за случайно перепутанного порядка деплоя. в итоге это позволяет и вам сосредоточиться на разработке, на вашем бизнесе, а не заниматься инфраструктурой и саппортом инженеров.
И это не сферический в вакууме пример, это реальная история, наблюдаемая мной лично и не один раз. А так можно и кабелеукладчиком в квартире ночник подключать, я думаю, тоже будешь немного разочарован.
Пойду удалю свои IaC, буду накликивать инфрастуктуру руками, ведь инфра в облаке должна хранить тепло человеческих рук, а не бездушность пайплайна. Ну и что, что это занимает в 10 раз больше времени и повышает вероятность ошибки.
Еще думаю поудалять весь ci/cd - он нарушает принцип kiss и вносит сложность в доставку. Пусть собирают руками, это не сложно и занимает всего день, вместо 10 мин, зато имеет встроенный тимбилдинг.
Ну и вишенкой думаю, будет отказ от облаков. Оттуда все эти девопсы полезли фантомные. А нужен возврат к корням - серверу под столом секретарши и админам в свитерах.
Слушайте, я занимаюсь "миром микросервисов и монолитов" уже более 8 лет, я сам пытался писать окрестратор на Ansible как раз для монолита, потому что руками его было раскатывать нереально в то время и я ленив. Так вот — там никогда не было легко, но сложность микросервисов компенсируется с лихвой их гибкостью, если вам это не надо, пользуйтесь монолитом, это не грех. Одно другого не исключает, даже гибриды есть, но это не значит, что монолит или микросервисы это плохо, они каждый для своего для своей архитектуры.
Вообще ни в каком месте не очевидно. Для оптимальной работы монолита его наверное надо запускать с определенными лимитами/реквестами, если монолиты вы хостите на одном инстансе, либо монолит на инстанс. То есть вы заранее выделяете какое-то количество ресурсов, для того чтобы запустить все компоненты монолита (а представьте что у вас он при старте качает 1Gb инфы просто чтобы начать работать, например текущие схемы обсчета данных). И по итогу, если мне надо скейлить другой функционал, не связанный с данными, я вынужден буду держать часть ресурсов монолита вхолостую.
Я выше расписал, почему это не легко, если система относительно сложная и разные профили нагрузок. Вы будете скейлить монолит одновременно по всем метрикам, верно, в случае микросервисов вы можете задачам с высоким потреблением цпу дать машины с много цпу мало памяти, в случае с скейлингом по памяти дать memory-type машины, в результате вы не тратите лишние ресурсы там, где не надо.
А в маленьких все будет плохо? Возможность выкатывать изменения не ломая соседу жисть это только на больших объемах работает?
Вообще ничего не понял, с каких пор "современные системы" стали свободны от ошибок реализации и логики? Утечка памяти тоже логируется? А логи кто вставляет в приложение? А исключений перехват и обработка? Не разработчик? Фронт отвечает — бэк нет, из-за паники в горутине. Вполне стандартная ситуация.
Простите, что? Для чего, по вашему, нужна очередь сообщений? Как вам передача управления посредством функции решит проблему доставки и хранения запросов? Давайте тогда через очередь пример — вы, например, чуть сложнее блога и у вас очередь запросов, ну например вы таки ее догадались внедрить после падений монолита и потери запросов, несмотря на красивую идею делать все через вызовы функций(кстати, а вы в монолите мгновенно все запросы обрабатываете, в отличие от микросервисов и запросы не копятся? а если копятся то где, в монолите?). Вы делаете в монолите изменения в части, не связанной с очередью и выкатываете на прод. Прод падает, с ним и обработка очереди. Вполне реальный пример. Что делать будете?
Слушайте, я верю, что они там снизили затраты в 10 раз, это не фигня, вопрос был — точно ли снижение затрат это следствие перехода с богомерзких микросервисов в православный монолит, или это результат переработки архитектуры и отказа от хранилища в качестве медиатора данных. Вот я это и пытаюсь выяснить, но пока что не удается
Где вы пафос нашли — ума не приложу. Вы же скейлите монолит на инстанс и не пихаете кучу монолитов в одно место, верно? То есть для скейла монолита нужна целая машина, иначе смысла нет — оверхед на переключение контекста будет такой же как и на микросервисах, если не больше.
У нас монорепо, в один образ кладутся 20 бинарников, вес образа 100Мб, так как образ один, то и общий объем такой же.
У нас пользователей от 700к до 3кк в день, сезонное. Примерно сравнимо. Раскатка всех микроосервисов (аналогично раскатке монолита, но не blue/green, обычный роллаут + канареечный деплой для вещей которые сложно проверить в тестах) — 3-4 минуты от пуша в репу до деплоя, сам роллаут занимает минут 10 на всю площадку этоо если все передоеплоивать, ибо мы делаем graceful shutdown. А вам для blue/green приходится поднимать копию прода, как я понимаю? И как по стоимости по сравнению с роллаутом, сравнимо? ) Про кваклификацию опущу пассаж — я придерживаюсь мнения, что девелоперы люди и могут ошибаться, поэтому я лучше с этим что-то буду делать для нивелирования ошибки а не вершать ярлыки
То же самое — можно запустить локально хоть часть, хоть все, БД, очереди и кеши доступны через впн. Компоуз файл написан один раз и используется всеми простой командой docker compose up, поднимая заодно и некоторые локальные зависимости. Что с этим не так?
Учитывая, что у вас голубосиний деплой, вы все это время держите две продовые площадки, пока ищете ошибку, собираете и накатываете по новой, верно? Не очень выгодно. Пример не абстрактный, а вполне реальный — апдейт одной из гошных либ привела к утечке памяти под нагрузкой, просто откатили версию назад одного из микросервисов и разбирались с причиной, другие микросервисы и пользователей это не затронуло вообще. А в вашем варианте будет даунтайм, как думаете? Вы же уже переключите на, положим, блю, и течь будет везде по всему монолиту, верно?
Я в предыдущем комменте привел более чем конкретные примеры с разными типами задач для разных микросервисов, с разными типами нагрузок (burst load/spikes/plain). И выше привел пример как чинить микросервис(в кавычки взяли вы потому, что у вас как-то по другому это называется)? Эти разные типы задач скейлятся сильно по разному, и требуют даже иногда разных инстансов для оптимальной работы — некоторые жрут ЦПУ, некоторые память, некоторые коннекты, некоторые другие ограниченные ресурсы, например API ключи. А еще у нас декстоп клиенты под 60к в пике со своими фокусами, и под них тоже нужны свои прцедуры скейла.
Жизнь становится сильно интереснее, если у тебя не просто сайт с блогами и картинками, даже если это drive2.ru
Я когда-то скейлил ворпресс, там да, хорошо мастабируется в обе стороны. Но далеко не кажды сайт или приложение в инете это простой вордпресс.
Конечно можно. А можно на каждую задачу по своей группе экземпляров монолита со своими скейл-правилами, хотя постойте, чем это будет отличаться от микросервисов, ну кроме межсервисного взаимодействия?
http вызовы это RPС, как думаете? Кубер это не клей, это оркестратор, я им и монолиты успешно скейлил простые, а вы чем их скейлите, руками или скриптом?
service mesh отдельный разговор, он не всегда нужен, но там где нужен — в сложных распределенных системах, там он очень помогает в плане visibility & management. Нам на всю нашу платформу хватает трех человек, которые занимаются всеми инфрастуктурными вещами. Зачем вам отдел под "клей" — ума не приложу.
Микросевисного девопса не бывает, девопс это методология и она включает разные варианты — от простейшего веб-сайта, до ML/AI. Вообще за девопс неплохо платят, да, думаете зря? )
Перекладыванием json занимаются разработчики, я им предоставляю платформу для максимально удобной работы. Контейнеры у меня оркестрирует кубер, а у вас? что касается CNI, я уж не помню, когда последний раз в его настройки залазил, последние 5 лет все работает из коробки.
В общем, я думаю у нас просто разные подходы к devops, поэтому вам кажется что я придумываю проблемы на пустом месте, а мне кажется, что ваш специфический опыт подходит далеко не всем.
пс. было бы любопытно встретиться на собеседовании, я бы поспрашивал вас по нюансам скейлинга монолитов =)
Это как? За счет чего? Бакет убрали из архитектуры? Так его и из микросервисов можно было убрать
Отлично, а по какой метрике? Вот представьте себе сферическое приложение — качает данные из сети, принимает запросы от пользователей в очередь, при этом еще делает выгрузку в БД периодически и отдает ее по запросу. При микросервисах это отдельные компоненты и скейлятся по разному — кач из сети скейлится по памяти, обработчик очереди скейлится по цпу, выгрузка в БД скейлится по коннектам а отдача по кастомной метрике например количеству юзеров. А монолит вы по чему скейлить будете?
Из предыдущего примера — я правильно понимаю, что мне нужно будет скейлить целый монолит просто потому, что выросло количество пользователей, а все остально не выросло, но у нас же монолит?
Опят же, из примера — мне нужно много памяти для закачки данных, в микросервисах мне нужно увеличить память именно для него, но я в монолите скейлю вообще все и остальные компоненты тоже, в том числе ненужные и это даст мне экономию? Может проще с бакетом было решить проблему, см первый пункт
Что делать, если в монолите выгрузка в БД, причем 2 часа в сутки, а остальное время не работает — зажимать выгрузку, чтобы не держать монолит вхолостую или наоборот? Может есть какой-то фреймворк или библиотека, о которой я не знаю и которая делает вышеуказанное вами из коробки и правильно?
Ухх, ну давайте. У нас 10 монолитов, мы неспеша раскатываем релиз по вашему алгоритму. Кстати, почему по одной ноде, а не по две или не по пять? Ну ок, мы по одной их раскатываем, раскатывается долго, это же монолит. Приходит разраб и говорит — у меня хотфикс, надо срочно накатить. Но пусть подождет окончания раскатки, там миграция и все такое, хотя хотфикс с миграцией не связан, но у нас монолит. Окончив релиз, начинаем раскатывать хотфикс, по одному, на все 10 нод(при микросервисах было бы 2 инстанса). И тут прибегает еще один разраб и говорит — у нас память течет после релиза в месте, не связанном с БД, надо откат делать всего для регрессии. А мы не можем, у нас деплой идет да и миграция уже была, в общем, подождут пусть пользователи, пока мы тут все раскатаем, зато монолит!
Не очень понятно, как относится фича флаги и прочее что вы указали к zero-time deployment, но допустим — у вас в монолите в обработчике очереди паника, сервисы валятся и лежит весь монолит. Микросервис можно было бы изолированно чинить, а так приходится дергать весь монолит, и боюсь тут ни фича-флаги ни VIP switch, ни каким-то боком приплетенный zero-time deployment не помогут.
Все, разобрался, спасибо! Статья вида "что такое докер и с чем его едят" в 2023.
Я думал пропустил чего или не понял, так как тема монолит vs микросервисы интересна именно в плане эксплуатации монолита, но увы, ничего в статье этого нет
Вопросы скучные, для мидлов на знание документации и кругозор.
Мне больше сеньорные вопросы нравятся, типа "а расскажи как ты делал то то и то то и почему" и сидишь перетираешь, заодно софт скиллы оценить можно
Тогда я не очень понимаю, о чем статья?
О том, что не надо везде пихать микросервисы? Так это известно с начала их появления.
Что надо начинать с монолита? Спорно, зависит от задач и связности команд, но допустим среднестатистический проект принято начинать с монолита, хорошо.
Если разработкой архитектуры занимаются маркетологи, то и результат будет соответствующий.
У меня на проекте есть и NoSQL и GraphQL и микросервисы и все это еще и в кубе, прости господи. И все хорошо и довольно дешево работает. Я пытался представить себе весь наш проект из 30 микросервисов в монолите, представил сборку и тестирование этого монстра, (не считая деплоя и инцидентов) и проснулся в холодном поту.
Я даже не знаю, что лучше уже — хайп или хейт, можно я просто буду выбирать архитектуру по задаче, а не по отзывам "самого Амазона".
Хорошо, мои неправильные вопросы вы перефразировали в постулаты известных проблем монолита, на которых нет ответа.
Может, давайте начнем сперва с моих "легких вопросов"? Пусть и неправильных
Так и не понял, в чем беда микросервисов и выгода монолита?
Вот собрал я свои глупые микросервисы(ввод данных, обработка, вывод) в один сияющий монолит, хорошо. Как его скейлить? микросервисы я мог скейлить независимо друг от друга, а монолит? ради увеличения мощности одного компонента, например ввода данных, мне нужно скейлить весь монолит, оставляя обработчик данных и вывод работать вхолостую? что делать, когда данных много и в один монолит не вмещается? увеличивать количество монолитов(ой, не это же первый шаг к микросервисам) или раздувать саму машину? как этот монолит перезапускать без потери качества и данных? что делать если он упадет?
иихо самое глупое - это обвинять в ошибках проектирования архитектурный паттерн.
как то вы усложняете все. Там же проще можно - создаешь ЧВК 'Кобальт' из жителей неблагополучных регионов разваливающейся империи, они отжимают шахты у аборигенов, а на вопросы всегда можно сказать 'настамнет'
И которая показывает 32Gb shared GPU memory
И вы будете абсолютно правы! Во-первых, используя докер, во-вторых нанимая дев-опс инженера, правда, а не менеджера, вам же делать что-то надо, правильно?
Только обычно девопс нужен тогда, когда уже есть команда а то и несколько и которым нужны площадки для разработки и тестирования. По опыту могу сказать, что при должном планировании и квалификации девопс инжененера вы получите:
- решение задач SRE - устойчивость продакшн системы, мониторинг-алертинг (работающие!), снижение затрат на инфрастуктуру и развертывание, улучшение качества услуг клиентам
- решение задач разработки - добавление новых сервисов быстрее и безболезненнее, минимизирован человеческий фактор, ваши сервера переходят из pet-режима (любимец, не трогать иначе боль!) в cattle (жги ломай все равно новые за минуты поднимаются а вся инфа в gitops и видны все изменения).
- ваши инженеры повышают техуровень, осваивая к8с и новые тулзы, с удовольствием тыкают на трейсы и залипают на графики. Они видят результаты работы и изменений и это мотивирует! Нет рутины и у них, они делают свою работу а не ждут пока что-то там настроится и починится из-за случайно перепутанного порядка деплоя.
в итоге это позволяет и вам сосредоточиться на разработке, на вашем бизнесе, а не заниматься инфраструктурой и саппортом инженеров.
И это не сферический в вакууме пример, это реальная история, наблюдаемая мной лично и не один раз.
А так можно и кабелеукладчиком в квартире ночник подключать, я думаю, тоже будешь немного разочарован.
Прочитал, впечатлился.
Пойду удалю свои IaC, буду накликивать инфрастуктуру руками, ведь инфра в облаке должна хранить тепло человеческих рук, а не бездушность пайплайна. Ну и что, что это занимает в 10 раз больше времени и повышает вероятность ошибки.
Еще думаю поудалять весь ci/cd - он нарушает принцип kiss и вносит сложность в доставку. Пусть собирают руками, это не сложно и занимает всего день, вместо 10 мин, зато имеет встроенный тимбилдинг.
Ну и вишенкой думаю, будет отказ от облаков. Оттуда все эти девопсы полезли фантомные. А нужен возврат к корням - серверу под столом секретарши и админам в свитерах.