Вот только LB у них у всех на одну домену (с одним SSL/TLS сертификатом) расчитаны ;) — ну это так, личная боль когда мног разных независимых проектов ;)
Использую GKE частным образом и EKS на работе (4 кластера). EKS стартовал вяло но сейчас вполне сносно…
Очень субьективно, но мне GKE больше нравится именно из-за приемлего мониторинга за даром и за бесплатный мастер.
Но и сами концепции в GKE кажутся мне у изначально продуманей а AWS постоянно приходится делать кучу оговорок и компромисов с их же самым легаси которое они набрали за долгие годы.
к 1.
Архитеркутрные паттерны: Command-Query-Responsibility-Segregation, Event Sourcing, Domain driver Design
к 2.
О ES уже фактически расказанно в докладе. Эта шина кафка и есть из которой можно "проиграть" событияиз прошлого… ES — в общем случае бесконечное прошлое.
ES отлично идет с CQRS и поэтому тоже упоминется…
Очень грубо: На входе команды (C из CQRS) котрые изменяют Агрегаты и порождают события(Events), вернее цепи событий как в докладе. А Q — это модель чтения состояния. Как можно догодаться если все на эвентах и командах то чтение и запись разделены(RS). И да я упомянул Агрегаты и события и вот мы уже и в DDD — это от туда.
А все-таки было бо интересно.
Прошло >2 года статья не потеряла актуальность. Спасибо, за четкое изложение.
Но можетъ есть у вас обновление сего доклада, но с более выверенными временем вещами и возможно более четким указанием на упомянутые DDD и ES ?
Первое и возможно главное что надо знать о podman это то что эго консольный интерфейс на 99% совместим с docker.
podman на моей рабочей федоре стоит месяца, я периодически строю и запускаю контейнеры, разницы в команндах не обнаружил пока.
Конечно есть ньюансы и они делаю podmanинтереснее. К примеру нет никакого демон процесса как у dockerи не нужен root.
В полушутку, рискуя кармой ;)
На самом деле годная статья, почитаю внимательней после полуночи, а пока хочется окунуть вас в это:
Представьте у вас трое детей!
"Колесо баланса", они сказали… мухаха…
Хотите мое колесо баланса.
Тут то плохая оценка, то подрались, то одеваться не хотим, то ещё мультик, то просто в штаны уделался кто-то
Ах да, деплоймент в продакшен между делом и общение с клиентом :)
Хомскулинг! — это придумали эгоистичные старики! :))
Вот тут описано про компоненты.
Сначало containerd-shim стал необходим что-бы запуск контейнеров вообще от docker cli и проичего отвязать как я понимаю. тогда интерфейсы CRI, CNI только недавно появились… и докер распилили.
Ну тоесть изменение находится в месте стрелочки <--> которя между containerd и dockerd.
если я вас правильно понял. После второго прочита я это тоже так понял.
Возмите в учет обычный клик. Любого пользователай вполне себе событие просмотра со множествоме метаданных. Кто, когда, и где и т.д.
И это миллионы этих 500-2000 байт.
К томуже их кафки могут быть использованны для чего угодно… Например стриминг логов с их серверов.
Ах. похоже картинко не про то.
видимо docker shim это лишнее звено между contanerd и чистым Докер рантаймом? Наверняка в Опен шифт от этой схемы уже давно ушли
1) не надо быть зарегистрированным что-бы пользоваться сайтом.
2) сколько по вашему занимает базовый эвент взаимодействия с сайтом? Опустим добавление медиа (картинок, видео и т.д.)
Я ищу свитч для дома который может 10Гбит.
Кабеля проложены Кат7 материнкы выпускаются уже с 10Гбитным интерфейсом, но вот со свитчем как-то непонятно все или дорого.
Пока это все очень похоже на очень дорогие сервисы сомнительной полезности, за цену вложенного доллара.
Но тема WAF и NGFW хайпит ведь большие концерны обожают купить сервис что-бы закрыть какой-то "технический" вопрос, даже если закрыт он только на бумаги для аудита...
"Обратный" подход тоесть contract first становится предпочтительней и важне как только вы подымаете голову из одного конкретного сервиса и смотрите на ваш сервисный ландшафт. Например если вы архитектор или проэктный мэнеджер или решате подобные задачи в любой другой роли.
Тоесь сначала вы пишите технический контракт API а потом уже реализацию. Очень верятно что это будет цикл: получил фидбек — улучшил.
Я например в какой-то момент задолбался обьяснять слишком удаленным от меня программерам (в nearshoring) что нельзя просто так взятъ и поменять api. Теперь им из Open API генерится библиотека содержащая Java Interafaces in Value Objects, все версионированно. Ошибки конечно ещё можно сделать но хотябы тип возвращаемого или поличемого обьекта не меняется больше без предупреждения и т.д.
Но Куда важнее другая тема. Имея представление о API в техническом формате мы смогли ускорить разработчиков клиентского приложения. Их команда смогла на 6-9 месяцев раньше начать писать их приложение и давать нам фидбек к нашему API которое которое на тот момент сущёствовало только как Open API без написаных сервисов.
Вот только LB у них у всех на одну домену (с одним SSL/TLS сертификатом) расчитаны ;) — ну это так, личная боль когда мног разных независимых проектов ;)
Использую GKE частным образом и EKS на работе (4 кластера). EKS стартовал вяло но сейчас вполне сносно…
Очень субьективно, но мне GKE больше нравится именно из-за приемлего мониторинга за даром и за бесплатный мастер.
Но и сами концепции в GKE кажутся мне у изначально продуманей а AWS постоянно приходится делать кучу оговорок и компромисов с их же самым легаси которое они набрали за долгие годы.
Да и на это есть ответ. Класс distributed broker с их самым известным представителем apache kafka
к 1.
Архитеркутрные паттерны: Command-Query-Responsibility-Segregation, Event Sourcing, Domain driver Design
к 2.
О ES уже фактически расказанно в докладе. Эта шина кафка и есть из которой можно "проиграть" событияиз прошлого… ES — в общем случае бесконечное прошлое.
ES отлично идет с CQRS и поэтому тоже упоминется…
Очень грубо: На входе команды (C из CQRS) котрые изменяют Агрегаты и порождают события(Events), вернее цепи событий как в докладе. А Q — это модель чтения состояния. Как можно догодаться если все на эвентах и командах то чтение и запись разделены(RS). И да я упомянул Агрегаты и события и вот мы уже и в DDD — это от туда.
А все-таки было бо интересно.
Прошло >2 года статья не потеряла актуальность. Спасибо, за четкое изложение.
Но можетъ есть у вас обновление сего доклада, но с более выверенными временем вещами и возможно более четким указанием на упомянутые DDD и ES ?
Первое и возможно главное что надо знать о podman это то что эго консольный интерфейс на 99% совместим с docker.
podman на моей рабочей федоре стоит месяца, я периодически строю и запускаю контейнеры, разницы в команндах не обнаружил пока.
Конечно есть ньюансы и они делаю podmanинтереснее. К примеру нет никакого демон процесса как у dockerи не нужен root.
В полушутку, рискуя кармой ;)
На самом деле годная статья, почитаю внимательней после полуночи, а пока хочется окунуть вас в это:
Представьте у вас трое детей!
"Колесо баланса", они сказали… мухаха…
Хотите мое колесо баланса.
Тут то плохая оценка, то подрались, то одеваться не хотим, то ещё мультик, то просто в штаны уделался кто-то
Ах да, деплоймент в продакшен между делом и общение с клиентом :)
Хомскулинг! — это придумали эгоистичные старики! :))
Всем добра ;)
Вот тут описано про компоненты.
Сначало containerd-shim стал необходим что-бы запуск контейнеров вообще от docker cli и проичего отвязать как я понимаю. тогда интерфейсы CRI, CNI только недавно появились… и докер распилили.
П.С. Хронологию точно не пытаюсь передать.
Ну тоесть изменение находится в месте стрелочки <--> которя между containerd и dockerd.
если я вас правильно понял. После второго прочита я это тоже так понял.
Возмите в учет обычный клик. Любого пользователай вполне себе событие просмотра со множествоме метаданных. Кто, когда, и где и т.д.
И это миллионы этих 500-2000 байт.
К томуже их кафки могут быть использованны для чего угодно… Например стриминг логов с их серверов.
Ах. похоже картинко не про то.
видимо docker shim это лишнее звено между contanerd и чистым Докер рантаймом? Наверняка в Опен шифт от этой схемы уже давно ушли
Я как-то думал что k8s уже давно напрямую с containerd взаимодействует.
Про подобную схему читал вроде как пару лет назад:
Видомо это очередной плюс ;)
1) не надо быть зарегистрированным что-бы пользоваться сайтом.
2) сколько по вашему занимает базовый эвент взаимодействия с сайтом? Опустим добавление медиа (картинок, видео и т.д.)
722 000 000 профилей пользователей. Куча взаимодействий с сайтом.
Каждый клик — событие…
Я ищу свитч для дома который может 10Гбит.
Кабеля проложены Кат7 материнкы выпускаются уже с 10Гбитным интерфейсом, но вот со свитчем как-то непонятно все или дорого.
Не так уж много. Вот две главных из них вы и назвали причем вместе. ;) По отдельности это не определят МС-сы.
Я слабое представление имею о Российском рынке, я скорее о европейском/мировом.
Пока это все очень похоже на очень дорогие сервисы сомнительной полезности, за цену вложенного доллара.
Но тема WAF и NGFW хайпит ведь большие концерны обожают купить сервис что-бы закрыть какой-то "технический" вопрос, даже если закрыт он только на бумаги для аудита...
"Обратный" подход тоесть contract first становится предпочтительней и важне как только вы подымаете голову из одного конкретного сервиса и смотрите на ваш сервисный ландшафт. Например если вы архитектор или проэктный мэнеджер или решате подобные задачи в любой другой роли.
Тоесь сначала вы пишите технический контракт API а потом уже реализацию. Очень верятно что это будет цикл: получил фидбек — улучшил.
Я например в какой-то момент задолбался обьяснять слишком удаленным от меня программерам (в nearshoring) что нельзя просто так взятъ и поменять api. Теперь им из Open API генерится библиотека содержащая Java Interafaces in Value Objects, все версионированно. Ошибки конечно ещё можно сделать но хотябы тип возвращаемого или поличемого обьекта не меняется больше без предупреждения и т.д.
Но Куда важнее другая тема. Имея представление о API в техническом формате мы смогли ускорить разработчиков клиентского приложения. Их команда смогла на 6-9 месяцев раньше начать писать их приложение и давать нам фидбек к нашему API которое которое на тот момент сущёствовало только как Open API без написаных сервисов.