Synapse Community

Я уже делился что в докладе Павла Шерепо из VK https://t.me/SynapseDevCommunity/36 обратил внимание на идею группировки релизов. Если релизов много, а 300 релизов это много,  их разумно объединять в группы для удобства управления. Группы могут быть: - тематические, например все релизы относящиеся к какому то проекту; - для удобства, например все релизы запланированные к внедрению на этой неделе; Еще из важного, группы не являются постоянными, на каждой стадии их можно формировать заново, исключать из них отдельные релизы или наоборот дополнять hot-fix-ами, можно даже полностью разбирать. Например: - делаем группу "релизы готовые к выкатке 14.08"; - включаем туда 20 релизов и выкатываем на greenfiled; - проводим анализ работы на greenfield-е; - откатываем один из релизов, исключаем его из группы и возвращаем на предыдущую стадию ждать смежных доработок; - следующий сбойный релиз откатываем и удаляем из группы, не взлетел; - для еще одного сбойного релиза выпускаем срочный патч и включаем его в группу вместо сбойного релиза; - обновленнцю группу выкатываем на основные площадки; - анализируем результаты работы; Особенно  эффективны группы будут на стадии  выкатки в сложный пром.контур, там где автоматический процесс все равно дублируют ручным контролем и может потребоваться ручное вмешательство. #deploymentasacode

Отвлекусь ненадолго от процессов деплоя. Про наш продукт. 22.08 проводим вебинар. Приходите. https://t.me/syngx_proxy/6

Проект Kargo Кому интересны детали рекомендую видео https://www.youtube.com/watch?v=Pto7QnxkjjA Основной тезис создателей Kargo - enterprise deploy в ближайщем будущем не станет полностью автоматическим. Даже если выкатка на конкретный кластер K8s будет автоматизирована полностью , в корпоративном ландшафте есть greenfield-ы, есть разные площадки, есть резервный контур (standbuy/standin), выкатка на них может быть разнесена по времени на несколько дней или недель, требовать добавления hot-fix-ов, выбора порядка площадок, контроля синхронизации резервного контура и т.д. Сложный процесс выкатки в большой системе все равно будет требовать ручного контроля. Под эту задачу в Kargo спроектировали интуитивно понятный интерфейс - сверху бесконечная лента релизов, в центре граф стадий процесса выкатки, справа цветовая диаграмма прохождения релизов по стадиям. Удобно, логично, красиво. А если у вас, допустим, есть десяток offline площадок то вещь вообще незаменимая. Что будет если увеличить кол-во релизов? Если увеличить, картинка перестанет быть красивой. На работу с лентой из 200 релизов интерфейс не рассчитан. Откуда 200 релизов? Редко когда реально нужно выкатить такое кол-во релизов за день. Если говорим про 3 релиза или про 5 релизов, можно спорить удобно или нет передвинуть их мышкой через несколько стадий. 200 релизов ставят точку в споре, двигать их мышкой никто не хочет. Для работы с большой лентой релизов нужна какая-то группировка. Про это в следующем посте. #deploymentasacode

Кроме нескольких оптимистов которых я похоже знаю, все остальные подтвердили что может оно и должно так быть, но этого точно нет. У меня есть два варианта почему: - Пока жили в монолите, этот вопрос не имел никакого значения. Переходили в микросервисы быстро, получилось как получилось; - Разложили тексты в красивую структуру и дальше что? А ничего. Нет готового инструмента собирающего релизы отдельных компонентов, конфигураций внешних ресурсов, релизы проекта и т.д. Его надо делать. Быстро он не делается, поэтому даже если кто-то в начале попытался навести красоту, это быстро забросили и пошли "давать план"; Если у кого-то есть свой вариант почему, добавляйте в комментарии. Как должен работать такой "идеальный сборщик"? Должна быть возможность собрать и выпустить релиз отдельного компонента или ресурса: - project.business_component.r.01.002.35 - project.kafka.r.39.003.01 Должна быть возможность собрать релиз проекта, включив в него несколько ресурсов и компонентов - project.r.04.001.04       - postge.r.05.021.01       - business_component.r.01.02.36       - another_business_component.r.03.001.02       - nginx.r.06.007.08 В релизе компонента могут быть только манифесты, только образ или и то и другое. Кажется отсутствие такого готового инструмента сборки это главное белое пятно. Если пофантазировать что он уже есть, то дальше все более менее понятно, есть Argo, есть CrossPlane, есть Kargo, из почти готовых кубиков можно быстро собрать pipeline любой сложности. #deploymentasacode

