Comments 51
Офигенно. Все по полочкам разложли.
… особенно финал, в котором можно заметить недосказанность: нормально поднять сам k8s может и не получиться, придется это отдавать на откуп поставщикам таковых решений, со всеми минусами оттуда вытекающими…
А по форме: креативно, понравилось.
А по форме: креативно, понравилось.
Я считаю, что установка очень даже проста, особенно если использовать что-то типа kubespray. Вот дальше уже сложнее.
UFO just landed and posted this here
Я считаю, что установка очень даже проста, особенно если использовать что-то типа kubespray. Вот дальше уже сложнее.
Mini-kube еще нормально ставить волшебным инсталлятором.
Но боевую систему управления сложными программными комплексами ставить и не понимать как она работает и где чинить в случае чего…
Зачем ставить miniKube, когда Kubernetes уже с Docker поставляется в "Docker for Mac/Windows"?
Зачем ставить miniKube, когда Kubernetes уже с Docker поставляется в «Docker for Mac/Windows»?
Речь о том, что ставить в боевое применение и не понимать что да как, полагаясь на автоматический инстраллятор — это странно.
При чем тут Mac/Win? Kubernetes точится под Linux и только под него.
То, что можно разрабатываться/тестировать с Mac/Win — это не применение на боевых серверах.
Шикарный комикс, вдохновляет… правда IP-адреса начинающиеся на 918.xx.xx.xx меня смущают, а капитана почему то нет.
А потом я возвращаюсь в реальность и вспоминаю, сколько труда и ресерча вложено в автоматизацию банальных рабочих процессов… и понимаю, что про 10 минут опять маркетингово лукавят, либо это не твоими руками, но за твои деньги.
А потом я возвращаюсь в реальность и вспоминаю, сколько труда и ресерча вложено в автоматизацию банальных рабочих процессов… и понимаю, что про 10 минут опять маркетингово лукавят, либо это не твоими руками, но за твои деньги.
А что же делать, если в контейнеры распиханы самые разные версии одной и той же сторонней или даже своей библиотеки и вдруг выясняется, что в её версии такой-то выявлен жёсткий баг, а в контейнерах у нас, между тем, почти все версии — ниже «такой-то». Такой библиотекой может быть не только что-то банальное, но и libssl, а багом может быть и потенциальное переполнение буфера / получение shell или просто «фишка», позволяющая вашим конкурентам убить работающее приложение наповал.
ОСи на виртуалках обновляют компоненты одновременно, в них системные администраторы контролируют актуальность библиотек, своевременное залатывание security-hole'ов. Ааа… кто отвечает за это в случае, когда ключевые компоненты и библиотеки попросту суются внутрь контейнеров?
P.S> Нужно ещё отметить упор на «разные версии» одной библиотеки — это важно, потому что да, есть подход, позволяющий пресобрать все контейнеры, содержащие внутри библиотеку X, одним махом, после чего перезапустить контейнеры. Например, разделение контейнеризации на «слои» легко позволяет так делать. Но… «А что если приложению YZ нужна версия библиотеки XX0, а приложению TP нужна версия библиотеки XX1?» И тут конечно на стоит вопрос о том, чтобы исправить приложение, ринципиально использующее древнюю и бажную как Г мамонта версию библиотеки. Точно так же, как и про то, что контейнеры должны бы собираться послойно разработчики знать не хотят. Я прав?
ОСи на виртуалках обновляют компоненты одновременно, в них системные администраторы контролируют актуальность библиотек, своевременное залатывание security-hole'ов. Ааа… кто отвечает за это в случае, когда ключевые компоненты и библиотеки попросту суются внутрь контейнеров?
P.S> Нужно ещё отметить упор на «разные версии» одной библиотеки — это важно, потому что да, есть подход, позволяющий пресобрать все контейнеры, содержащие внутри библиотеку X, одним махом, после чего перезапустить контейнеры. Например, разделение контейнеризации на «слои» легко позволяет так делать. Но… «А что если приложению YZ нужна версия библиотеки XX0, а приложению TP нужна версия библиотеки XX1?» И тут конечно на стоит вопрос о том, чтобы исправить приложение, ринципиально использующее древнюю и бажную как Г мамонта версию библиотеки. Точно так же, как и про то, что контейнеры должны бы собираться послойно разработчики знать не хотят. Я прав?
А что же делатьСтатическое сканирование образов: Clair.
кто отвечает за это в случае, когда ключевые компоненты и библиотеки попросту суются внутрь контейнеров?Те же сисадмины/безопасники должны бить по рукам за
FROM ubuntu:latest, хотите сесурити — делайте свой Docker registry с защищенными тегами для прода и около + читать что вы там деплоите.то, что контейнеры должны бы собираться послойно разработчики знать не хотят. Я прав?В моём маленьком свечном заводе со слоями иногда даже перебарщивают. Тут важно объяснять зачем и как это делать.
Только совсем недавно обсуждали прямо таки обратную вещь
habr.com/company/raiffeisenbank/blog/427953
habr.com/company/raiffeisenbank/blog/427953
Микросервисы делают мир проще (а вот и нет)
- В монолите шансы на большую непонятно как работающую штуковину гораздо больше, чем в микросервисах.
- Монолит может сильно ограничивать проект в плане добавления новых возможностей (микросервисы уже автоматически декомпозированы).
- В статье ничего не сказано про сложности функциональных тестов монолита по сравнению с тестированием микросервисов.
Если вкратце.
То нет — не взлетят ваши микросервисы с таким пониманием.
Вопросы к переосмыслению вами ваших же тезисов:
Далеко ходить не надо. На одном соседнем проекте, изначально разрабатывавшемся как микросервисный, через год разработки пошли разговоры о том что надо все переписать заново.
Как-то это крайне далеко от идеологии микросервисов.
Старая картинка
Так вот точка пересечения по моим личным практическим ощущениям лежит где-то за десятками человек-лет разработки проекта.
Много у нас таких проектов встречает среднестатистический разработчик?
То нет — не взлетят ваши микросервисы с таким пониманием.
Вопросы к переосмыслению вами ваших же тезисов:
- Откуда взяты «шансы»? Можно ознакомиться с этим статистическим анализом?
- Чем большая непонятно как работающая, но одна штуковина сложнее в управлении десятков простых непонятно как связанных штуковин? Hint:
vs
- Откуда информация про сложности добавления новых возможностей не завязанных на уже существующие реализации?
- И да, что дороже функциональное тестирование монолитного приложения или связки из десятков/сотни микросервисов? А почему?
Далеко ходить не надо. На одном соседнем проекте, изначально разрабатывавшемся как микросервисный, через год разработки пошли разговоры о том что надо все переписать заново.
Как-то это крайне далеко от идеологии микросервисов.
Старая картинка
Так вот точка пересечения по моим личным практическим ощущениям лежит где-то за десятками человек-лет разработки проекта.
Много у нас таких проектов встречает среднестатистический разработчик?
Hint:
Вы не поверите, но и автомобиль, и электроника — это зачастую куча разных микросервисов, иерархически объединённые в одну сложную систему. Простой в создании она становится именно благодаря декомпозиции на независимые составляющие.
Откуда информация про сложности добавления новых возможностей не завязанных на уже существующие реализации?
Опыт разработки монолитной системы.
И да, что дороже функциональное тестирование монолитного приложения или связки из десятков/сотни микросервисов? А почему?
Потому что покрыть тестами желательно каждую мелочь в монолитном проекте. Если отдельно микросервис покрыт собственными тестами, то в монолите в каждом тесте требуется тестировать сразу весь проект. Тут стоит сделать оговорку, что и в монолите можно повставлять всякие моки и подобное, но сложности будут. Из-за таких сложностей либо тесты будут дорогостоящими, либо будут очень дешёвыми комплексными и не учитывающими множественные частные случаи, т. к. по большей части тесты будут просто отсутствовать, а ошибки — циклически исправляться на лету.
Разницы во времени разработки (без учёта тестирования/исправления ошибок) с самого начала между двумя подходами быть практически не должно, если всё грамотно сделано. В случае микросервисов будет только начальный период подготовки инфраструктуры для внедрения и тестирования, а также создание скелета системы. Но это же ускоряет тестирование и отладку в будущем по сравнению с монолитными проектами.
Плюс монолита — в скорости начальной разработки, но не более. Монолит подходит для создания прототипа. И достоверных графиков Вы здесь не найдёте, а предположенные приводить бессмысленно, т. к. для подобного исследования потребовалось бы очень много денежных средств.
Есть вещи где достаточно логики, основанной на необходимых базовых знаниях, чтобы с большой долей вероятности выдвигать какие-либо гипотезы. Это тот случай.
вы видимо не разделяете монолит как один модуль и монолит как набор модулей, объединённый в единое целое на этапе сборки.
Есть проекты, где нет никакого смысла в микросервисах. Есть проекты, где монолитную систему можно сделать модульной, но всё ещё нет смысла в микросервисах. Есть те, — где уже появляются выгоды при создании микросервисной архитектуры, но всё ещё можно монолитом сделать. А есть проекты, где монолит будет уже сильно убыточен из-за дороговизны поддержки. Всё зависит от сложности проекта.
Всё зависит от сложности проекта.
Не от сложности.
Компромиссы микросервисов
Микросервисы: размер имеет значение, даже если у вас Kubernetes
При переходе с монолита на микросервисы — сложность никуда не исчезает.
Она просто переходит в связи между микросервисами.
В монолите шансы на большую непонятно как работающую штуковину гораздо больше, чем в микросервисах.
Сложность никуда не исчезает.
Просто вместо одного большого непонятного комка получаем комок непонятных связей.
Правильнее было бы рассматривать отдельные связки узлов.
Нам ничто не мешает делать ровно то же и в монолите — рассматривать по частям.
То что он называется «монолит» не означает, что там «сплошняк».
Есть же принципы SOLID/«Чистая архитектура»
Чистая архитектура
Откуда информация про сложности добавления новых возможностей не завязанных на уже существующие реализации?
Опыт разработки монолитной системы.
То есть потому что это оказалось непросто — вы делаете выводы, что любая другая неизвестная технология будет лучше?
То есть потому что это оказалось непросто — вы делаете выводы, что любая другая неизвестная технология будет лучше?
Может всё-таки потому, что проект заходит местами в тупики и потихоньку всё-таки обрастает микросервисами? Переделать монолитный проект в микросервисный (каким он изначально и задумывался) намного дороже. Почему так — вопросы финансирования, кадров, сроки и компромиссы.
Переделать монолитный проект в микросервисный (каким он изначально и задумывался) намного дороже
Вы не путаете с SOA?
Современные проекты не монолиты по сути.
Микросервисы, судя по Википедии, входят в SOA и это не обязательно контейнеры и оркестрация через популярные штуковины. А границы термина размыты.
* Взаимодействие одноранговое.
* Если один микросервис не поднялся, остальные продолжают работать в штатном режиме (иначе — ошибка разработчика).
Чем не микросервисы?
* Взаимодействие одноранговое.
* Если один микросервис не поднялся, остальные продолжают работать в штатном режиме (иначе — ошибка разработчика).
Чем не микросервисы?
Чем не микросервисы?
Современное типовое приложение это:
Бэкенд
СУБД
Кэш в памяти (Redis, Tarantool и пр.)
+внешние службы
+иногда почтовый сервер
+иногда отдельный бэкенд под фоновые задачи
По вашей классификации это получается микросервисная архитектура.
Ну тогда никакой SOA и монолитов в реальной жизни не бывает, что ли?
Все микросервисы?
P.S.:
Имхо микросервисная архитектура без какой-нибудь оркестрации — это нонсенс. Значит она еще не сервисы микро- в неимоверном количестве использует, если ей оркестрация еще не нужна.
По вашей классификации это получается микросервисная архитектура.
* Шина взаимодействия 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.
Вы не поверите, но и автомобиль, и электроника — это зачастую куча разных микросервисов,
Не поверю.
Потому что именно из такого
Большинство подсистем в автомобиле несамостоятельны и встроены в иерархию.
Именно поэтому он в целом монолит.
Тогда как клубок проводков с картинки выше это именно клубок независимых проводков.
Так что, как мы только что выяснили, одной лишь логики (возможно конкретно вашей) совсем недостаточно для тех трех утверждений, которые вы себе позволили.
Тогда как клубок проводков с картинки выше это именно клубок независимых проводков.
Вы просто взяли и разделили механические связи и электрические, хотя по факту оба являются способом передачи энергии и данных. Если забыть про эти же провода в автомобиле, взять для рассмотрения электромобиль, двигатель нельзя запустить отдельно от автомобиля? Или аккумулятором нельзя запитать что-либо в другой цепи? А сколько датчиков у автомобиле? Может там всё-таки много групп микросервисов разного рода?
Если красиво спрятать провода, то будет монолит получается? Странная логика.
Если красиво спрятать провода, то будет монолит получается?
Это ваши выводы. И они ошибочны как и предыдущие.
Вот розетки в рамках нормальной сети одной квартиры вполне себе микросервисы.
От того что откажет одна/пять/десять из розеток всем остальным не холодно и не жарко.
Вот розетки в рамках нормальной сети одной квартиры вполне себе микросервисы.
От того что откажет одна/пять/десять из розеток всем остальным не холодно и не жарко
- Невозможно держать монолиты в нескольких инстансах на случай чего? (а в серьезных проектах их так и запускают — минимум 3 экземпляра одновременно)
- Вы преувеличивайте возможности отказоустойчивости микросервисов. Если в интернет-магазине не будет работать микросервис, отвечающий за один из элементов — корзину — это означает, что у вас нет интернет-магазина
Повторюсь. Ключевой момент не количество экземпляров.
А независимость и одноранговость при небольшой функциональности.
Миллиарды инсталяций windows не делают ее микросервисом.
И, да, если у вас без корзины не работает магазин — не делайте ее микросервисом. Это в целом бессмысленно.
Разве что для единообразности подхода.
А независимость и одноранговость при небольшой функциональности.
Миллиарды инсталяций windows не делают ее микросервисом.
И, да, если у вас без корзины не работает магазин — не делайте ее микросервисом. Это в целом бессмысленно.
Разве что для единообразности подхода.
Можно подумать, если двигатель откажет в автомобиле, то датчики ничего показывать не будут, или колёса крутиться не будут. Если тормоз откажет во время движения, машина ведь не перестанет ехать от этого? :)
Сравнивать нужно не розетки, а приборы. Розетка — это разомкнутая цепь, а, значит, ток не проводит. И даже если у Вас стоят автоматы везде по дому и по нейтрали, и по фазе, пара человек в доме всегда могут догадаться пустить заземление по отопительной батарее (на нейтраль тоже любят пускать). Случаи, когда какой-то уникум спалит оборудование по подъезду, случаются.
Всё-таки пытаться сложность работы микросервисов через аналогию с электротехникой или механикой — это бессмысленная идея. Это как пытаться доказать математическую теорему через философию.
От того что откажет одна/пять/десять из розеток всем остальным не холодно и не жарко.
Сравнивать нужно не розетки, а приборы. Розетка — это разомкнутая цепь, а, значит, ток не проводит. И даже если у Вас стоят автоматы везде по дому и по нейтрали, и по фазе, пара человек в доме всегда могут догадаться пустить заземление по отопительной батарее (на нейтраль тоже любят пускать). Случаи, когда какой-то уникум спалит оборудование по подъезду, случаются.
Всё-таки пытаться сложность работы микросервисов через аналогию с электротехникой или механикой — это бессмысленная идея. Это как пытаться доказать математическую теорему через философию.
Да нет, пожалуй. Это с таким уровнем абстрагирования действительно сложно понять разницу между первым и вторым.
Нас не интересует разомкнутая цепь или нет. Равно как и с кем там общается данная конкретная розетка.
Для внешнего мира она представляет рабочий интерфейс доступа к электрической сети.
Эта электрическая сеть может быть и 110 и 220, постоянного или переменного тока — для розетки в целом не суть важно.
Она либо выполняет свою функцию, либо не выполняет. На жизнь прочих розеток она не влияет (отсутствие иерархии).
В случае же с автомобилем, то отказ двигателя превращает весь автомобиль в тыкву (наличие иерархии).
Вам выше уже указали, что основная ваша сложность — это неспособность разделить когда именно монолит может состоять более чем из одной части и продолжать быть монолитом
Нас не интересует разомкнутая цепь или нет. Равно как и с кем там общается данная конкретная розетка.
Для внешнего мира она представляет рабочий интерфейс доступа к электрической сети.
Эта электрическая сеть может быть и 110 и 220, постоянного или переменного тока — для розетки в целом не суть важно.
Она либо выполняет свою функцию, либо не выполняет. На жизнь прочих розеток она не влияет (отсутствие иерархии).
В случае же с автомобилем, то отказ двигателя превращает весь автомобиль в тыкву (наличие иерархии).
Вам выше уже указали, что основная ваша сложность — это неспособность разделить когда именно монолит может состоять более чем из одной части и продолжать быть монолитом
Нас не интересует разомкнутая цепь или нет. Равно как и с кем там общается данная конкретная розетка.
Интересует. Розетки без приборов — это аналог Kubernetes без микросервисов. Мы же говорим не об этом.
Она либо выполняет свою функцию, либо не выполняет. На жизнь прочих розеток она не влияет (отсутствие иерархии).
Да ну, серьёзно? А у Вас никогда не вырубались сразу все приборы от включения, например, стиральной машины? Точно не влияет на другие?
В случае же с автомобилем, то отказ двигателя превращает весь автомобиль в тыкву (наличие иерархии).
Не смогу даже свет включить в нём? А окно открыть? Или даже с парой силачей отогнать на обочину, т. е. колёса не смогут выполнять свою функцию? А датчики показывать будут скорость, с которой машину толкают? А ручной тормоз тоже работать не будет, то есть она даже стоять не сможет? Или всё-таки не работает только двигатель, а остальные части автомобиля работают?
Захотели мы сделать из этого самосвала карьерного, электромобиль. Современно, экономно и т.п.
Что же нам делать?
А точно! Выкинуть двигатель, выкинуть топливную систему (или просто забить на нее), выкинуть коробку и т.д.
Ну можно не выкидывать, т.к. на это слишком много времени уйдет.
Давайте просто в кузов кинем кучу аккумуляторов и прихерачим как то двигатель к оси. Старое пусть остается, может не помешает. Подумаешь тяжело, прорвемся.
Заводим… не завелось. Давай копаться.
Блин, ось то подсоединена к старой системе. Давай откручивать.
Открутили, заводим и… да чтож такое.
Пока откручивали, повредили связь между электродвигателем и осью.
…
…
…
Примерно так происходит с монолитами, особенно если они оч. крупные.
Что же нам делать?
А точно! Выкинуть двигатель, выкинуть топливную систему (или просто забить на нее), выкинуть коробку и т.д.
Ну можно не выкидывать, т.к. на это слишком много времени уйдет.
Давайте просто в кузов кинем кучу аккумуляторов и прихерачим как то двигатель к оси. Старое пусть остается, может не помешает. Подумаешь тяжело, прорвемся.
Заводим… не завелось. Давай копаться.
Блин, ось то подсоединена к старой системе. Давай откручивать.
Открутили, заводим и… да чтож такое.
Пока откручивали, повредили связь между электродвигателем и осью.
…
…
…
Примерно так происходит с монолитами, особенно если они оч. крупные.
Примерно так происходит с монолитами, особенно если они оч. крупные.
Да.
Если вы не знаете/не умеете/не следуете принципам SOLID/«Чистой архитектуры».
В монолите шансы на большую непонятно как работающую штуковину гораздо больше, чем в микросервисах.
Сложность никуда не исчезает.
Просто вместо одного большого непонятного комка получаем комок непонятных связей.
Монолит может сильно ограничивать проект в плане добавления новых возможностей (микросервисы уже автоматически декомпозированы).
Вы считаете, что любая декомпозиция — это благо?
А что если декомпозированы неправильно, где будет легче исправить? Думаете переписать несколько микросервисов будет легче?
А что если декомпозированы неправильно, где будет легче исправить? Думаете переписать несколько микросервисов будет легче?
Думаю, что можно будет сделаю прослойку абстракции для API, а переписывать по мере надобности. Весь проект будет переписать тяжелее, в любом случае.
И, думаю, не стоит рассматривать случай, когда декомпозиция была неправильной по той причине, что делалась начинающими программистами? Там в обоих случаях всё плохо будет.
Думаю, что можно будет сделаю прослойку абстракции для API
Не поможет.
Если вам для получения данных придется делать JOIN между микросервисами (а это пример кривой композиции) — производительность будет страдать неимоверно.
И, думаю, не стоит рассматривать случай, когда декомпозиция была неправильной по той причине, что делалась начинающими программистами?
Не боги горшки обжигают.
Это самые обычные программисты. И миддлы и сеньоры.
Вообще в ММО сервера плодят путем копирования «Эталонного» сервера на виртуалки в нужном количестве. Ну плюс какойнить простенький скрипт, который «Донастраивает» такие сервера при запуске (Задаёт имя сервера или ещё чего).
Комикс классный. И про гугл правильно. На такого вендора завязываться — путь к финансовым проблемам.
Кто в курсе, что в кубернетисе с персистентностью сейчас?
Реально что-то сохранить без базы? Куда?
Кто в курсе, что в кубернетисе с персистентностью сейчас?
Реально что-то сохранить без базы? Куда?
Браво!!!
Вкусовщина
за контент ничего сказать не могу — не читал
но от рисовки глазки бо-бо
никто не ждет уровня Оды или Кишимото
но на том же www.webtoons.com/en овермного очень юных авторов рисуют прям супер кайфово
но от рисовки глазки бо-бо
никто не ждет уровня Оды или Кишимото
но на том же www.webtoons.com/en овермного очень юных авторов рисуют прям супер кайфово
2014 — 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
2016 — We must adopt #docker to solve all problems with microservices.
2018 — We must adopt #kubernetes to solve all problems with docker
Действительно, почем Афина выглядит как «малолетняя косплеерша»?) Если предположить, что в любых комиксах, объясняющих преимущества чего-либо на пальцах, используются герои, создающие максимально положительный образ этого продукта, то опять же, почему она ребенок? Хмммм...)
Афина как олицетворение микросервисов:
— Относительно молода.
— Выглядит божественно.
— Энтузиазм новичка, который проглотил маркетинговый материал, и возможно, успел попользовать на какие то тестовых проектах с положительным результатом.
— Не участвовала в реальных боях в проде, когда война идет годами, а сервисов и их разнообразия — легион. Поэтому нет шрамов и взгляда смотрящего сквозь ничтожность бытия.
— Относительно молода.
— Выглядит божественно.
— Энтузиазм новичка, который проглотил маркетинговый материал, и возможно, успел попользовать на какие то тестовых проектах с положительным результатом.
— Не участвовала в реальных боях в проде, когда война идет годами, а сервисов и их разнообразия — легион. Поэтому нет шрамов и взгляда смотрящего сквозь ничтожность бытия.
Sign up to leave a comment.
Легкое плавание с Kubernetes (комикс)