и на данным момент не сильно функциональнее сварма
Kubernetes немного дальше в например с той же интеграцией стораджа…
Ну и сама API не завязана на докер, это конечно как плюсы и минус можно видеть. Минус в сложности, так как ко всему есть абстракции, их надо один раз понять. Но зато, поняв их, вы становитесь независимы от сущностей облака или железа на которм бежит k8n. Как-бы принцип Контеэнров но в более широком смысле.
Со swarm пока больше возни в этом плане, но похоже с LinuxKit они тоже как-то по своему решают вопрос с абстракциями — IMHO пока слишком омбизиозный ( не совсем мне понятный) подход. Я бы сказал с k8n на данный момент не ошибится, он просто популярнее и активнее поддерживается (включая крупных игроков).
Но если есть/желание и возможность то и swarm надо иногда щупать
Мне кажется это персекаетася с DaaS Directory as a Service
Посмотрите на jumpcloud.com. Помоему очень интересный продукт, если не проблема доверять им все эти данные.
Фактически именно это интересно когда у вас есть внешний LDAP Server с плюшками. В таком случае не надо самому вводить в виде Active Directory (дефакто стандарт во многих регионах мира для подобных задач), супер интересно для небольших стартапов.
Интересная тема. На вскидку не нагуглил ничего о том можно ли ейто как-то привязать к AWS ECS. Было бы помоему очень полезно ибо из коробки у ECS куча недоделок в этом направлении
Может быть мы о разном. Давайте разбираться…
Все серивисы подписаны на кафку и имеют локальные копи (снэпшоты, кеши и т.д.) так как им удобно… Они могут вести свои собственные базы данных NoSQL и прочую организацию для исполнения задачи. Им не нужно совершенно прочесывать кавку.
Кавка остается "универсальной правдой" потоком событий (или фактов). Сервисы подписаны на кафку и лишь слушают изменения и актуализируют свое сотояние.
Допустим у вас 250 сервисов… я не совсем понял как они слушают и кого? Раббита? или постоянно ходят в базу данных что-бы забрать новые эвенты? Не говороя уже о не скалиремости релациональной БД не понимаю даже приемущества ДБ+раббит супротив кавки начиная с систем не помещающихся на 3 хоста
В том примере Постгри какраз второстепенен. Ничего не попадет ни в какие базы данных никаких серверов кроме как через кафку. И кафка единственнай правда остальное получается снэпшоты и кеши.
Ну самое тривиальное упращение: берем актуальный в каую-то секунду статус из базы данных и импортируем в новую ситему. Теоритичеки тривиально…
А на практике новая система может быть вовсе не понимать SQL и надо думать о трансформации и реализовывать её, причем может надо избежать даунтайм.
Далее одна система с которой мне приходится возится, несмотря на то что она достаточно легаси, построена на нескольких базах данных которые несут распределенно статус и историю. Некоторые пишут по 2 миллиона событий в день. Одна только синхронизация такого експорта/импрота в новую систему не тривиальна как мне представляется из опыта.
Вы работаете с SQL это конечно упрощает но в случае вышеупомянутой системы, было бы в нашем случае не целесобразно, потому что железо для такой SQL машины стоило бы непомерно… Да и зачем когда вся фишка вроде как в специализированых решения как кафка. Мне бы очень хотелось пощупать это ;)
Не зависимо от импорта, если я дальше думаю о вышеупомянутой системе, присутствует условие стирания событий назовем их Messages (законы просто не позволяют долго хронить определнню информацию) и в даже в новой системе эти события придется стирать, что не предусмотренно в описанном подходе в принципе если я правильно понимаю.
Я об этом же. Но это не тивирально может быть. Например если уже есть некая история.
P.S. У вас с Кафкой опыт есть? Я так понимаю именно для это-го он подходит?
Отличная статья, большое спасибо! В закладки!
Поговорить о деталях видимо может быть уместным только попробовав на практике… Пока у меня небыло подобного опыта в полном обьеме хотя писать эвенты вместа апдейта статуса уже догадывались под разным причинам ;)
Интересует такой момент. В описаной вамеи связке Event Sourcing + CORS события имеет смысл класть в какое-то хранилище (Event Bus).
Вы вначале статьи написали о Кафке и похоже именно на неё намекаете, (я именно в таком контексте слышал о кафке). Могли бы вы побольше пролить свет о роли кафки или другого хранилища?
И правильно ли я понял что при наличии надежного хранилища событий, в идеале его можно сделать единственным и эксклюзивным хранилищем всей истории событий?
Даный подход открывает невероятное возможности в динамике конзумирующих сервисов в таком случае, что очень интересно.
П.С.
А при переходе на таку модель с чего-то исторического, надобно существующий статус как-то перевести в начальные события, что-бы отчего-то оталкиватся, без потери информации и возможнои истории, что может быть тоже не тривиально совершенно..
А родной aws cli сильно тормозит? Через него можно получить логи в json формате, на ходу можно pipe-ить в читалку json-a и оттуда уже пайпить в slit либо куда душа пожелает
Месяца 3 назад бегло пробовал. Да тормозило сильно…
Но можно посерьезнее постмотреть и хитро пайпить… это верно.
papertrail
да именно к нему присмариваюсь в часном проекте… Но на фирме там разные сложные констрейны с банковскими клиентами. так просто уйти в следующий клауд сервис да еще с логами не реально пока ;))
Простите я бы хотел попробовать ваш тул. Но пока мы логим в CloudWatch только и смотрим там ( Хватает, но те кто привыкли к копаться в логах недовольны...)
Не посоветуете что-то не тормозящее что может выкичивать из CloudWatch напрямую или переброс в S3 это стандартных подход к вопросу? Если да то как это делают?
которая предоставляет в пользовательском окружении следующие файлы:
/proc/cpuinfo
список CPU
/proc/diskstats
статистика I/O в контейнере
/proc/meminfo
доступная контейнеру память и статистика по использованию
/proc/stat
статистика по доступным CPU
/proc/swaps
статистика по swap
/proc/uptime
uptime контейнера.
Простите а виртуальная машина явы именно на них смотрит при планировании ресурсов?
да. ;)
Kubernetes немного дальше в например с той же интеграцией стораджа…
Ну и сама API не завязана на докер, это конечно как плюсы и минус можно видеть. Минус в сложности, так как ко всему есть абстракции, их надо один раз понять. Но зато, поняв их, вы становитесь независимы от сущностей облака или железа на которм бежит k8n. Как-бы принцип Контеэнров но в более широком смысле.
Со swarm пока больше возни в этом плане, но похоже с LinuxKit они тоже как-то по своему решают вопрос с абстракциями — IMHO пока слишком омбизиозный ( не совсем мне понятный) подход. Я бы сказал с k8n на данный момент не ошибится, он просто популярнее и активнее поддерживается (включая крупных игроков).
Но если есть/желание и возможность то и swarm надо иногда щупать
Мне кажется это персекаетася с DaaS Directory as a Service
Посмотрите на jumpcloud.com. Помоему очень интересный продукт, если не проблема доверять им все эти данные.
Фактически именно это интересно когда у вас есть внешний LDAP Server с плюшками. В таком случае не надо самому вводить в виде Active Directory (дефакто стандарт во многих регионах мира для подобных задач), супер интересно для небольших стартапов.
Для кафки интересно
Интересная тема. На вскидку не нагуглил ничего о том можно ли ейто как-то привязать к AWS ECS. Было бы помоему очень полезно ибо из коробки у ECS куча недоделок в этом направлении
Оффигеть увеличеная плотность процессов на железе ведет к большему потребленю энергии? ;) Дык радоваться надо ;)
Может быть мы о разном. Давайте разбираться…
Все серивисы подписаны на кафку и имеют локальные копи (снэпшоты, кеши и т.д.) так как им удобно… Они могут вести свои собственные базы данных NoSQL и прочую организацию для исполнения задачи. Им не нужно совершенно прочесывать кавку.
Кавка остается "универсальной правдой" потоком событий (или фактов). Сервисы подписаны на кафку и лишь слушают изменения и актуализируют свое сотояние.
Допустим у вас 250 сервисов… я не совсем понял как они слушают и кого? Раббита? или постоянно ходят в базу данных что-бы забрать новые эвенты? Не говороя уже о не скалиремости релациональной БД не понимаю даже приемущества ДБ+раббит супротив кавки начиная с систем не помещающихся на 3 хоста
В том примере Постгри какраз второстепенен. Ничего не попадет ни в какие базы данных никаких серверов кроме как через кафку. И кафка единственнай правда остальное получается снэпшоты и кеши.
Кафка подходит. Хотя на мой вкус немного радикальное решение но этим то и интересно.
Вот тут очень хорошо описано с поянениями в каментах:
Ну самое тривиальное упращение: берем актуальный в каую-то секунду статус из базы данных и импортируем в новую ситему. Теоритичеки тривиально…
А на практике новая система может быть вовсе не понимать SQL и надо думать о трансформации и реализовывать её, причем может надо избежать даунтайм.
Далее одна система с которой мне приходится возится, несмотря на то что она достаточно легаси, построена на нескольких базах данных которые несут распределенно статус и историю. Некоторые пишут по 2 миллиона событий в день. Одна только синхронизация такого експорта/импрота в новую систему не тривиальна как мне представляется из опыта.
Вы работаете с SQL это конечно упрощает но в случае вышеупомянутой системы, было бы в нашем случае не целесобразно, потому что железо для такой SQL машины стоило бы непомерно… Да и зачем когда вся фишка вроде как в специализированых решения как кафка. Мне бы очень хотелось пощупать это ;)
Не зависимо от импорта, если я дальше думаю о вышеупомянутой системе, присутствует условие стирания событий назовем их Messages (законы просто не позволяют долго хронить определнню информацию) и в даже в новой системе эти события придется стирать, что не предусмотренно в описанном подходе в принципе если я правильно понимаю.
Я об этом же. Но это не тивирально может быть. Например если уже есть некая история.
P.S. У вас с Кафкой опыт есть? Я так понимаю именно для это-го он подходит?
Отличная статья, большое спасибо! В закладки!
Поговорить о деталях видимо может быть уместным только попробовав на практике… Пока у меня небыло подобного опыта в полном обьеме хотя писать эвенты вместа апдейта статуса уже догадывались под разным причинам ;)
Интересует такой момент. В описаной вамеи связке Event Sourcing + CORS события имеет смысл класть в какое-то хранилище (Event Bus).
Вы вначале статьи написали о Кафке и похоже именно на неё намекаете, (я именно в таком контексте слышал о кафке). Могли бы вы побольше пролить свет о роли кафки или другого хранилища?
И правильно ли я понял что при наличии надежного хранилища событий, в идеале его можно сделать единственным и эксклюзивным хранилищем всей истории событий?
Даный подход открывает невероятное возможности в динамике конзумирующих сервисов в таком случае, что очень интересно.
П.С.
А при переходе на таку модель с чего-то исторического, надобно существующий статус как-то перевести в начальные события, что-бы отчего-то оталкиватся, без потери информации и возможнои истории, что может быть тоже не тривиально совершенно..
Месяца 3 назад бегло пробовал. Да тормозило сильно…
Но можно посерьезнее постмотреть и хитро пайпить… это верно.
да именно к нему присмариваюсь в часном проекте… Но на фирме там разные сложные констрейны с банковскими клиентами. так просто уйти в следующий клауд сервис да еще с логами не реально пока ;))
Не посоветуете что-то не тормозящее что может выкичивать из CloudWatch напрямую или переброс в S3 это стандартных подход к вопросу? Если да то как это делают?
Простите а виртуальная машина явы именно на них смотрит при планировании ресурсов?
У вас это тоже так ;)
Это закон мура… И я в нем не сомниваюсь после >12 лет проф. деятельности в различных ролях и фирмах