Комментарии (47)
alexkuzko
04.11.2018 13:00… особенно финал, в котором можно заметить недосказанность: нормально поднять сам k8s может и не получиться, придется это отдавать на откуп поставщикам таковых решений, со всеми минусами оттуда вытекающими…
А по форме: креативно, понравилось.de1m
04.11.2018 20:42Я считаю, что установка очень даже проста, особенно если использовать что-то типа kubespray. Вот дальше уже сложнее.
bravosierrasierra
05.11.2018 01:01угу, только в этом kubespray очень много возможностей, из-за чего много кода для универсальности. В итоге получаем умную уберсложную магическую штуку, которая периодически требует досконального разбирательства почему у тебя очередной раз развалился кластер из-за очередного умолчания, которое у тебя внезапно нарушилось. И повторные прогоны плейбука ничего не чинят. Самопал на основе kubernetes the hard way оказывается гораздо управляемее и предсказуемее.
stratosmi
05.11.2018 09:21Я считаю, что установка очень даже проста, особенно если использовать что-то типа kubespray. Вот дальше уже сложнее.
Mini-kube еще нормально ставить волшебным инсталлятором.
Но боевую систему управления сложными программными комплексами ставить и не понимать как она работает и где чинить в случае чего…
Borz
05.11.2018 10:17Зачем ставить miniKube, когда Kubernetes уже с Docker поставляется в "Docker for Mac/Windows"?
stratosmi
05.11.2018 16:44Зачем ставить miniKube, когда Kubernetes уже с Docker поставляется в «Docker for Mac/Windows»?
Речь о том, что ставить в боевое применение и не понимать что да как, полагаясь на автоматический инстраллятор — это странно.
При чем тут Mac/Win? Kubernetes точится под Linux и только под него.
То, что можно разрабатываться/тестировать с Mac/Win — это не применение на боевых серверах.
Sergey-S-Kovalev
04.11.2018 14:05Шикарный комикс, вдохновляет… правда IP-адреса начинающиеся на 918.xx.xx.xx меня смущают, а капитана почему то нет.
А потом я возвращаюсь в реальность и вспоминаю, сколько труда и ресерча вложено в автоматизацию банальных рабочих процессов… и понимаю, что про 10 минут опять маркетингово лукавят, либо это не твоими руками, но за твои деньги.
DRVTiny
04.11.2018 14:59А что же делать, если в контейнеры распиханы самые разные версии одной и той же сторонней или даже своей библиотеки и вдруг выясняется, что в её версии такой-то выявлен жёсткий баг, а в контейнерах у нас, между тем, почти все версии — ниже «такой-то». Такой библиотекой может быть не только что-то банальное, но и libssl, а багом может быть и потенциальное переполнение буфера / получение shell или просто «фишка», позволяющая вашим конкурентам убить работающее приложение наповал.
ОСи на виртуалках обновляют компоненты одновременно, в них системные администраторы контролируют актуальность библиотек, своевременное залатывание security-hole'ов. Ааа… кто отвечает за это в случае, когда ключевые компоненты и библиотеки попросту суются внутрь контейнеров?
P.S> Нужно ещё отметить упор на «разные версии» одной библиотеки — это важно, потому что да, есть подход, позволяющий пресобрать все контейнеры, содержащие внутри библиотеку X, одним махом, после чего перезапустить контейнеры. Например, разделение контейнеризации на «слои» легко позволяет так делать. Но… «А что если приложению YZ нужна версия библиотеки XX0, а приложению TP нужна версия библиотеки XX1?» И тут конечно на стоит вопрос о том, чтобы исправить приложение, ринципиально использующее древнюю и бажную как Г мамонта версию библиотеки. Точно так же, как и про то, что контейнеры должны бы собираться послойно разработчики знать не хотят. Я прав?chupasaurus
05.11.2018 03:38А что же делать
Статическое сканирование образов: Clair.
кто отвечает за это в случае, когда ключевые компоненты и библиотеки попросту суются внутрь контейнеров?
Те же сисадмины/безопасники должны бить по рукам заFROM ubuntu:latest, хотите сесурити — делайте свой Docker registry с защищенными тегами для прода и около + читать что вы там деплоите.
то, что контейнеры должны бы собираться послойно разработчики знать не хотят. Я прав?
В моём маленьком свечном заводе со слоями иногда даже перебарщивают. Тут важно объяснять зачем и как это делать.
stratosmi
04.11.2018 15:02Только совсем недавно обсуждали прямо таки обратную вещь
habr.com/company/raiffeisenbank/blog/427953
Микросервисы делают мир проще (а вот и нет)
c0f04
05.11.2018 11:52- В монолите шансы на большую непонятно как работающую штуковину гораздо больше, чем в микросервисах.
- Монолит может сильно ограничивать проект в плане добавления новых возможностей (микросервисы уже автоматически декомпозированы).
- В статье ничего не сказано про сложности функциональных тестов монолита по сравнению с тестированием микросервисов.
Fortop
05.11.2018 14:45+1Если вкратце.
То нет — не взлетят ваши микросервисы с таким пониманием.
Вопросы к переосмыслению вами ваших же тезисов:
- Откуда взяты «шансы»? Можно ознакомиться с этим статистическим анализом?
- Чем большая непонятно как работающая, но одна штуковина сложнее в управлении десятков простых непонятно как связанных штуковин? Hint:
vs
- Откуда информация про сложности добавления новых возможностей не завязанных на уже существующие реализации?
- И да, что дороже функциональное тестирование монолитного приложения или связки из десятков/сотни микросервисов? А почему?
Далеко ходить не надо. На одном соседнем проекте, изначально разрабатывавшемся как микросервисный, через год разработки пошли разговоры о том что надо все переписать заново.
Как-то это крайне далеко от идеологии микросервисов.
Старая картинка
Так вот точка пересечения по моим личным практическим ощущениям лежит где-то за десятками человек-лет разработки проекта.
Много у нас таких проектов встречает среднестатистический разработчик?c0f04
05.11.2018 16:02Hint:
Вы не поверите, но и автомобиль, и электроника — это зачастую куча разных микросервисов, иерархически объединённые в одну сложную систему. Простой в создании она становится именно благодаря декомпозиции на независимые составляющие.
Откуда информация про сложности добавления новых возможностей не завязанных на уже существующие реализации?
Опыт разработки монолитной системы.
И да, что дороже функциональное тестирование монолитного приложения или связки из десятков/сотни микросервисов? А почему?
Потому что покрыть тестами желательно каждую мелочь в монолитном проекте. Если отдельно микросервис покрыт собственными тестами, то в монолите в каждом тесте требуется тестировать сразу весь проект. Тут стоит сделать оговорку, что и в монолите можно повставлять всякие моки и подобное, но сложности будут. Из-за таких сложностей либо тесты будут дорогостоящими, либо будут очень дешёвыми комплексными и не учитывающими множественные частные случаи, т. к. по большей части тесты будут просто отсутствовать, а ошибки — циклически исправляться на лету.
Разницы во времени разработки (без учёта тестирования/исправления ошибок) с самого начала между двумя подходами быть практически не должно, если всё грамотно сделано. В случае микросервисов будет только начальный период подготовки инфраструктуры для внедрения и тестирования, а также создание скелета системы. Но это же ускоряет тестирование и отладку в будущем по сравнению с монолитными проектами.
Плюс монолита — в скорости начальной разработки, но не более. Монолит подходит для создания прототипа. И достоверных графиков Вы здесь не найдёте, а предположенные приводить бессмысленно, т. к. для подобного исследования потребовалось бы очень много денежных средств.
Есть вещи где достаточно логики, основанной на необходимых базовых знаниях, чтобы с большой долей вероятности выдвигать какие-либо гипотезы. Это тот случай.Borz
05.11.2018 16:10вы видимо не разделяете монолит как один модуль и монолит как набор модулей, объединённый в единое целое на этапе сборки.
c0f04
05.11.2018 17:05Есть проекты, где нет никакого смысла в микросервисах. Есть проекты, где монолитную систему можно сделать модульной, но всё ещё нет смысла в микросервисах. Есть те, — где уже появляются выгоды при создании микросервисной архитектуры, но всё ещё можно монолитом сделать. А есть проекты, где монолит будет уже сильно убыточен из-за дороговизны поддержки. Всё зависит от сложности проекта.
stratosmi
05.11.2018 19:52Всё зависит от сложности проекта.
Не от сложности.
Компромиссы микросервисов
Микросервисы: размер имеет значение, даже если у вас Kubernetes
При переходе с монолита на микросервисы — сложность никуда не исчезает.
Она просто переходит в связи между микросервисами.
В монолите шансы на большую непонятно как работающую штуковину гораздо больше, чем в микросервисах.
Сложность никуда не исчезает.
Просто вместо одного большого непонятного комка получаем комок непонятных связей.
Правильнее было бы рассматривать отдельные связки узлов.
Нам ничто не мешает делать ровно то же и в монолите — рассматривать по частям.
То что он называется «монолит» не означает, что там «сплошняк».
Есть же принципы SOLID/«Чистая архитектура»
Чистая архитектура
stratosmi
05.11.2018 17:42Откуда информация про сложности добавления новых возможностей не завязанных на уже существующие реализации?
Опыт разработки монолитной системы.
То есть потому что это оказалось непросто — вы делаете выводы, что любая другая неизвестная технология будет лучше?c0f04
05.11.2018 18:40То есть потому что это оказалось непросто — вы делаете выводы, что любая другая неизвестная технология будет лучше?
Может всё-таки потому, что проект заходит местами в тупики и потихоньку всё-таки обрастает микросервисами? Переделать монолитный проект в микросервисный (каким он изначально и задумывался) намного дороже. Почему так — вопросы финансирования, кадров, сроки и компромиссы.stratosmi
05.11.2018 19:46Переделать монолитный проект в микросервисный (каким он изначально и задумывался) намного дороже
Вы не путаете с SOA?
Современные проекты не монолиты по сути.c0f04
05.11.2018 20:07+1Микросервисы, судя по Википедии, входят в SOA и это не обязательно контейнеры и оркестрация через популярные штуковины. А границы термина размыты.
* Взаимодействие одноранговое.
* Если один микросервис не поднялся, остальные продолжают работать в штатном режиме (иначе — ошибка разработчика).
Чем не микросервисы?stratosmi
05.11.2018 21:22Чем не микросервисы?
Современное типовое приложение это:
Бэкенд
СУБД
Кэш в памяти (Redis, Tarantool и пр.)
+внешние службы
+иногда почтовый сервер
+иногда отдельный бэкенд под фоновые задачи
По вашей классификации это получается микросервисная архитектура.
Ну тогда никакой SOA и монолитов в реальной жизни не бывает, что ли?
Все микросервисы?
P.S.:
Имхо микросервисная архитектура без какой-нибудь оркестрации — это нонсенс. Значит она еще не сервисы микро- в неимоверном количестве использует, если ей оркестрация еще не нужна.
c0f04
05.11.2018 21:58+1По вашей классификации это получается микросервисная архитектура.
* Шина взаимодействия IPC разная.
* Система вряд ли будет работоспособна, если хотя бы один сервис упадёт.
* Вряд ли в такой системе предусмотрена возможность запуска нового сервиса, о котором другие до того не знали, так, чтобы он начал взаимодействовать с другими сервисами.
Имхо микросервисная архитектура без какой-нибудь оркестрации — это нонсенс.
Я бы не стал привязывать термин исключительно к новомодным явлениям. Микросервисы в первую очередь однотипны (исполняются в одной среде), и каждый выполняет ровно свою полностью законченную задачу. Вы сейчас говорите об этом шаблоне использования:
Microservices architectures have given rise to many approaches for making them work well at varying degrees of scale. One widely discussed pattern for large-scale microservices development and delivery is the service mesh pattern.
In a service mesh, each service instance is paired with an instance of a reverse proxy server, called a service proxy, sidecar proxy, or sidecar. The service instance and sidecar proxy share a container, and the containers are managed by a container orchestration tool such as Kubernetes.
Fortop
06.11.2018 13:39Вы не поверите, но и автомобиль, и электроника — это зачастую куча разных микросервисов,
Не поверю.
Потому что именно из такогопонимания, которое на самом деле непонимание и вырастают проблемы при работе с микросервисами.
Большинство подсистем в автомобиле несамостоятельны и встроены в иерархию.
Именно поэтому он в целом монолит.
Тогда как клубок проводков с картинки выше это именно клубок независимых проводков.
Так что, как мы только что выяснили, одной лишь логики (возможно конкретно вашей) совсем недостаточно для тех трех утверждений, которые вы себе позволили.c0f04
06.11.2018 16:18Тогда как клубок проводков с картинки выше это именно клубок независимых проводков.
Вы просто взяли и разделили механические связи и электрические, хотя по факту оба являются способом передачи энергии и данных. Если забыть про эти же провода в автомобиле, взять для рассмотрения электромобиль, двигатель нельзя запустить отдельно от автомобиля? Или аккумулятором нельзя запитать что-либо в другой цепи? А сколько датчиков у автомобиле? Может там всё-таки много групп микросервисов разного рода?
Если красиво спрятать провода, то будет монолит получается? Странная логика.Fortop
06.11.2018 23:46Если красиво спрятать провода, то будет монолит получается?
Это ваши выводы. И они ошибочны как и предыдущие.
Вот розетки в рамках нормальной сети одной квартиры вполне себе микросервисы.
От того что откажет одна/пять/десять из розеток всем остальным не холодно и не жарко.stratosmi
07.11.2018 01:21Вот розетки в рамках нормальной сети одной квартиры вполне себе микросервисы.
От того что откажет одна/пять/десять из розеток всем остальным не холодно и не жарко
- Невозможно держать монолиты в нескольких инстансах на случай чего? (а в серьезных проектах их так и запускают — минимум 3 экземпляра одновременно)
- Вы преувеличивайте возможности отказоустойчивости микросервисов. Если в интернет-магазине не будет работать микросервис, отвечающий за один из элементов — корзину — это означает, что у вас нет интернет-магазина
Fortop
07.11.2018 13:53Повторюсь. Ключевой момент не количество экземпляров.
А независимость и одноранговость при небольшой функциональности.
Миллиарды инсталяций windows не делают ее микросервисом.
И, да, если у вас без корзины не работает магазин — не делайте ее микросервисом. Это в целом бессмысленно.
Разве что для единообразности подхода.
c0f04
07.11.2018 10:47Можно подумать, если двигатель откажет в автомобиле, то датчики ничего показывать не будут, или колёса крутиться не будут. Если тормоз откажет во время движения, машина ведь не перестанет ехать от этого? :)
От того что откажет одна/пять/десять из розеток всем остальным не холодно и не жарко.
Сравнивать нужно не розетки, а приборы. Розетка — это разомкнутая цепь, а, значит, ток не проводит. И даже если у Вас стоят автоматы везде по дому и по нейтрали, и по фазе, пара человек в доме всегда могут догадаться пустить заземление по отопительной батарее (на нейтраль тоже любят пускать). Случаи, когда какой-то уникум спалит оборудование по подъезду, случаются.
Всё-таки пытаться сложность работы микросервисов через аналогию с электротехникой или механикой — это бессмысленная идея. Это как пытаться доказать математическую теорему через философию.
sayber
06.11.2018 23:01Захотели мы сделать из этого самосвала карьерного, электромобиль. Современно, экономно и т.п.
Что же нам делать?
А точно! Выкинуть двигатель, выкинуть топливную систему (или просто забить на нее), выкинуть коробку и т.д.
Ну можно не выкидывать, т.к. на это слишком много времени уйдет.
Давайте просто в кузов кинем кучу аккумуляторов и прихерачим как то двигатель к оси. Старое пусть остается, может не помешает. Подумаешь тяжело, прорвемся.
Заводим… не завелось. Давай копаться.
Блин, ось то подсоединена к старой системе. Давай откручивать.
Открутили, заводим и… да чтож такое.
Пока откручивали, повредили связь между электродвигателем и осью.
…
…
…
Примерно так происходит с монолитами, особенно если они оч. крупные.stratosmi
07.11.2018 01:23Примерно так происходит с монолитами, особенно если они оч. крупные.
Да.
Если вы не знаете/не умеете/не следуете принципам SOLID/«Чистой архитектуры».sayber
07.11.2018 11:13Принципам SOLID. Модно стало говорить об этом.
Но результат один.
Я не сторонник монолита или микросервисов. Все зависит от целей и времени.
Последний проект следовал solid + DDD архитектура.
А затем надо было перевести бизнес совершенно на другие рельсы. И это стало серьезной проблемой.
stratosmi
05.11.2018 16:47В монолите шансы на большую непонятно как работающую штуковину гораздо больше, чем в микросервисах.
Сложность никуда не исчезает.
Просто вместо одного большого непонятного комка получаем комок непонятных связей.
c0f04
05.11.2018 16:57Правильнее было бы рассматривать отдельные связки узлов. У меня такой график в Doxygen был недавно. Просто в любом сложном проекта он абсолютно неинформативен.
stratosmi
05.11.2018 17:39Монолит может сильно ограничивать проект в плане добавления новых возможностей (микросервисы уже автоматически декомпозированы).
Вы считаете, что любая декомпозиция — это благо?
А что если декомпозированы неправильно, где будет легче исправить? Думаете переписать несколько микросервисов будет легче?c0f04
05.11.2018 18:31А что если декомпозированы неправильно, где будет легче исправить? Думаете переписать несколько микросервисов будет легче?
Думаю, что можно будет сделаю прослойку абстракции для API, а переписывать по мере надобности. Весь проект будет переписать тяжелее, в любом случае.
И, думаю, не стоит рассматривать случай, когда декомпозиция была неправильной по той причине, что делалась начинающими программистами? Там в обоих случаях всё плохо будет.stratosmi
05.11.2018 19:48+1Думаю, что можно будет сделаю прослойку абстракции для API
Не поможет.
Если вам для получения данных придется делать JOIN между микросервисами (а это пример кривой композиции) — производительность будет страдать неимоверно.
И, думаю, не стоит рассматривать случай, когда декомпозиция была неправильной по той причине, что делалась начинающими программистами?
Не боги горшки обжигают.
Это самые обычные программисты. И миддлы и сеньоры.
Fox_exe
04.11.2018 15:28Вообще в ММО сервера плодят путем копирования «Эталонного» сервера на виртуалки в нужном количестве. Ну плюс какойнить простенький скрипт, который «Донастраивает» такие сервера при запуске (Задаёт имя сервера или ещё чего).
fukkit
04.11.2018 16:23Комикс классный. И про гугл правильно. На такого вендора завязываться — путь к финансовым проблемам.
Кто в курсе, что в кубернетисе с персистентностью сейчас?
Реально что-то сохранить без базы? Куда?
Mimus_spb
04.11.2018 21:22Вкусовщиназа контент ничего сказать не могу — не читал
но от рисовки глазки бо-бо
никто не ждет уровня Оды или Кишимото
но на том же www.webtoons.com/en овермного очень юных авторов рисуют прям супер кайфовоriver-fall
05.11.2018 00:46+12014 — We must adopt #microservices to solve all problems with monoliths.
2016 — We must adopt #docker to solve all problems with microservices.
2018 — We must adopt #kubernetes to solve all problems with docker
Acuna
05.11.2018 20:58Действительно, почем Афина выглядит как «малолетняя косплеерша»?) Если предположить, что в любых комиксах, объясняющих преимущества чего-либо на пальцах, используются герои, создающие максимально положительный образ этого продукта, то опять же, почему она ребенок? Хмммм...)
Sergey-S-Kovalev
06.11.2018 09:39+1Афина как олицетворение микросервисов:
— Относительно молода.
— Выглядит божественно.
— Энтузиазм новичка, который проглотил маркетинговый материал, и возможно, успел попользовать на какие то тестовых проектах с положительным результатом.
— Не участвовала в реальных боях в проде, когда война идет годами, а сервисов и их разнообразия — легион. Поэтому нет шрамов и взгляда смотрящего сквозь ничтожность бытия.Acuna
07.11.2018 03:40О, а ведь и правда, это многое объясняет, благодарствую!) Еще подумал, что только у детей может быть столько бьющей через край активности и энергии (что так же определенно плюс), ее аж трясет, но касаемо взрослой женщины это выглядело бы как минимум странно)
Anton23
Офигенно. Все по полочкам разложли.