Да не тот критерий на который наверно стоит много завязывать.
Но! Скорось старта важна по двум основым причинам..
Если писать на этом (микро)сервисы которые "дышат"… (Стартуются при пиках нагрузки и убиваются при малой), да и просто могут упасть не вовремя — скорость старта важнецкая вещь. К томуже есть такие команды, которые выкатывают приложени несколько раз в день в продакшн… (Да JEE в/для другой реальности писался я в курсе).
Feedback-цыкл быстрее в том случае если сервер стартует на машине разработчика или в автоматизированных тестах...
Киллер фича в моем понимании это то, что кафка и не брокер в классическом смылсе это распределнный Log или по русски может быть я назвал бы точнее "распределенное хранение событий".
Тут переосмыслен сам это Log. Клиенты сами ведут учет какое сообщение они получили а какое нет. Вам вообще можно ничего не стирать, лог остается не изменненый, можете прочитать заного событие из 2014-го года…
Это все скалирует очень хорошо конечно… А главное это дает возможность переосмыслить архитекртуры, и внедрить EventSourcing и CQRS.
Но статья совершенно не об этом… Поэтому сравнения с Раббитом уместны и правильны.
Ок, тогда я вас не совсем понял, показалось что без logstash хотели…
Может тогда и вторая часть не совсем вам, но:
как же не парсить то, logstash этим то и занимается, парсит стринг и пишет в документ с соотвествующими полями…
И тут вам наверняка могут понадобится какие-то специфические поля, например id каких-то вещей. Вы можете начать выделять определенные события возможно с аттрибутами, тут можно много напарзить и важно подготовить правильно поля… Ну и представьте банальную реальность, все это просто не на greenfield а на легаси системе, с сервисами которые уже давно никто не ковырял и он даже не Loj4J2 логит.
А так же ИМХО вся фишка с ELK же в том, что вы свои логи можете отслеживать начиная "с клика по ссылке" и заканчивания вызовом како-го-то жесткого легаси или third party, вы строите логи абстрагируя от технологий, все логи и весь анализ в одном месте… В таком случае не только на log4j2, да и на java-сервисы замыкаться, многое терять..
А что если кластере капризнул и отказал принять ваши логи (это вполен нормально, ES не база данных и в стандарном виде скорее на чтение заточен чем на индексахию, да и при заточке, все бывает)… Вы напишете логику повтора после некторой задержки тоже сами?
Али что делать сели после написания 25-го сервиса всетаки решили немного переделать модель домента логов или просто новый индех создать, полезете править 25- боевых сервисов и передеплоить?
Знакомо.
Слежу за новостями фронтэнда по вершкам иногда что-то пробую, в какой-то зыбкой надежде применить это в каком-нибудь проекте…
Но в реальности все время занят архитектурой и бэкэндами ;)
Странная статья…
Создаете контейнерный кластер руками вместо того что-бы его терраформом и создать…
Терраформ просто идеален иммено для описания инфраструкутры, в вашем случае той инфрастукуры на которой будер развернут 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 но еще не решился.
Да не тот критерий на который наверно стоит много завязывать.
Но! Скорось старта важна по двум основым причинам..
Киллер фича в моем понимании это то, что кафка и не брокер в классическом смылсе это распределнный Log или по русски может быть я назвал бы точнее "распределенное хранение событий".
Тут переосмыслен сам это Log. Клиенты сами ведут учет какое сообщение они получили а какое нет. Вам вообще можно ничего не стирать, лог остается не изменненый, можете прочитать заного событие из 2014-го года…
Это все скалирует очень хорошо конечно… А главное это дает возможность переосмыслить архитекртуры, и внедрить EventSourcing и CQRS.
Но статья совершенно не об этом… Поэтому сравнения с Раббитом уместны и правильны.
Ок, тогда я вас не совсем понял, показалось что без logstash хотели…
Может тогда и вторая часть не совсем вам, но:
как же не парсить то, logstash этим то и занимается, парсит стринг и пишет в документ с соотвествующими полями…
И тут вам наверняка могут понадобится какие-то специфические поля, например id каких-то вещей. Вы можете начать выделять определенные события возможно с аттрибутами, тут можно много напарзить и важно подготовить правильно поля… Ну и представьте банальную реальность, все это просто не на greenfield а на легаси системе, с сервисами которые уже давно никто не ковырял и он даже не Loj4J2 логит.
А так же ИМХО вся фишка с ELK же в том, что вы свои логи можете отслеживать начиная "с клика по ссылке" и заканчивания вызовом како-го-то жесткого легаси или third party, вы строите логи абстрагируя от технологий, все логи и весь анализ в одном месте… В таком случае не только на log4j2, да и на java-сервисы замыкаться, многое терять..
А что если кластере капризнул и отказал принять ваши логи (это вполен нормально, ES не база данных и в стандарном виде скорее на чтение заточен чем на индексахию, да и при заточке, все бывает)… Вы напишете логику повтора после некторой задержки тоже сами?
Али что делать сели после написания 25-го сервиса всетаки решили немного переделать модель домента логов или просто новый индех создать, полезете править 25- боевых сервисов и передеплоить?
Тесла разве что косвенно за счет господдержки
Ну за kubernetes я в курсе. Оттого и спрашивал какое решение у ребят на этот счет…
Да и статейке уже как год. Много чего произошло в этих технологиях.
Знакомо.
Слежу за новостями фронтэнда по вершкам иногда что-то пробую, в какой-то зыбкой надежде применить это в каком-нибудь проекте…
Но в реальности все время занят архитектурой и бэкэндами ;)
Мне кажтся абривеатура 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 но еще не решился.