Запись вебинара Максима Чудновского "Защита контейнерных сред с помощью Policy Engine и ServiceMesh"

#доклады

https://rutube.ru/video/private/434a3496f25727039a59f82af1d3eb9f/?p=-VKkatJhxK-rpf0lhYJQyg

Поделюсь записью  еще одного очень хорошего вебинара от компании Luntry - "Подпись и валидация образов в  Kubernetes"

#доклады

https://luntry.ru/research

Идея, которая не пригодилась

Разбирая старый компьютер, наткнулся на презентацию 2018 года, когда только начинали переходить в контейнерные среды.
Презентация была посвящена доставке НСИ (нормативно-справочной информации). Казалось бы, что может быть проще, чем работа со справочниками? На самом деле, справочники – это основа работы любой информационной системы; без них ничего работать не будет.

Немного деталей:
1. У каждой системы есть своё программное обеспечение, которое читает данные из справочников. Так делают для повышения автономности и надёжности.
2. В каждом ландшафте существует своя система ведения и выгрузки рабочих копий справочников.
3. Если система распределённая, то есть еще система тиражирования справочников на все площадки.
4. Тиражирование справочников происходит, как правило, в виде транспортных архивов или файлов.
5. На каждой площадке имеется отдельная база данных либо набор баз данных, либо набор схем в общей базе данных, где хранится рабочая копия справочников.
6. У каждой системы есть программа загрузки справочников, которая переносит информацию из транспортных файлов в рабочую копию базы данных.
7. В каждой системе присутствует набор программных компонентов со своими API, которые читают данные из справочников.
8. Чтобы чтение из справочников происходило быстрее, данные обычно поднимаются в кэш.
9. Кэш необходимо уметь сбрасывать, это делается через управляющую консоль.
10. Консоль также отвечает за мониторинг загрузки транспортных файлов и наличие ошибок.

Продолжение в следующем посте...

Собственно, само предложение заключалось в следующем: а давайте откажемся от транспортных архивов, от хранения рабочих копий в базе данных, откажемся от системы тиражирования транспортных файлов, от кэширования, от управления кешем, от мониторинга ошибок загрузки, от необходимости на каждом стенде следить за тем, чтобы в базе данных была нужная версия данных, а в кластере — нужная версия программного обеспечения, умеющего работать с этими данными.

Просто положим справочники в виде файла в образ и прочитаем его при старте приложения. Исчезнет половина, если не две трети сложности. Не будет проблем с масштабированием, не будет проблем с развёртыванием новых стендов, не будет проблемы с временем отклика при обращении к справочникам.

Особенно удобна такая схема, когда ещё нет общей системы тиражирования транспортных файлов. Всё, что нужно, — выложить образы в общедоступный реестр и на каждой площадке поднять нужное кол-во кластеров Kubernetes.

Привет всем.
Видео доклада Максима Чудновского на HighLoad 2024

"Все то, что нужно для сетевой безопасности приложений в платформе на базе Kubernetes"

https://youtu.be/LgIEXAJm5Rk

В докладе будет, в том числе, про KubeLatte - PolicyEngine с открытым исходным кодом от команды Synapse. https://gitverse.ru/sbertech/kubelatte-ce

#доклады

Запись вебинара "Архитектура как код".

Вы спросите: «Чего ты опять с этой архитектурой?» У меня есть предчувствие, возможно ошибочное, что дальнейшее развитие платформы Kubernetes, микросервисного подхода и всеми любимого ИИ сильно трансформируют прикладное программирование. Оно должно стать ещё более высокоуровневым. Может быть, прикладные программисты станут архитекторами, а может, архитекторы — программистами? Я не знаю, но какой-то ветер перемен прям ощущается.

https://t.me/dochubchannel/173

#aaac

На Хабре вышла статья Максима Ажгирея про инструмент нагрузочного и функционального тестирования SyTester. Вопросы автору статьи можно задавать как на Хабре, так и в комментариях под постом.

📌Полная версия статьи - ссылка

В ноябре код SyTester-а был выложен на GitVerse и доступен по ссылке

#Habr

Про велосипеды.

Перед Новым годом прочел интересную статью. Хотел ею поделиться, но забыл. К тому же она была очень интересная, но не совсем про разработку, точнее совсем не про разработку.

