Знакомо.
Слежу за новостями фронтэнда по вершкам иногда что-то пробую, в какой-то зыбкой надежде применить это в каком-нибудь проекте…
Но в реальности все время занят архитектурой и бэкэндами ;)
Странная статья…
Создаете контейнерный кластер руками вместо того что-бы его терраформом и создать…
Терраформ просто идеален иммено для описания инфраструкутры, в вашем случае той инфрастукуры на которой будер развернут kubernetes.
Это меняется сейчас. ктомуже очень зависить от фирмы… Более старые фирмы и "традиционные" да! Но нпример в Берлине уже все достаточно интернационально.
В Гамбурге, Франкфурте и Мюнхене тоже можно найти фирмы которые вполне. Но это дорогие Города и зарплата в 60 должна быть минимум ИМХО.
Вы поняли как вам это хотелось…
Да синхронизация через базу даных это самообман и антипэттерн.
Я поясню и так. Мы написали олколо 10 новых сервисов, делающих тоже самое что старый монолит, но посколько мы изначально думали о том что такое "shared state".
Все они имеют кой-то стейт и это не проблема. Проблема возникает если вы вдруг водите "shared state" и считаете что именно так и никак иначе в вашей архитектуре быть не может.
Конечно это зависит от задачь, но я в работл во многих индустриях и проблемы на самом деле обысчно очень похоже… И я почти уверен что распределенный стейт можно локализировать и особо к нему подойти. В этом то и ошибка многих команд, что к нему не достаточно внимания.
Давайте конкретенее… Вот раньше сесси на стороне сервиса/сервера были проблемой, сечас сессионый статус держит клиент — и это очень элегантный выход из моних ситуаций…
Мы используем еще внешние системы которы звонятнаам по колбэкам. В одном случае мы встроили наш ключ в callback url в данном случает хэто позволяет полностью избежать знание о друг други или общис стейт между звонящим и принимающим звонок сервис.
Хорошо вы скажете а как же вы будете скалировать ваш User data сервис… ну очень надо 10 инстанций… Тут вот и есть вопрос загнанного в угл "shared state".
И тут вы может епринять решения.
Ответьте себе на впрос вам дейтвительно нужно ACID или вполне достачно BASE.
Вообще-то в реальная жизнь тоже поххоже на BASE и на событийную архитектуру…
Если каждая инстанция сервиса имеет свою наиболее актуальную версию стейта, но без гарантии — это BASE и это отлично скалиерует. С паттернами Event Sourcing и CQRS вообще открываются очень интересные возможности.
А если вы уверены что вам нуже только ACID и только он — ну да это не скалирует…
Но может вы говорите о кластере сервисов которы в волатильной памяти должны держать "shared state", бывает и такие задачи, но тут возникаакуут вопрос, что именно это за стейт? Может это просто кэш? возмите что-то готовое, есть кучу решений…
Я вот очень сильно хотел бы прочитать о вашем примере…
Но и на это случай полно очень продуманых штук от навароченых библиотек Apache Ignite до простых распределенных примитивом или реализаций протоколов выбора лидера… — Но оно вам надо? моя практика показвыет что обычно это идет в бой когда девелоперы хотят поробовать новые штуки а не когда это действительно нужно и без это-го никак.
Совершенно верно "стейт" — это сложно и затратно. Но набив руку вы не сядите в лужу…
Если вы строите чтп-то новое, то все карты в руки.
Задача сводится к отдалению "стейта" например туда где эго мэнджмент уже решон, например нормально настроеная NoSQL.
Есть мног итнересных паттернов… и возможностей избежать сейта или жить с его не синхроными копийми или или или..
П.С. за последний год переписал часть одной легаси системы. Около 10 новых микросервисов, пока только один со стейтом и не скалируется, то такой мощный что его хватит на 100% рот нашего лоада…
а главнео мы когда этотот 100% лоад достигнем и стнем лиллионерами :) просто заменим этот сервис за пру спринтов.
Я вот замечаю что его больше и больше внедряют в продакшн.
k8s гораздо распространненей сворма. А гугл его как продукт в своейм облаке предлагает… из коробки.
А в kubernetes не так?
не так.
PS Вы постоянно подчеркиваете что Kubernetes это абстракция. А много ли контейнерных движков вы знаете, что нужна абстракция?
Абстракция от того где это все будет бежать полезна без того что-бы без того что-бы стравнивать движки...
Ну и как-бы ваша аргументаци о том что вы любите и что вам нравится…
Любите заниматься вопросами настройки кластера? — какие проблемы… Я вовсе не сказал что докер сворм плохой.
ими можно уже на уровне кластера управлять? а не на конкретной машине?
Load balancing идет из коробки
Вообщето это обширная тема. Из коробки там по портам. Если просто называть сущности.то никуда не придем ;)
LB есть и там и там
Scheduling есть и там и там
Persintance есть и там и там..
Dockre-Flow haproxy
Сторонние инструменты можно и с k8s использовать… Не аргумент. Да и костыль это например если интегрировать в ресурсе предостовлямые клауд-провайдерарами а k8s какраз под них заточен. и модули написаные под него абстрагируйту такие вещи. Это фишка дизйна…
Сворм похоже и не стремится туда..
Плюс по поводу Kubrnetes у меня большие опасения. Это вендор лок, на этом самом Kubernetes. Swarm использует механизмы которые есть в докере. Что будет если Swarm победит? Вы привязаны к legacy технологии.
Тут какраз все упорекают докер что это вендор лок ;)
k8s какраз и сторит все абстракцие которы могут быть реализованны где угодно и на чем угодно, вы многие компоненты можете выкинутЭи заменить, включая сам докер. А сворм это какраз больше на легаси похоже, потому что пытается быть минималистичным (что хорошо).
k8s преподносит себя как платформа, вот линукс с башем — тоже же вендор лок своебразный.
Что будет если Swarm победит?
swarm пока проигрывет очень в плане распространенности и поддержке, да и сырости.
Нет докер абстрагирует только процесс на ядре линукс (с разными плюшками конечно) на одной машине.
Сворм добавляет новую абстракцию, мы абстрагируемся от конкретной машины и деплоим в кластер тут у нас конечно и k8s он тоже это делает. Делают они это по разному и по своему интересно и поэтому мне оба интересны хоть и знаком поверхностно.
Но в k8s все немного шире. Особенно со стораджем (где конечно до сих пор не все гладко), но достаточно посмотреть список все-го того что можно подключить и как хорошо ИМХО это подлючение абстрагированно от деталей самих технологий. https://kubernetes.io/docs/concepts/storage/persistent-volumes/
Или такая штука как igress которая если я правильно помню гораздо шире того, что предлагает sworm, где к сервису просто порт открывается и мэпится виртуально через кластер.
В k8s igress позволяет в большей степени не думать о нодах, сети (на до кибернетовском уровне) а перед sworm если не путаю надо сначало заглушку поставить если не хотите сервисы из кластера делать доступными по портам, не говоря уже о балансировке по путям, TLS и т.д.
И так во многом.
Не совсем понятно зачем быть не зависимым от докера. Он все равно под капотом. Лично мне приятнее использовать нативные инструменты.
Ну я же говорю это зависит от… Я к примеру тоже люблю.
С k8s вы не заморачиваетесь с тем где это все бежит. При случае можно и сменить все под k8s. Для больших и очень больших проектов это становится очень важно и не только по соображениям то-го что мы тоеоритически можем поменять облако, а скорее в более общем плане, как создание, абстркций — которые становятся технологически независимым стандартом.
В маленьком проекте может гораздо выжнее совсем другие вещи, как мотивация, одного девелопера ;)
Вот я в все пили свой частный проектик по ночам и там смотрю тоже на swarm но еще не решился.
и на данным момент не сильно функциональнее сварма
Kubernetes немного дальше в например с той же интеграцией стораджа…
Ну и сама API не завязана на докер, это конечно как плюсы и минус можно видеть. Минус в сложности, так как ко всему есть абстракции, их надо один раз понять. Но зато, поняв их, вы становитесь независимы от сущностей облака или железа на которм бежит k8n. Как-бы принцип Контеэнров но в более широком смысле.
Со swarm пока больше возни в этом плане, но похоже с LinuxKit они тоже как-то по своему решают вопрос с абстракциями — IMHO пока слишком омбизиозный ( не совсем мне понятный) подход. Я бы сказал с k8n на данный момент не ошибится, он просто популярнее и активнее поддерживается (включая крупных игроков).
Но если есть/желание и возможность то и swarm надо иногда щупать
Мне кажется это персекаетася с DaaS Directory as a Service
Посмотрите на jumpcloud.com. Помоему очень интересный продукт, если не проблема доверять им все эти данные.
Фактически именно это интересно когда у вас есть внешний LDAP Server с плюшками. В таком случае не надо самому вводить в виде Active Directory (дефакто стандарт во многих регионах мира для подобных задач), супер интересно для небольших стартапов.
Интересная тема. На вскидку не нагуглил ничего о том можно ли ейто как-то привязать к AWS ECS. Было бы помоему очень полезно ибо из коробки у ECS куча недоделок в этом направлении
Знакомо.
Слежу за новостями фронтэнда по вершкам иногда что-то пробую, в какой-то зыбкой надежде применить это в каком-нибудь проекте…
Но в реальности все время занят архитектурой и бэкэндами ;)
Мне кажтся абривеатура SOA здесь только мешает так как вызывет гораздо более привычне к ней ассоциации SOA (service-oriented architecture)
Странная статья…
Создаете контейнерный кластер руками вместо того что-бы его терраформом и создать…
Терраформ просто идеален иммено для описания инфраструкутры, в вашем случае той инфрастукуры на которой будер развернут kubernetes.
Это меняется сейчас. ктомуже очень зависить от фирмы… Более старые фирмы и "традиционные" да! Но нпример в Берлине уже все достаточно интернационально.
В Гамбурге, Франкфурте и Мюнхене тоже можно найти фирмы которые вполне. Но это дорогие Города и зарплата в 60 должна быть минимум ИМХО.
Спасибо.
А можно прилить свет побольше на то кто и зачем это использует?
Что можно послать как сообщение к примеру? Документ, Файл можно или только текст?
Спасибо. Глянул бегло, выглядит интересно. буду пробовать
Да, это типа стандарт. Чем-то оттолкнуло меня в начале… Но думаю гляну опять на днях.
Вы поняли как вам это хотелось…
Да синхронизация через базу даных это самообман и антипэттерн.
Я поясню и так. Мы написали олколо 10 новых сервисов, делающих тоже самое что старый монолит, но посколько мы изначально думали о том что такое "shared state".
Все они имеют кой-то стейт и это не проблема. Проблема возникает если вы вдруг водите "shared state" и считаете что именно так и никак иначе в вашей архитектуре быть не может.
Конечно это зависит от задачь, но я в работл во многих индустриях и проблемы на самом деле обысчно очень похоже… И я почти уверен что распределенный стейт можно локализировать и особо к нему подойти. В этом то и ошибка многих команд, что к нему не достаточно внимания.
Давайте конкретенее… Вот раньше сесси на стороне сервиса/сервера были проблемой, сечас сессионый статус держит клиент — и это очень элегантный выход из моних ситуаций…
Мы используем еще внешние системы которы звонятнаам по колбэкам. В одном случае мы встроили наш ключ в callback url в данном случает хэто позволяет полностью избежать знание о друг други или общис стейт между звонящим и принимающим звонок сервис.
Хорошо вы скажете а как же вы будете скалировать ваш User data сервис… ну очень надо 10 инстанций… Тут вот и есть вопрос загнанного в угл "shared state".
И тут вы может епринять решения.
Ответьте себе на впрос вам дейтвительно нужно ACID или вполне достачно BASE.
Вообще-то в реальная жизнь тоже поххоже на BASE и на событийную архитектуру…
Если каждая инстанция сервиса имеет свою наиболее актуальную версию стейта, но без гарантии — это BASE и это отлично скалиерует. С паттернами Event Sourcing и CQRS вообще открываются очень интересные возможности.
А если вы уверены что вам нуже только ACID и только он — ну да это не скалирует…
Но может вы говорите о кластере сервисов которы в волатильной памяти должны держать "shared state", бывает и такие задачи, но тут возникаакуут вопрос, что именно это за стейт? Может это просто кэш? возмите что-то готовое, есть кучу решений…
Я вот очень сильно хотел бы прочитать о вашем примере…
Но и на это случай полно очень продуманых штук от навароченых библиотек Apache Ignite до простых распределенных примитивом или реализаций протоколов выбора лидера… — Но оно вам надо? моя практика показвыет что обычно это идет в бой когда девелоперы хотят поробовать новые штуки а не когда это действительно нужно и без это-го никак.
Совершенно верно "стейт" — это сложно и затратно. Но набив руку вы не сядите в лужу…
Если вы строите чтп-то новое, то все карты в руки.
Задача сводится к отдалению "стейта" например туда где эго мэнджмент уже решон, например нормально настроеная NoSQL.
Есть мног итнересных паттернов… и возможностей избежать сейта или жить с его не синхроными копийми или или или..
П.С. за последний год переписал часть одной легаси системы. Около 10 новых микросервисов, пока только один со стейтом и не скалируется, то такой мощный что его хватит на 100% рот нашего лоада…
а главнео мы когда этотот 100% лоад достигнем и стнем лиллионерами :) просто заменим этот сервис за пру спринтов.
Ну и как-бы ваша аргументаци о том что вы любите и что вам нравится…
Любите заниматься вопросами настройки кластера? — какие проблемы… Я вовсе не сказал что докер сворм плохой.
ими можно уже на уровне кластера управлять? а не на конкретной машине?
Вообщето это обширная тема. Из коробки там по портам. Если просто называть сущности.то никуда не придем ;)
LB есть и там и там
Scheduling есть и там и там
Persintance есть и там и там..
Сторонние инструменты можно и с k8s использовать… Не аргумент. Да и костыль это например если интегрировать в ресурсе предостовлямые клауд-провайдерарами а k8s какраз под них заточен. и модули написаные под него абстрагируйту такие вещи. Это фишка дизйна…
Сворм похоже и не стремится туда..
Тут какраз все упорекают докер что это вендор лок ;)
k8s какраз и сторит все абстракцие которы могут быть реализованны где угодно и на чем угодно, вы многие компоненты можете выкинутЭи заменить, включая сам докер. А сворм это какраз больше на легаси похоже, потому что пытается быть минималистичным (что хорошо).
k8s преподносит себя как платформа, вот линукс с башем — тоже же вендор лок своебразный.
swarm пока проигрывет очень в плане распространенности и поддержке, да и сырости.
Нет докер абстрагирует только процесс на ядре линукс (с разными плюшками конечно) на одной машине.
Сворм добавляет новую абстракцию, мы абстрагируемся от конкретной машины и деплоим в кластер тут у нас конечно и k8s он тоже это делает. Делают они это по разному и по своему интересно и поэтому мне оба интересны хоть и знаком поверхностно.
Но в k8s все немного шире. Особенно со стораджем (где конечно до сих пор не все гладко), но достаточно посмотреть список все-го того что можно подключить и как хорошо ИМХО это подлючение абстрагированно от деталей самих технологий.
https://kubernetes.io/docs/concepts/storage/persistent-volumes/
Или такая штука как igress которая если я правильно помню гораздо шире того, что предлагает sworm, где к сервису просто порт открывается и мэпится виртуально через кластер.
В k8s igress позволяет в большей степени не думать о нодах, сети (на до кибернетовском уровне) а перед sworm если не путаю надо сначало заглушку поставить если не хотите сервисы из кластера делать доступными по портам, не говоря уже о балансировке по путям, TLS и т.д.
И так во многом.
Ну я же говорю это зависит от… Я к примеру тоже люблю.
С k8s вы не заморачиваетесь с тем где это все бежит. При случае можно и сменить все под k8s. Для больших и очень больших проектов это становится очень важно и не только по соображениям то-го что мы тоеоритически можем поменять облако, а скорее в более общем плане, как создание, абстркций — которые становятся технологически независимым стандартом.
В маленьком проекте может гораздо выжнее совсем другие вещи, как мотивация, одного девелопера ;)
Вот я в все пили свой частный проектик по ночам и там смотрю тоже на swarm но еще не решился.
да. ;)
Kubernetes немного дальше в например с той же интеграцией стораджа…
Ну и сама API не завязана на докер, это конечно как плюсы и минус можно видеть. Минус в сложности, так как ко всему есть абстракции, их надо один раз понять. Но зато, поняв их, вы становитесь независимы от сущностей облака или железа на которм бежит k8n. Как-бы принцип Контеэнров но в более широком смысле.
Со swarm пока больше возни в этом плане, но похоже с LinuxKit они тоже как-то по своему решают вопрос с абстракциями — IMHO пока слишком омбизиозный ( не совсем мне понятный) подход. Я бы сказал с k8n на данный момент не ошибится, он просто популярнее и активнее поддерживается (включая крупных игроков).
Но если есть/желание и возможность то и swarm надо иногда щупать
Мне кажется это персекаетася с DaaS Directory as a Service
Посмотрите на jumpcloud.com. Помоему очень интересный продукт, если не проблема доверять им все эти данные.
Фактически именно это интересно когда у вас есть внешний LDAP Server с плюшками. В таком случае не надо самому вводить в виде Active Directory (дефакто стандарт во многих регионах мира для подобных задач), супер интересно для небольших стартапов.
Для кафки интересно
Интересная тема. На вскидку не нагуглил ничего о том можно ли ейто как-то привязать к AWS ECS. Было бы помоему очень полезно ибо из коробки у ECS куча недоделок в этом направлении
Оффигеть увеличеная плотность процессов на железе ведет к большему потребленю энергии? ;) Дык радоваться надо ;)