Давно занимает такая тема: Раз микросервисная архитектура это покомпонентный перенос изменений в пром.среду, то структура репозитория проекта должна соответствовать составу компонентов в проме один в один, как на рисунке. Чтобы задача сборки и выкатки изменений не превращалась в занимательный ребус. Почитал статьи про модели ветвления, посмотрел доклады, такой информации ни у кого не нашел. Везде рассказ начинается с того что репозиторий уже есть и давайте будем ветвиться. #deploymentasacode

Любую крупную систему хотя бы раз в год накрывает "девятый вал" внедрений. С переходом в микросервисную архитектуру это вал становится 90-м или даже 900-м, обьектов управления то кратно больше. Как выжить и уцелеть в этих обстоятельствах в докладе от VK. Что то похожее на идеи из доклада есть в проекте Kargo (kargo.akuity.io). Предложение обьединять доработки в пакеты (в докладе это поезда) напомнило "плановые интеграционные релизы" и неожиданно в новом микросервисном мире эта идея снова имеет право на рассмотрение, как это ни покажется странным, да. В целом тему можно было бы раскрыть поинтересней, но "каждый мнит себя стратегом...". Несколько хороших предложений по автоматизации выкатки в докладе есть. Видео, к сожалению, снова нет.

Чтобы закончить тему с обзором Saint HighLoad÷÷ еще про два доклада. Давно ничего не слушал про Apache Flink. Когда то был большим энтузиастом использования этой технологии. В 2018 году с коллегами сделали прекрасную систему на базе Apache Flink. С оптимистичным названием -  Харон. Но в докладах Flink встречается редко. И вот рассказ от Т1 как они сделали за 6 месяцев высокопроизводительную банковскую рекомендательную систему на базе Apache Flink. Сложные алгоритмы потоковой обработки невозможно реализовать без  in memory  хранилища, поэтому в докладе еще и про Tarantool. Настоящих буйных мало, но они есть. Для тех кто интересуется где нужны алгоритмы потоковой обработки. Видео, к сожалению, нет, смотрите материалы на платформе Онтико.

"У меня есть мысль и я ее думаю", этот канал целиком посвящен разработке на платформе Synapse и технологии Service Mesh. Для тех кто хочет прочитать о чем то еще сделали с коллегами подборку "наших" каналов. Там про все: - Про разработку - Про то как "пасти котов" (спойлер - никак) - Про DevOps - О жизни и о себе Разные в общем каналы, присоединяйтесьhttps://t.me/addlist/Hjh12dzfjzhmY2Qy

Еще один достойный доклад "YTSaurus и аналитические витрины с актуальностью 15 минут" от Филиппа Козьмина из Яндекс.Маркет. Вообще аналитические витрины тема не наша и я мало чего в этом понимаю, но даже я понял что обновление с задержкой 15 минут от транзакционных систем это очень, очень быстро. И речь не про отдельную оттюненную витрину, а про режим работы большинства витрин. Когда дополнительно погрузился и поговорил с коллегами то впечатлился еще больше. Команда разработки около 50 человек, это очень немного, объем данных в петабайтах около 28, это очень немало, и при всем при этом 15 минут задержка обновления. Ссылки на видео так же к сожалению нет. У кого есть доступ к материалам Онтико посмотрите там. Через некоторое время я думаю выложат в открытый доступ.