Статья посвящена событиям, о которых мы знаем немного — трансформации американского военно-промышленного комплекса и истории утраты им технологического лидерства. Она короткая и написана блестяще. Проблемы, которые обсуждаются Шьямом Санкаром, техническим директором компании Palantir, хорошо знакомы и разработчикам.

Например, если вслух произнести «дублирование кода», любой мысленно продолжит: «Надо бы устранить». Перед словом «архитектура» рука так и тянется добавить «согласованная» или «утверждённая». Мы ворчим по этому поводу, но это скорее поза. Если поставить вопрос ребром, все ответят: конечно, устранить, согласовать и утвердить. Ну а как иначе то? Теоретически, во второстепенных вопросах иногда можно, но в серьёзных вопросах однозначно нельзя.

Автор статьи рассуждает о вопросах максимально серьёзных.

Пару дней назад в частной беседе кто-то из коллег сказал: «Ну понятно, очередной велосипед». В этот момент я снова вспомнил про статью. Мы всегда говорим об «изобретении велосипеда» с негативной коннотацией; в воображении тут же всплывают еще костыли и квадратные колёса. Хотя на самом деле почему? Почему мы так про велосипеды? А по той же причине, по которой дублирование кода хочется сразу устранить.

Поэтому ещё интереснее ознакомиться с мнением человека, который предлагает этого сознательно не делать — не устранять дублирование, не согласовывать архитектуру.

