Comments 58
Странная статья. Почему монолит не может работать в кубе? И почему, не используя куб, не нужно будет использовать Grafana, трейсы, логи, нанимать SRE? Как будто в случае монолита и на "голых" виртуалках без этого всего можно обойтись. А так же ноль новых мыслей по сравнению с другими статьями на тему "монолит vs микросервисы".
Все можно и нужно, но для разных задач разные инструменты. Можно и монолит в kubernetes запускать, но вопрос - а зачем? Логи, метрики и т.д. вообще полезны, но если у вас простой сервис, который не обновляется и нет "движущихся" частей, скорее всего вы про них не вспомните после настройки. А вот когда что-то сложное, их не использовать - самоубийство. Да и если у вас сервис на одной виртуалке - кажется нанимать SRE в 99% это несколько избыточно, хотя редкие исключения, подтверждающие правило есть всегда.
Можно и монолит в kubernetes запускать, но вопрос - а зачем?
Для получения основных преимуществ контейнеров - изоляция, деплой.
Микропенисысервисы и кубер не обязательны друг с другом. И уж тем более не исключают другие подходы типа монолита с его зависимостями в кубере.
Я согласен, что микросервисы и Kubernetes не обязательны друг с другом. Как и что и у контейнеров есть свои преимущества, и у виртуалок. Мысль была в том, что вот есть у вас конкретный проект - для него оптимален определенный технологический стек, и не всегда он самый модный. Т.е. лучше ответить себе на вопрос - оно правда нужно? Часто - преимущества перевешивают недостатки, но не всегда. А если принимать решение исходя из моды, можно добавить излишнюю сложность в свой проект не получив преимуществ.
оптимален определенный технологический стек
Если уже определен стек, который соответствует всем условным требованиям и в нем нет кубера, то зачем туда пытаться пристроить кубер если решение не планируется быть встраиваемым?
Если смотреть со стороны где кубер просто решает определенные задачи, то его имеет смысл использовать при наличии таких задач, а с другой стороны можно подумать что раз модно -- значит надо. Вопрос -- на какой стороне Вы?)
Изоляция и деплой работают в системных виртуальных машинах, например.
Можно и монолит в kubernetes запускать, но вопрос - а зачем?
Так монолит же не в одиночку живёт, у него зависимости есть, может быть несколько инстансов монолита и так далее
Разумеется. Только кол-во взаимосвязей между инстансами монолита несравнимо с количеством взаимосвязей которым монолит обзаведётся после "распиливания" на микросервисы. Ну, много у Вас зависимостей и взаимосвязей в типичном LNMP? Собственно, 4 (четыре), что и дало название.
CI/CD? Для сайта на "пэхапэ" (например, 1С-Битрик) это просто выкатывание кода в директорию web-сервера, git сверху. Нет никаких проблем организовать это без использования микросервисов. Причём сделав разработку и эксплуатацию в разы безопасней и стабильней. Потому что точек отказа в разы меньше.
Звучит как будто бы монолиты - всегда что-то маленькое, а микросервисы - непомерно большое и комплексное. Кмк, можно делать 3.5 микросервиса, если команда посчитает это более удобным, так и делать монолит по функциональности в условный облачный провайдер.
Канарейные развертывания для тестирования гипотез, изоляция, оверлейные сети и проч - все это и монолиту применимо
xexe
Ковид более монолитен
я бы сказал что у ковида нормальная структура зависимостей, прямо эталон. Ядро и сеттелиты.
|Вы упрощаете понимание сложной системы
|Один из них – экспоненциально растущая сложность системы.
Есть даже “народная примета”: если вы используете микросервисную архитектуру, ваш сервис рано или поздно сломается. А если еще не сломался, то просто время не пришло.
Неважно какая архитектура вашего сервиса. Если у вас есть сервис, у вас есть проблемы.
А что сейчас без знания микросервисов бекендером не устроиться?
а мне казалось что k8s это в первую очередь - масштабирование, во вторую - управление.
если не забывать об этом то сразу понятно становится что где и как применять. и стоит ли пилить монолит на микросервисы
Все достоинства микросервисной архитектуры перечеркиваются правильным монолитом. Таким, как у САП. Там все эти достоинства также присутствуют, причём, в гораздо более удобном виде. Плюс колоссальное преимущество от того, что все данные в единой БД и доступны отовсюду. И без всяких этих ваших кубернетесов.
реальные внедренцы САПа думают немного по другому
Я реальный внедренец САП. Буду рад услышать аргументированные возражения коллег.
Плюс колоссальное преимущество от того, что все данные в единой БД и доступны отовсюду.
Да, и под эту единую базу данных нужен единый сервер с 16 процессорами и террабайтами оперативки. Который сейчас нигде не купишь.
Надуманная проблема. Если у вас 10 БД вместо одной, вам меньше вычислительной мощности потребуется? Заметно больше хотя бы по тому, что вы никогда не сбалансируете и не оптимизируете нагрузку 10 БД. А ещё их обслуживание. А ещё, "как мы любим" в мультисервисах, они будут все на разных СУБД - и вот с этим зоопарком вы упаритесь не считая всего остального.
А ещё эти 10 БД будут частично дублировать информацию друг из друга, а ещё информационные обмены между ними тоже не бесплатные. В итоге вы купите гораздо больше процессоров и оперативки, чем на одну БД.
Совсем не надуманная проблема проблема. Купить 8 серверов с двумя процессорами несложно, а вот один с 16тью уже квест. На счёт под каждый микросервис свою субд — ну дурость везде есть, кто то должен следить чтоб не притащили ничего лишнего.
Я не спец по БД, но почему-то уверен, что расшардить (сегментировать) единую БД на 8 серверов по 2 проца выйдет дешевле и производительнее, чем порезать приложение на 8 СУБД и разложить по тем же серверам. Хотя бы по тому, что нагрузку между 8 сегментами можно перераспределять гораздо гибче, чем бизнес-логику. Если сервер с данными о движениях на складах захлёбывается, а сервер с бухгалтерскими проводками недозагружен, вы никак не перераспределите нагрузку между ними, с этим и будете жить. А между сегментами легко. И опять же сервер с данными о движениях товаров будет дублировать данные о клиентах с сервером с данными о проводках. И грузиться бесконечными пересылками этих данных друг другу.
Очень зависит от специфики конкретного сервиса.
Если возникает необходимость независимо масштабировать части систему — монолит в пролёте.
Если возникает необходимость независимо выкатывать части системы — монолит в пролёте.
Ну а единая БД может быть и при микросервисной структуре (правда, многие считают это анти-паттерном).
Повторюсь, всё зависит от монолита. Если САП монолит (он имеет признаки и монолита и микросервиса), то я не встречал систем, которые масштабируются и расширяются удобнее. Нет проблем ни масштабировать, ни выкатывать релизы и обновлять хоть одну запятую, хоть тысячу человеко-дней разработки.
Я про САП ничего не знаю :(
Можете объяснить на пальцах, как можно в монолите независимо масштабировать/деплоить части системы?
Быстро не объясню. :-) В САПе переносится исходный код. Каждое изменение кода и структур данных записывается в т.н. "запрос на перенос" и специальная транспортная система переносит эти запросы между средами. То есть можно поправить одну букву, записать в запрос, эта буква переедет в целевую систему (в тест, потом в прод) и там обновится только та подпрограммка, в которой произошли изменения и которая включена в запрос на перенос. В целевой системе перекомпилируется только одна подпрограммка/модуль в которой произошли изменения. Весь код хранится в БД - одна подпрограммка - одна запись. Скомпилированный код тоже в БД. При обращении он оттуда вызывается. Очень похоже на микросервис, но монолит :-) Причём "сервисы" нарезаны гораздо мельче, чем в микросервисе. В системе сотни тысяч таких кусочков кода-подпрограмм-модулей каждый из которых обновляется независимо и это здорово автоматизировано.
Это то, что делают все системы управления зависимостями и системы плагинов. Заказываем апдейт, резольвер собирает новое дерево модулей, они скачиваются и компилируются в целое. Результат подхватывается приложением.
Расскажите, пожалуйста, с примерами)
Допустим, мы нашли ошибку в каком-то сложном алгоритме, реализованном в виде десятков вызываемых друг из друга методов (модулей кода). И ошибка только в одном из этих модулей кода. И ещё надо поменять тип поля в какой-то структуре, например таблице. Мы записываем в запрос на изменение имя изменённого модуля и изменение в структуре (не мы, они сами записываются при нашем контроле). Потом мы говорим - перенести такой-то запрос в тестовую среду. Или не один запрос, а целую очередь запросов. Система поможет выстроить последовательность запросов в очереди, но мы можем сделать это сами. Специальная транспортная система переносит очередь или один запрос в тест и там обновляется только один модуль и одно поле - в соответствии с нашим запросом. Мы тестируем и утверждаем перенос дальше в прод. И там так же обновляется только один модуль кода и одно поле в одной таблице.
При всём при этом десятки и сотни коллег из разных проектов, стран и континентов могут параллельно делать свои изменения в других модулях кода и структурах данных и мы особо не мешаем друг другу. Конфликты возникают только если разные люди одновременно меняют один объект. Но объекты небольшие и это происходит не часто и разруливается организационно.
Как продать контейнеры с коробочным деплоем на основе данных с гит реппозитория? Правильно, надо самим продавать хостинг контейнеров и говорить, что кубер это дорого и неудобно. Это просто другая игла. Хорошо, я повелся на рекламу - зашел, открыл доку https://docs.amvera.ru/ - где на вашей стороне мониторинг, логирование и все остальное что было перечислено? Пожалуй, что не стоит потраченного времени. Удачи в работе, в том числе и надо ошибками.
Наш сервис это не аналог kubernetes. У нас размещают небольшие проекты из 1-5 контейнеров (боты и т.д.). И основное в чем фишка - это доствка обновлений через push в GIT. Мы не пересекаемся с потребителями kubernetes, поэтому можем его и ругать и хвалить без задней мысли. Задачи решаемые нашими пользователями и пользователями k8s просто совсем разные.
И основное в чем фишка - это доствка обновлений через push в GIT
Ээ вы слышали про fluxcd?
Как хорошая альтернатива Kubernetes - Hashicorp Nomad. Поставляется в виде бинарного файла, который можно запустить в режиме сервера и в режиме клиента. Для небольших и средних проектов идеально подойдёт.
Заголовок и выводы про кубернетес, а статья про микросервисы почему-то. Плюс SRE, метрики и логи, которые вообще ни от одного, ни от другого не зависят.
Статья для рекламы?..
Не раскрыта тема сборок типа OpenShift или TKG, где решена часть проблем голого Kubernetes.
OpenShift - это такая сборка, которая по стоимости может перекрыть весь остальной софт на проекте. Проверено лично.
Лично же РедХат ронял в 5 раз по цене за счет лицензирования.
Повлиять на то, как девопсы наго... задеплоили контейнеры не мог, а то уверен, что еще раз в несколько бы смог.
Падение в цене очень сильно зависит от того, кто вы в цепочке поставки. И какие ваши коммерческие условия при закупке (объём, длительность, аванс).
У этого заказчика всё хорошо с объёмами и реселлеры зарабатывают только на рибейтах. С другой стороны и цены для них не проблема, так что не совсем понятно к чему жалоба на дороговизну.
Это не жалоба, а комментарий по поводу использования OpenShift. При традиционном для девопсов деплое "как бог на душу положит" лицензирование OpenShift может превысить стоимость ВСЕГО остального софта на проекте.
Соответственно бездумный подход для коммерческих дистрибутивов не катит.
Ну вы еще мне расскажите про цепочку поставок и спеццены с условиями.
Я говорю только о чисто техническом утаптывании по условиям лицензирования + оптимизацией самого лицензирования через подбор размеров виртуальных воркеров без каких либо дополнительных телодвижений по спецусловиям.
Статья ни о чем. Сравниваются микросервисы и монолит при деплое в кубер с претензией, буд-то монолит нельзя размещать в k8s. С какого перепугу?
По вашему мнению метрики, логи и прочее нужны только девопсам, а сисадмины таким не пользуются?
Кубер славится тем, что предоставляет абстракции и избавляет от кучи проблем, которые были раньше (конечно же добавляя новые, т.к. появляется оверхед сложности, добавляемый абстракциями). Множество вещей работает из коробки и ставится в несколько команд.
Ничего страшного в кубере нет. Надо просто брать и использовать, а не слушать байки от всяких продавцов хостингов. Поставили, потыкали, наловили ошибок, узнали нового, получили экспертизу. Как говорится, купить и дурак может.
Кубер, кстати, давно уже не на хайпе. Это такой же рабочий инструмент наравне с ансибл, терраформ и докер. Сам не пытайся хайповать на кубере и не втюхивай людям своё облако грязной рекламой.
Бесконечное усложнение систем. SAP ERP монстр, который используется на 90% крупных производственных предприятиях ни в кубере ни в микросервисах не нуждается
Ох уж этот страх и ужас перед микросервисами. Кровь, сопли, расчлёнёнка, как же сложно! Пятьдесят мониторов во всю стену, чтоб это замониторить. Монолит, он же внутри другой, там по сути одна большая функция, никакой сложности нет. И мониторить его не надо, с ним нет никаких проблем. Монолит наше всё! Микросервисы придумали, чтоб нас поработить и заставить пользоваться ненавистным кубернетисом.
А вам точно нужен Kubernetes?