Продолжим про Saint HighLoad++ (да я тормоз, ну и что) Следующий доклад который произвел на меня впечатление - "Геораспределенные системы" от Евгения Кузовлева из Т-банка Разобрана хорошо знакомая мне по прошлой работе тема - нагруженная система счетов физических лиц. С отсылкой к CAP-теореме, к книге Мартина Клеппмана "Высоконагруженные приложения". Все как мы любим. Основной тезис доклада - в чистом виде преодолеть теоретические ограничения невозможно, но при учете некоторых граничных условий и особенностей работы конкретного бизнеса можно создать устойчивые к разделению, и в тоже время высокодоступные приложения. Автор приводит пример - в профиле нагрузки системы счетов расходные операции значительно превосходят приходные по частоте, но сумма расходных операций как правило значительно меньше общего остатка на счете, с другой стороны приходные операции по сравнению с расходными менее критичны к скорости выполнения операции. В этих условиях, для создания системы размещенной в трех дата центрах на разных континентах, разработчики системы решили вести на счете остаток из трех частей, любая расходная операция с суммой меньшей чем 1/3 остатка авторизовывалась принявшим дата центром без синхронного обращения к смежникам, и только операции превышающие 1/3 остатка выполнялись в режиме синхронизации с двумя или тремя дата центрами, операции пополнения проводились в асинхронном режиме. К сожалению видео в открытый доступ не выкладывалось. У кого есть доступ к материалам Онтико ищите. Кто работает вместе со мной пишите, чего-нибудь придумаем. Еще один тезис доклада который мне отозвался - никакой бизнес никогда не даст вам требования на создание такой системы, нужно самим создать, а потом объяснить бизнесу как это будет работать, и объяснить что по другому работать просто не будет. На этом месте доклада я аплодировал, потому что прикладное программирование, по моему мнению, это вот так, а не детальное выполнение требований, соответствие ожиданиям, и прочий low-coding (шутка). Если у кого-то есть доступ к материалам Онтико, потратьте 30 минут, доклад стоящий этого.

Привет. С некоторым опозданием хочу поделиться впечатлением от Saint  HighLoad. Сразу скажу что мне понравилось. Очень. Может попались темы в которых я хоть что-то понимаю, но кажется было много сильных интересных докладов. По части есть возможность поделиться ссылками, по части нет. Первый доклад Романа Щербакова из Т-банка "Пайплайны записи своими руками: думали - велосипед, оказалось - паттерны". Название не очень завлекающее, и это, пожалуй, единственный недостаток доклада. Освещены основные вопросы создания системы сбора и долгосрочного хранения метрик, логов и трассировок: подключение новых потребителей, внезапные всплески нагрузки, изоляция "шумных соседей", охлаждение и вытестение данных, работа в геораспределенной конфигурации, экономия ресурсов. У коллег есть небольшое сообщество в телеграм и версия с открытым кодом. Вот ссылка на сам доклад https://www.youtube.com/watch?v=bLBbzdKCheM

Привет всем. Делюсь видео доклада Максима Чудновского на SaintHighLoad 2024++ https://youtu.be/eZg5LO6BssQ В докладе подробный рассказ про использование KubeLatte - PolicyEngine с открытым исходным кодом от команды Synapse. https://gitverse.ru/sbertech/kubelatte-ce

Им GitVerse сказал спасибо: На прошедшей 27.06 большой конференции GigaConf немного внимания перепало и на нам. Проект KubeLatte получил звезду GitVerse за командную работу. Приз для команды получает Александр Козлов. Напоминаю что KubeLatte это PolicyEngine с открытым исходным кодом от команды Synapse который позволяет управлять кластерами Kubernetes с помощью политик.

Сегодня в 16.00 в Большом зале на Saint HighLoad доклад Максима Чудновского про инструмент превращающий переход с одного дистрибутива Kubernetes на другой в приятную прогулку. Заходите послушать.

Ссылка на доклад Александра Козлова на прошедшей в апреле в Екатеринбурге конференции DUMP про решение задачи деплоймента в мультикластерных конфигурациях https://youtu.be/Gl2Wa3xfGUk?feature=shared

Анонс доклада на июньской конференции в Санкт-Петербурге - Saint HighLoad. Максим Чудновский расскажет про решение проблемы переноса сервисов между разными платформами контейнеризации. https://highload.ru/spb/2024/abstracts/12048

С опозданием на один день ссылка на наш доклад на JPoint Максим Чудновский и Александр Козлов "Как мы сделали кастомный Service Discovery для Istio" https://jpoint.ru/talks/e28ad7e10fbb4b03a9996a0ab81c9a2d/?referer=/schedule/today/