Любая большая корпорация это отдельный мир, со своими правилами, своими подходами и своими вариантами решениями технологических проблем. И всегда интересно из одного мира заглянуть в другой. А как оно там?

Хочу представить прекрасный доклад коллег из СИБУРа которые рассказывают про трудности доставки централизованно разработанного ПО на удаленные производственные площадки.

Доклад был сделан в октябре этого года на конференции Industrial++ Если кто-то захочет задать вопросы их можно задать в комментариях, докладчики есть среди подписчиков канала.

https://www.youtube.com/watch?v=dp_MSA20uqM

#доклады

Еще один рассказ "из другого мира", на этот раз из мира автомобильного.

Тема для меня совершенно неизвестная, и как все неизвестное интересная. Технологический стек облачный, правильный стек. И рассказал докладчик очень хорошо.

https://www.youtube.com/watch?v=9Iy0bUCqq6Q

#доклады

На следующей неделе уже начинается HighLoad, а ее еще не отчитался обо всех ноябрьских конференциях. Исправляюсь, стараюсь нагнать.

7-8 ноября проходила конференция ByteOilGas (https://byteoilgasconf.ru). Если коротко то конференция мне очень понравилась, организована прекрасно.
Конференция больше IT-шная, но совсем программистские доклады тоже были - про Python, про алгоритмы, про оптимизацию, и конференция дает очень хороший срез основных тем над которыми работает отрасль.

Много докладов по теме безопасности - построение конвейеров DevSecOps, безопасная разработка, безопасность LLM моделей. Много докладов по архитектуре, предполагаю что это связано с активным импортозамещением, чтобы начать замещать, надо сначала инвентаризировать.

Нам тоже предоставили возможность выступить с докладом. https://vkvideo.ru/video-218490305_456239123?t=6h9m42s

Из других докладов которые меня заинтересовали отмечу доклад Руслана Кульчинского из "Транснефти". Прекрасный рассказ про то как все сложно, и как интересно.
https://vkvideo.ru/video-218490305_456239118?t=19m24s

К сожалению еще не все стримы успели порезать на отдельные выступления, поэтому делюсь ссылкой на стримы целиком.

#доклады

Давно с интересом слежу за развитием темы "Архитектура как код". Докладов и событий по этой теме становится все больше, инструменты развиваются, совершенствуются подходы.

В самый канун Нового года, "под елочку", пройдет презентация новой версии DocHub.

https://t.me/dochubchannel/170

#aaac

Запись вебинара Максима Чудновского "Защита контейнерных сред с помощью 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