Перевод статьи нашёл на канале Александра Любимова. Текст здесь (https://t.me/akela_zavtra/99). Прочитайте, некоторые тезисы про организацию сложных производств интересные.

#велосипеды

Про велосипеды, продолжение.

Чем зацепила статья из поста выше? Конечно же, формулировки смешные ("про Кубу и Министерство обороны США") и тезисы броские ("отрыв коммерческих инноваций от производства", "зацикленность монополии на затратах, контроле и муторном регулировании"). Но самое главное – это абсолютно понятный любому айтишнику разговор о среде, которая генерирует и поддерживает инновации.

Анализ, проведенный Шьямом Санкаром, удивительно подтверждает выводы, сделанные двадцать пять лет назад Эриком Реймондом в его знаменитой статье «Собор и базар» о модели разработки операционной системы Linux. (Если кто-то вдруг не читал, вот ссылка на перевод)

Когда одни выпускают кукурузные хлопья и системы наведения, другие – алюминиевые банки и первые ступени ракет, и так далее, это типичный «базар». Его реорганизовали в строгий «собор» из пяти крупных компаний с долгосрочным финансированием и "выстроенными" процессами. «Собор», казалось бы, должен был обыграть «базар» в одну калитку, однако, если верить автору статьи, получилось ровно наоборот ( "консолидация породила конформизм").

А при чем здесь "велосипеды" спросите вы? "Велосипеды" это и есть инновации. Нет никаких формальных критериев, позволяющих на ранних этапах отличить «велосипед» от перспективной инновации. На старте они выглядят совершенно одинаково – как "велосипед". Решающий фактор отбора перспективных решений – количество попыток, предпринятых независимыми экспериментаторами.

#велосипеды

Чуть флуда на этом серьёзном канале.

Сегодня исполняется 30 лет с момента выхода мажорной версии JDK 1.0.

У меня в связи с этим своё воспоминание: где-то в 1998 году я пришёл к нашему зам. директору Владимиру Александровичу, светлая ему память, и говорю: «Технология перспективная, надо переходить». (Всё, что у нас было в тот момент, работало на SCO Unix и на C/C++.) Долго я его этим вопросом доставал. Собрали какое-то совещание, все послушали про "write once, run anywhere" и сказали: «На фиг-на фиг». Я, конечно, расстроился слегка.

Уже после совещания он меня спрашивает:
— Сколько этой твоей Java ресурсов то надо?
— 4 Мб памяти минимум.
— Ну вот видишь, а у нас, у нас во всех филиалах на рабочих местах 640 Кб.

Да путь к инновациям никогда не бывает легким.
Всем, кто продолжает сегодня писать на Java, физкульт-привет!

Про велосипеды. Окончание

Никак не мог дописать про велосипеды. Крутится в голове разное: велосипеды, Калашников, реформа американского ВПК, Айзек Азимов, князь Кропоткин, анархисты... Поэтому дальше будет набор несвязных мыслей.

"Велосипедом" принято называть попытку сделать уже сделанное по следующим причинам:
- не смогли нагуглить;
- нагуглили, но было лень дальше читать;
- чтобы чтобы упростить сложную реализацию;
- чтобы приспособить старую реализацию к изменившимся условиям.

И выглядит это, как правило, совершенно нерационально. Зачем «изобретать велосипед», когда нужно правильно пользоваться проверенными решениями? И вроде действительно так, но есть несколько «но». Первое — упрощение, это самый главный инженерный навык. Великий Михаил Калашников, в начале своей карьеры, услышал от другого великого конструктора Георгия Шпагина* присказку, которую повторял всю жизнь: «Самое сложное — это сделать просто». Второе — а откуда, собственно, берутся проверенные надёжные решения? Из требований пользователей? Ну, если вы никогда не слышали про Айфон, вы вряд ли знаете, что он вам нужен. Они берутся из попыток сделать что-то по другому, иногда из наивных, как правило нерациональных, иногда рискованных, и всегда интересно понять, почему они вдруг делаются и как выживают, превращаясь в зрелые проверенные решения.
*(на всякий случай, Г. С. Шпагин — это конструктор автомата Победы, ППШ, такого с круглым магазином, и один из конструкторов пулемёта ДШК)

У Айзека Азимова был рассказ «День знаний», в котором цивилизация достигла такого прогресса, что все нужные знания прошиваются обучающимся прямо в мозг, а вся специализация, карьера, весь жизненный трек человека определяются на основании тестирования подростка машиной. И в этом обществе был очень небольшой процент «бракованных» персонажей, непригодных ни к какой прошивке; единственное, чем они были полезны, — они могли создавать новые знания, те самые обучающие программы, которые прошивали всем остальным. Те из них, из кого учёных в результате не получилось, становились коучами и психологами. Возможно что «изобретатели велосипедов» из тех самых, из «бракованных».

#велосипеды

Про велосипеды. Окончание.

Что еще зацепило в статье Шьяма Санкара? Эта статья — программный манифест одного из кандидатов на должность заместителя министра обороны США, и основной её тезис — «Развитие не может быть регламентированным, развитие всегда хаотично».

Это пишет представитель культуры, которая вся про «how much», про измерение всего и рациональное управление. И шутки про Министерство обороны США и Кубу, про проигрыш великих американских автоконцернов в конкурентной борьбе японцам, они приведены как обоснование идеи, что «научное и рациональное» управление развитием не работает, и придётся выбирать.

Можно спросить: «А нам-то зачем всё это читать?» Мы ведь живём в другой экономической реальности и вообще люди другой культуры. И тут вот что интересно: одно из направлений общечеловеческой мысли, в которое русские внесли наибольший вклад, — это анархизм. Явление, бывшее очень популярным в России в конце XIX — начале XX века, яркое, сложное, сейчас почти забытое, упрощенное до нескольких клише: революционные матросы, Нестор Махно и лозунг «Анархия — мать порядка» (лозунг, кстати, принадлежит французу Пьеру-Жозефу Прудону).

И тут что интересно, на этом обычно не делают акцент, но программное обеспечение с открытым исходным кодом — это просто образцовая реализация идей князя Кропоткина. Наш любимый Agile тоже, анархисты называли команды артелями, на роли скрам-мастеров акцентов не делали, но на этом сущностные различия заканчиваются. В основе Agile лежат идеи анархистов, примененные к специфической технической отрасли, где основой производства являются не ресурсы, машины и механизмы, а обмен информацией и идеями между людьми.

Заканчивая этот поток путаных мыслей… Обычно фразу «Анархия — мать порядка» произносят с такой же коннотацией, как и «Изобрести велосипед», мол, хотите внести беспорядок и дезорганизацию в наши дела. Я, собственно, всегда так её и понимал и использовал, но статья Шьяма Санкара заставила ещё раз задуматься. Она написана по «очень серьёзному поводу» и для «очень серьёзных людей», но написан в ней буквально тот же лозунг, ну или я это так прочитал.

#велосипеды

Про нестареющую классику

В середине 90-х идея «Шаблонов» захватила информационное пространство, почти так же, как сегодня LLM-модели. Самой известной книгой той эпохи является, конечно, труд Эрика Гаммы и соавторов «Design Patterns». Однако были и другие работы: серия «Pattern-Oriented Software Architecture» Франка Бушмана, «Enterprise Integration Patterns» Грегори Хопа, «Patterns of Enterprise Application Architecture» Мартина Фаулера.

Самая первая книга Мартина Фаулера немного выбивалась из общего ряда — она называлась «Analysis Patterns» и была посвящена шаблонам анализа. К сожалению, эта работа на русский язык никогда не переводилась. Но вот недавно некий добрый человек выложил в открытый доступ свой перевод этой книги. Несмотря на то, что прошло почти 30 лет, описанные в ней подходы по-прежнему актуальны не только при разработке структуры классов, но и при проектировании микросервисных архитектур.

Статья: habr.com/ru/articles/872598
Перевод: violettape.github.io/ap_book/cover.html

P.S. Новость нашел на канале Кати Лысенко

Следим за успехами Архитектура как Код

Сегодня сложно себе представить платформу по работе с кодом без ИИ АССИСТЕНТА. DocHub не отстаёт. На примере Романа co-pilot помогает в написании документации и предлагает варианты заполнения архрешения. Думаю качество решений будет только расти. Пользуйтесь!
#aaac

AI теперь в DocHub официально!

Долгий был путь к разработке внятной интеграции AI ассистентов в DocHub. Но, наконец, инфраструктурные метания завершены. Ассистент встроен и совместно со мной проходит тесты наполняя документацией новый портал DocHub!

Впереди еще большая работа по его улучшениям. Но в целом, уже сейчас он реально облегчает мне задачу документирования.

Шаблоны проектирования

Совсем недавно вспоминали прошлый век и "Analysis Patterns", а сегодня прочитал у коллеги на канале про AI шаблоны.

P.S. Канал кстати хороший, я читаю.
Ну и к Мартину Фаулеру на сайт надо заглянуть обязательно. У меня ощущение, я не знаю почему, что эти технологии: микросервисы, архитектура как код, и AI помощники где-то должны встретиться и дополнить друг друга. Как конкретно, я пока не понимаю, но ощущение есть и давно что встретиться должны на нашей платформе.

https://t.me/javaKotlinDevOps/387

Микросервисы

Куда сейчас без них? Мы привыкли слышать про микросервисы в интеграционных приложениях или в высоко нагруженных бэкофисах. Но только этими областями применение микросервисов не ограничивается.

Сегодня в 13.00 коллеги расскажут про микросервисы в моделировании процессов нефтегазохимической промышленности. Интересно будет сравнить с собственным опытом. Заходите послушать.

https://t.me/fielddev/471

Классика

UML, если кто вдруг не помнит, родился как объединение трех нотаций. Одна из них называлась нотацией Якобсона.
Ивар Якобсон это тот самый человек который ввел в широкое использование понятие Use Case Diagram.

Очень старая (2017) но интересная лекция Ивара Якобсона

https://2017.secrus.org/program/submitted-presentations/kill-all-methods-free-the-practices

Еще про цифровые двойники. Нашел интересный референс в НефтеГазовой индустрии. Идея похожа на то что предлагалось для микросервисного проекта https://t.me/SynapseDevCommunity/50.

Каждая единица оборудования (в нашем случае это микросервис) описывается набором уравнений. Оборудование собирается в проект (в нашем случае цифровая архитектура) и получается цифровой двойник промышленного объекта.

Преимущество этого решения в том что на самом промышленном объекте не нужно организовывать хранение большого объема данных. Для запуска цифрового двойника достаточно локального компьютера. При необходимости цифровой двойник можно откалибровать под конкретный пром.объект.

Полная запись вебинара по ссылке

#DigitalTwin

Ролик про разработчика который пришел к архитектору выбирать себе платформу

На прошлой неделе прошла 10-я, юбилейная DevOpsConf "Профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации".

Честно говоря мне она кажется даже интересней чем более "престижный" ХайЛоад. В этом году четко заметен тренд на создание внутренних платформ. Тренд видимо был давно, те кто вышли в этом году с докладами, начали работы 4-5 лет назад. В этом году заметны уже результаты тренда.

Может это мой личный вкус, но самый интересный доклад был тот где прямо начали с вопроса - а кто клиент внутренней платформы?
И на следующем слайде ответили на вопрос, что основной клиент внутренней платформы - это разработчик.
Получился прямо классический рассказ про "Customer jorney map".
Возможно следующим этапом развития станет унификация и появления коммерческих developers platforms, будем следить.
Я надеюсь частью докладов, с разрешения авторов получится поделиться.

P.S. На фото вместе с Максом и Всеславом смотрим в прекрасное платформенное будущее с оптимизмом