{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Yuriy Gavrilov: posts tagged Dev",
    "_rss_description": "Welcome to my personal place for love, peace and happiness 🤖 Yuiry Gavrilov",
    "_rss_language": "en",
    "_itunes_email": "yvgavrilov@gmail.com",
    "_itunes_categories_xml": "",
    "_itunes_image": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic-square@2x.jpg?1643451008",
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/gavrilov.info\/tags\/dev\/",
    "feed_url": "https:\/\/gavrilov.info\/tags\/dev\/json\/",
    "icon": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008",
    "authors": [
        {
            "name": "Yuriy Gavrilov - B[u]g - for charity.gavrilov.eth",
            "url": "https:\/\/gavrilov.info\/",
            "avatar": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008"
        }
    ],
    "items": [
        {
            "id": "308",
            "url": "https:\/\/gavrilov.info\/all\/zrya-ya-emu-pamyat-stavil-bolshe\/",
            "title": "Зря я ему память ставил больше 🥲 ... проект – “Монолит”",
            "content_html": "<p>вот же блин, не ждал я тут подвоха 😭<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/telegram-cloud-photo-size-2-5388624450019856252-y.jpg\" width=\"1032\" height=\"1152\" alt=\"\" \/>\n<\/div>\n<p>сдулся мой старенький asustor, придется бутылки сдавать ... и еще накатить чего-то с горя, что бы было что сдавать.<\/p>\n<p>🥹<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-01-03-v-19.28.31.png\" width=\"1198\" height=\"866\" alt=\"\" \/>\n<\/div>\n<p>а вот еще тряхнул стариной и решил понарошку собрать комп нестыдный на сегодня :)) ну даже очень.<br \/>\nвот что вышло:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/zrya-ya-emu-pamyat-stavil-bolshe1.png\" width=\"1582\" height=\"1346\" alt=\"\" \/>\n<\/div>\n<p>ну прям мечта сисадмина и не только))) это по сути 4 в одном. через proxmox 4 виртуалки. Первая True Nas Scale для массива, вторая ubuntu server для докеров и Portainer тоже с gpu и третья виндовая для gpu в виндовой среде.  Встречайте...<\/p>\n<hr \/>\n<h2>Проект “Монолит”: Как собрать домашний сервер мечты за миллион (и зачем это вообще нужно)<\/h2>\n<p>Говорят, что универсальных инструментов не бывает. Что “Швейцарский нож” режет хуже скальпеля, а универсальная шина хуже зимней. Мы решили бросить вызов этому утверждению. Ну я и мой электронный друг Gemini.<\/p>\n<p><b>Задача звучала амбициозно:<\/b> собрать в одном компактном корпусе устройство, которое заменит целый IT-отдел. Оно должно быть:<\/p>\n<ol start=\"1\">\n<li><b>AI-станцией<\/b> для запуска “тяжелых” нейросетей (LLM) локально.<\/li>\n<li><b>Графическим ПК<\/b> топового уровня (4K\/8K видео).<\/li>\n<li><b>Корпоративным хранилищем (NAS)<\/b> на 100+ ТБ с надежностью банка.<\/li>\n<li><b>Лабораторией виртуализации<\/b> для Docker, Kubernetes и DevOps-экспериментов.<\/li>\n<\/ol>\n<p>И всё это должно работать 24\/7, стоять дома и не напоминать шумом взлетающий Боинг. Спойлер: у нас получилось.<\/p>\n<h3>Почему не Mac Pro и не облака?<\/h3>\n<p>Первый вопрос, который задают рациональные люди: *“Зачем тратить 1.2 млн рублей на самосбор, если есть MacBook Pro, AWS и простая дисковая шуршалка в углу?”*<\/p>\n<ul>\n<li><b>MacBook M4 Max<\/b> прекрасен, но это “золотая клетка”. На нем не развернешь серьезный кластер виртуализации, в нем нет 100 ТБ памяти, и он все еще слабее в AI-обучении, чем топовые GPU. Ну и закрыл крышку – прод упал.<\/li>\n<li><b>Облака<\/b> — это игла подписки. Аренда мощностей уровня нашей сборки (A100\/H100) будет стоить те же деньги за год-полтора, но в итоге у вас не останется ничего.<\/li>\n<\/ul>\n<p>Мы выбрали путь <b>“Digital Sovereignty”<\/b> (Цифровой суверенитет). Своё железо, свои данные, свои правила.<\/p>\n<h3>Анатомия Монстра: Разбор “железа”<\/h3>\n<p>Каждый компонент здесь — результат компромиссов и долгих споров. Вот наша “Золотая конфигурация”:<\/p>\n<h4>1. Сердце: Архитектура “Всё в одном”<\/h4>\n<p>Мы отказались от серверных Threadripper в пользу <b>AMD Ryzen 9 9950X3D<\/b>.<\/p>\n<ul>\n<li>*Зачем?* Нам важна однопоточная производительность для графики и отзывчивости системы. 16 ядер Zen 5 — это избыточно для дома, но идеально для виртуализации. А X3D-кэш делает этот “сервер” лучшим графическим ПК в мире.<\/li>\n<li>*Материнская плата:* <b>MSI MAG X870E Tomahawk<\/b>. Надежная база с хорошим VRM, способная переварить этот процессор 24\/7. Есть еще Eco режим, что позволит немного снизить мощность, но выиграть в теплоотдач и работе 24x7.<\/li>\n<\/ul>\n<h4>2. Мозг AI: Революция 5090 D<\/h4>\n<p>Сначала мы смотрели на RTX 4090. Но потом решили взглянуть на <b>NVIDIA RTX 5090 D (32GB)<\/b>.<br \/>\nЭто “Game Changer”.<\/p>\n<ul>\n<li>Потребительские карты обычно имеют 24 ГБ памяти. Этого мало для серьезных языковых моделей (LLM). Llama-3-70B туда влезает только “порезанной”.<\/li>\n<li>32 ГБ GDDR7 памяти у 5090 D открывают портал в мир взрослого AI.<\/li>\n<li>Двухслотовая турбина выбрасывает горячий воздух из корпуса, спасая остальные компоненты от перегрева. Да, это стоит 340 000 рублей, но альтернатива (профессиональные карты RTX 6000) стоит в 3 раза дороже. Это отличный истребитель, но не космический крейсер enterprise уровня.<\/li>\n<\/ul>\n<h4>3. Хранилище: Надежность прежде всего<\/h4>\n<ul>\n<li>Диски:<b> 8 штук **WD Ultrastar по 22 ТБ<\/b>. Это 176 ТБ “сырого” объема.<\/li>\n<li>Контроллер:<b> Настоящий серверный HBA-адаптер **LSI 9300-8i<\/b> в прошивке IT-Mode. Никаких программных RAID на материнской плате, только хардкор.<\/li>\n<li>Файловая система:<b> ZFS в режиме **RAIDZ2<\/b> (аналог RAID 6). Могут умереть любые два диска одновременно — данные выживут.<\/li>\n<\/ul>\n<h4>4. Память: Золотая (в прямом смысле) DDR5 ECC<\/h4>\n<p>Самая болезненная строка бюджета. <b>128 ГБ DDR5 ECC<\/b>.<br \/>\nИз-за бума ИИ цены на память взлетели. Комплект из 4 планок по 32 ГБ сейчас стоит около <b>200 000+ рублей<\/b>.<\/p>\n<ul>\n<li>Можно ли сэкономить и взять обычную?* Нет. ZFS активно использует оперативную память. Ошибка в бите памяти может разрушить файловую систему. Для сервера 24\/7 ECC (коррекция ошибок) — обязательное требование. Лучше этим не пренебрегать.<\/li>\n<\/ul>\n<h4>5. Корпус: Jonsbo N5<\/h4>\n<p>Это магия инженерии. Красивый черный куб, куда помещается E-ATX плата, полноразмерная видеокарта и 8 жестких дисков. Мечта с красивыми деревяшками на лицевой панеле :)<\/p>\n<h3>Программная магия: Как этим управлять?<\/h3>\n<p>Железо — это только половина дела. Вся мощь раскрывается в софте.<br \/>\nМы используем <b>Proxmox VE<\/b> как гипервизор. Это “слоеный пирог”:<\/p>\n<ol start=\"1\">\n<li><b>VM TrueNAS:<\/b> Прямой проброс контроллера LSI. Эта виртуалка управляет дисками и раздает файлы по сети.<\/li>\n<li><b>VM Windows 11:<\/b> Прямой проброс RTX 5090. Подключаем монитор\/клавиатуру — и это мощнейший графический ПК. Или подключаемся удаленно через Moonlight.<\/li>\n<li><b>VM Ubuntu Server + Docker (Portainer):<\/b> Здесь живут “слуги”: Home Assistant (умный дом), Plex (кинотеатр), Nextcloud (ваше личное облако) и среды для разработки.<\/li>\n<\/ol>\n<h3>Экономика: Игрушка или Инвестиция?<\/h3>\n<p>Цена сборки чуть переваливает за <b>1 250 000 рублей<\/b>. Безумие?<br \/>\nСмотря как посмотреть.<\/p>\n<p>Если рассматривать это как консоль для игр — безумие.<br \/>\nНо если вы IT-инженер, DevOps или AI-энтузиаст, это устройство становится активом:<\/p>\n<ul>\n<li><b>Аренда мощностей:<\/b> В простое карту 5090 можно сдавать в аренду на площадках типа Vast.ai для обучения чужих нейросетей, отбивая стоимость “железа”.<\/li>\n<li><b>Обучение и Карьера:<\/b> Навыки поднятия Kubernetes-кластера дома или тонкой настройки LLM стоят на рынке труда гораздо дороже миллиона.<\/li>\n<li><b>Свой стартап:<\/b> Это готовый MVP-стенд для запуска своего AI-сервиса без трат на облака.<\/li>\n<\/ul>\n<h3>Итог<\/h3>\n<p>Эта собрка не просто компьютер. Это <b>автономная цифровая крепость<\/b>. В эпоху, когда сервисы закрываются, подписки дорожают, а данные утекают, иметь свой собственный суперкомпьютер под столом — это не паранойя. Это новый уровень свободы для миллионеров из трущоб :)<\/p>\n<p>Добро пожаловать в клуб владельцев виртуальных “Monolith”. 🤪<\/p>\n<p>UPD: 25.01.2026<\/p>\n<p>Первый шаг к монолиту сделан.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/IMG_1037.jpg\" width=\"982\" height=\"1555\" alt=\"\" \/>\n<\/div>\n<p>Кстати, конфигурация немного поменялась. Самсунг ssd заменил в плане на Микрон серверный по 960gb, но 4 штуки. У них оказался срок службы гораздо большое. в 5-7 раз где-то. Они будут работать в Raid10 или raidz1 с блоком 32к. Места будет чуть меньше в raidz1, где то 2.7tb.<\/p>\n<h4>Почему Micron 7450 MAX 1.6TB лучше Samsung 990 PRO UPD: не подходит, надо 2280, будет или 800gb или найду Trancend с PLP<\/h4>\n<p>Сравниваем, опираясь на мануал материнской платы и датащит диска:<\/p>\n<ol start=\"1\">\n<li><b>Бессмертие (Endurance):<\/b>\n<ul>\n  <li>Samsung 990 PRO (2TB):** Ресурс ~1,200 TBW.<\/li>\n  <li>Micron 7450 MAX (1.6TB):<b> Ресурс **8,700 TBW<\/b> (См. Table 3 в инструкции).<\/li>\n  <li>Итог:<b> Micron выносливее **в 7 раз<\/b>. Вы можете писать на него базы данных и логи круглосуточно, и он переживет сам сервер.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<ol start=\"2\">\n<li><b>Over-provisioning (Резервная область):<\/b>  <br \/>\nПочему объем такой странный — 1.6 ТБ, а не 2 ТБ?  <br \/>\nMicron намеренно “скрыл” около 400 ГБ флеш-памяти. Контроллер использует это скрытое место, чтобы перемещать данные, выравнивать износ и поддерживать высокую скорость, когда диск заполнен.  <br \/>\nУ Samsung 990 PRO этой резервной области почти нет, поэтому при заполнении на 90% он начнет тормозить. Micron 7450 MAX будет работать на полной скорости даже если вы забьете его под завязку.<\/li>\n<\/ol>\n<ol start=\"3\">\n<li><b>Скорость случайной записи (IOPS)<\/b>:  <br \/>\nДля виртуалок важна запись мелких файлов (4K Random Write).<\/li>\n\n<ul>\n  <li>Micron 7450 PRO:** 120,000 IOPS.<\/li>\n  <li>Micron 7450 MAX:<b> **250,000 IOPS<\/b> (См. Table 2).<\/li>\n  <li>Модель MAX в два раза быстрее обычной серверной PRO-версии на запись. Это идеально для баз данных и ZFS SLOG.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<h4>Математика массива на Micron 1.6TB<\/h4>\n<p>Если берем 4 таких диска и делаем <b>ZFS RAID10<\/b>:<\/p>\n<p>$$1.6 \\text{ ТБ} \\times 4 = 6.4 \\text{ ТБ (Сырой объем)}$$<br \/>\n$$\\text{Полезный объем (RAID10)} = 3.2 \\text{ ТБ}$$<\/p>\n<p>Еще большой плюс:  PLP (Power Loss Protection) — Защита от потери питания, которая есть в Micron. На плате распаяны танталовые конденсаторы. Если питание пропадает, у диска есть еще несколько миллисекунд, чтобы сбросить всё из оперативной памяти в ячейки NAND = защита от отключения электропитания и потери данных.<\/p>\n<p>Почему это важно для ZFS, он очень зависит от синхронной записи (Sync Writes) для баз данных и виртуальных машин. Зная, что у диска есть защита PLP, ZFS может безопасно отключать некоторые программные тормоза (O_DSYNC), работая значительно быстрее на мелких операциях записи.<\/p>\n<p><b>Итого:<\/b><br \/>\n3.2 ТБ сверхбыстрого, защищенного от потери питания (PLP), “бессмертного” серверного пространства — это мечта для гипервизора Proxmox.<\/p>\n<p><b>Короче берем Micron 7450 MAX 1.6TB.<\/b> Это лучший компонент во всей сборке с точки зрения профессионального подхода. Главное найти его в форм-факторе 2280, а то на материнской плате есть только один длинный порт.<\/p>\n<p>UPD: 22.02.2026<\/p>\n<p>Проц едет.<\/p>\n<p>Диски ssd пришлось заменить на Synology m2 1.6 – других с поддержкой PLP нету в наличии вообще. PLP нужна для защиты от обрывов питания резких. 4 планки будут в 10 массиве, стрейп и зеркало.<\/p>\n<p>Память нашлась в наличии 90к – 48gb ecc ddr5 – но еще не брал(( надо сдать бутылки.<\/p>\n",
            "date_published": "2026-01-03T19:30:34+03:00",
            "date_modified": "2026-02-23T12:40:03+03:00",
            "tags": [
                "Dev",
                "Devices"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/telegram-cloud-photo-size-2-5388624450019856252-y.jpg",
            "_date_published_rfc2822": "Sat, 03 Jan 2026 19:30:34 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "308",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/telegram-cloud-photo-size-2-5388624450019856252-y.jpg",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-01-03-v-19.28.31.png",
                    "https:\/\/gavrilov.info\/pictures\/zrya-ya-emu-pamyat-stavil-bolshe1.png",
                    "https:\/\/gavrilov.info\/pictures\/IMG_1037.jpg"
                ]
            }
        },
        {
            "id": "307",
            "url": "https:\/\/gavrilov.info\/all\/svoy-heroku-doma-zapustil-dokku-doma-i-nakatil-novogodnego\/",
            "title": "Свой Heroku: запустил Dokku дома и накатил новогоднего :)",
            "content_html": "<p>Мы привыкли, что для развертывания веб-приложений нужно платить за VPS или разбираться в дебрях Kubernetes. Но если у вас есть домашний сервер (в моем случае — Asustor), вы можете создать свою собственную PaaS-платформу (Platform as a Service), которая работает по принципу *“git push — и готово”*.<\/p>\n<p>Сегодня я расскажу, как настроить <b>Dokku<\/b> через Portainer, запустить веселое Python-приложение к Новому 2026 году и поделюсь лайфхаками по оптимизации сборки и масштабированию.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-01-01-v-22.53.49.png\" width=\"2546\" height=\"936\" alt=\"\" \/>\n<\/div>\n<hr \/>\n<h3>Часть 1. Фундамент: Запуск Dokku в Portainer<\/h3>\n<p>Dokku — это Docker-контейнер, который управляет другими Docker-контейнерами. Чтобы он заработал на NAS, его нужно правильно запустить. Я использовал Portainer Stack.<\/p>\n<h4>Docker Compose конфигурация<\/h4>\n<p>Вот рабочий `docker-compose.yml`, который решает главную проблему — доступность приложений из локальной сети.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\"># version: '3.2'\nservices:\n  agent:\n    image: dokku\/dokku:${VERSION}\n    pid: host.  # ⚠️ важно для работы на NAS\n    network_mode: bridge # ⚠️ важно для работы на NAS\n    environment:\n      DOKKU_HOSTNAME: ${DOKKU_HOSTNAME}\n      DOKKU_HOST_ROOT: ${DOKKU_HOST_ROOT}\n    volumes:\n      - \/var\/run\/docker.sock:\/var\/run\/docker.sock\n      - ${VOLUME_PATH:-\/var\/lib\/dokku}:\/mnt\/dokku\n    ports:\n      - &quot;3022:22&quot; # ⚠️ важно для работы через ssh и что бы не конфликтовал с 22 \n      - &quot;80:80&quot;    # Внешний порт 80 -&gt; порт 80 внутри контейнера Dokku\n      - &quot;443:443&quot;<\/code><\/pre><p><b>Нюансы сети:<\/b><br \/>\nЧтобы обращаться к приложениям по красивым домегам типа `my-app.dokku.datahub.mother`, я настроил <b>AdGuard Home<\/b> в качестве локального DNS-сервера (фильтры получил бонусом – где-то 20% это всякие счетчики, ужас:). Добавил правило Rewrite: `*.dokku.datahub.mother` → `192.168.0.20` (IP моего NAS). Теперь все поддомены (приложения) автоматически ведут на Dokku.<\/p>\n<p>Также для удобства я настроил `~\/.ssh\/config` на ноутбуке, чтобы не вводить порты вручную:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">Host dokku.datahub.mother\n  HostName 192.168.0.20\n  Port 3022\n  User dokku<\/code><\/pre><p>ну и ключ сам так можно добавить<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">echo &quot;ВАШ_ПУБЛИЧНЫЙ_КЛЮЧ&quot; | dokku ssh-keys:add dokku<\/code><\/pre><hr \/>\n<h3>Часть 2. Приложение “my-first-app”: Новогоднее гадание<\/h3>\n<p>Для теста я написал простое Flask-приложение, которое рассчитывает ваш возраст в наступающем 2026 году.<\/p>\n<h4>Код приложения (`app.py`)<\/h4>\n<pre class=\"e2-text-code\"><code class=\"\">from flask import Flask, request\n\napp = Flask(__name__)\n\n@app.route('\/')\ndef home():\n    return &quot;&quot;&quot;\n    &lt;h1&gt;Приветствую в игре Нового 2026 года! 🎉&lt;\/h1&gt;\n    &lt;p&gt;Это веселая интерактивная игра в честь Нового года. Угадай свой возраст на 1 января 2026!&lt;\/p&gt;\n    &lt;p&gt;Введи свой год рождения:&lt;\/p&gt;\n    &lt;form action=&quot;\/result&quot; method=&quot;get&quot;&gt;\n        &lt;input type=&quot;number&quot; name=&quot;birth_year&quot; min=&quot;1900&quot; max=&quot;2025&quot; required&gt;\n        &lt;button type=&quot;submit&quot;&gt;Угадать возраст на Новогодний 2026!&lt;\/button&gt;\n    &lt;\/form&gt;\n    &quot;&quot;&quot;\n\n@app.route('\/result')\ndef result():\n    birth_year = request.args.get('birth_year')\n    if not birth_year or not birth_year.isdigit():\n        return &quot;Ошибка: введи корректный год рождения!&quot;\n    \n    birth_year = int(birth_year)\n    age_in_2026 = 2026 - birth_year\n    return f&quot;&quot;&quot;\n    &lt;h2&gt;Результат: 🎇&lt;\/h2&gt;\n    &lt;p&gt;В 2026 году тебе будет {age_in_2026} лет!&lt;\/p&gt;\n    &lt;p&gt;Счастливого Нового 2026 года! Пусть все твои желания сбудутся!&lt;\/p&gt;\n    &lt;a href=&quot;\/&quot;&gt;Играть снова&lt;\/a&gt;\n    &quot;&quot;&quot;\n\nif __name__ == '__main__':\n    app.run(host='0.0.0.0', port=5000)<\/code><\/pre><h4>Подготовка к деплою<\/h4>\n<p>Чтобы Dokku понял, как запускать это чудо, нужны два файла в корне проекта:<\/p>\n<ol start=\"1\">\n<li><b>`requirements.txt`<\/b> (зависимости):<\/li>\n<\/ol>\n<pre class=\"e2-text-code\"><code class=\"\">Flask==2.3.2\ngunicorn==20.1.0\nWerkzeug==2.3.3<\/code><\/pre><ol start=\"2\">\n<li><b>`Procfile`<\/b> (команда запуска):<\/li>\n<\/ol>\n<pre class=\"e2-text-code\"><code class=\"\">web: gunicorn app:app --bind 0.0.0.0:5000<\/code><\/pre><ol start=\"3\">\n<li><b>`.python-version`<\/b> (опционально, явная версия Python):<\/li>\n<\/ol>\n<pre class=\"e2-text-code\"><code class=\"\">3.11.14<\/code><\/pre><h4>Процесс деплоя<\/h4>\n<p>Все делается через Git, как на “взрослых” платформах:<\/p>\n<ol start=\"1\">\n<li><b>Создаем приложение на сервере:<\/b><\/li>\n<\/ol>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku@dokku.datahub.mother apps:create my-first-app<\/code><\/pre><ol start=\"2\">\n<li><b>Отправляем код:<\/b><\/li>\n<\/ol>\n<pre class=\"e2-text-code\"><code class=\"\">git init\n    git add .\n    git commit -m &quot;Happy New Year 2026 version&quot;\n    git remote add dokku dokku@dokku.datahub.mother:my-first-app\n    git push dokku master<\/code><\/pre><p>Если вы до этого еще что-то деплоили, то лучше проверить куда гит смотрит<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">git remote -v<\/code><\/pre><p>ну и поменяем еще не верное<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">git remote remove dokku<\/code><\/pre><pre class=\"e2-text-code\"><code class=\"\">git init\n    git add .\n    git commit -m &quot;Happy New Year 2026 version&quot;\n    git remote add dokku dokku@dokku.datahub.mother:my-first-app\n    git push dokku master<\/code><\/pre><p>После пуша Dokku сам скачает Python, установит Flask и запустит Gunicorn. Через минуту-две приложение доступно по адресу `<a href=\"http:\/\/my-first-app.dokku.datahub.mother\">http:\/\/my-first-app.dokku.datahub.mother<\/a>`.<\/p>\n<p>Еще нужно домен установить<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku@dokku.datahub.mother domains:set my-first-app my-first-app.dokku.datahub.mother<\/code><\/pre><p>или можно сразу глобально его установить:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku@dokku.datahub.mother domains:set-global dokku.datahub.mother\n# но тогда придется удалить ручную привязку \nssh dokku@dokku.datahub.mother domains:clear my-first-app\n\n# не забыть перебрать nginx ( на всякий случай ) \nssh dokku@dokku.datahub.mother proxy:build-config my-first-app<\/code><\/pre><p>Сертификат сгенерировать<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku@dokku.datahub.mother certs:generate my-first-app my-first-app.dokku.datahub.mother<\/code><\/pre><p>и проверить порты<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku@dokku.datahub.mother ports:report my-first-app<\/code><\/pre><p>если порты не корректные, то можно их установить так:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku@dokku.datahub.mother ports:set my-first-app http:80:5000 https:443:5000<\/code><\/pre><hr \/>\n<h3>Часть 3. Уровень PRO: Скорость (uv) и Marimo<\/h3>\n<p>Аппетит приходит во время еды. После простого Flask-приложения я решил развернуть что-то посерьезнее — Data Science ноутбук на <b>Marimo<\/b>, и столкнулся с реальными сложностями и особенностями. Для примера брал их дело ноутбук <a href=\"https:\/\/marimo.app\">https:\/\/marimo.app<\/a><\/p>\n<h4>1. Ускорение сборки с `uv`<\/h4>\n<p>Стандартный `pip` устанавливает пакеты медленно. Если проект большой, деплой может висеть минутами.<br \/>\nЯ перешел на <b>uv<\/b> — новый менеджер пакетов на Rust.<\/p>\n<p>Вместо `requirements.txt` я использовал `pyproject.toml` и `uv.lock`. Dokku (благодаря современным buildpacks) увидел `uv.lock` и переключился на быстрый режим. Время сборки сократилось <b>в разы<\/b>.<\/p>\n<h4>2. Ловушка масштабирования (Scaling)<\/h4>\n<p>Marimo — это <b>stateful<\/b> приложение (хранит состояние в памяти). Flask, который мы делали выше — <b>stateless<\/b>.<\/p>\n<p>Когда я задеплоил Marimo, Dokku по умолчанию все было хорошо, но потом я решил масштабировать его и сделал так<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku@dokku.datahub.mother ps:scale my-marimo-app web=3<\/code><\/pre><p>далее Dokku запустил <b>3 копии<\/b> контейнера (`web=3`).<br \/>\nНачался хаос:<\/p>\n<ul>\n<li>Интерфейс открывался.<\/li>\n<li>При нажатии кнопок вылетала ошибка `Invalid server token`.<\/li>\n<\/ul>\n<p><b>Почему?<\/b> Браузер загружал страницу с *Контейнера 1*, а WebSocket-запрос улетал в *Контейнер 2*, который ничего не знал про мою сессию.<\/p>\n<p><b>Решение:<\/b><br \/>\nДля интерактивных приложений (Streamlit, Marimo, Jupyter) всегда принудительно ставьте одну реплику:<br \/>\nНу ли придется делать липкие сессии на nginx или еще что-то.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku.datahub.mother ps:scale my-marimo-app web=1 # все вернуло в рабочее состояние.<\/code><\/pre><p>А если не хватает мощности — лучше дайте этому единственному контейнеру больше ресурсов, чем пытаться плодить клонов или дайте каждому запускать свой:<\/p>\n<p>Вот так можно установить лимиты или повысить их:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku.datahub.mother resource:limit my-marimo-app --memory 2G --cpu 2<\/code><\/pre><h4>3. SSL в локальной сети<\/h4>\n<p>Браузеры блокируют микрофон и иногда WebSockets на HTTP-сайтах. Для локальной сети Let’s Encrypt не сработает (нет публичного IP), ну и его чуть сложнее запускать.<br \/>\nЯ решил вопрос генерацией самоподписанного сертификата одной командой Dokku:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ssh dokku.datahub.mother certs:generate my-first-app my-first-app.dokku.datahub.mother<\/code><\/pre><p>Браузер ругается, но приложение работает полноценно.<\/p>\n<hr \/>\n<p>Еще я прогнал стресс тесты<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">ab -n 10000 -k -c 2000 ...<\/code><\/pre><p>Много они не показали, решением было подкрутить nginx, настроить кеш ssl, горизонтальное масштабирование не приносило больших результатов. я упирался в ограничения клиента при тестах нагрузки.<\/p>\n<h3>Итог<\/h3>\n<p>Dokku на домашнем сервере — это отличный инструмент.<\/p>\n<ul>\n<li><b>Для простых API (Flask\/FastAPI):<\/b> Работает “из коробки” идеально.<\/li>\n<li><b>Для сложных задач:<\/b> Использование `uv` делает работу комфортной, а понимание разницы между *Stateless* и *Stateful* приложениями спасает от занудных ошибок и отладки.<\/li>\n<\/ul>\n<p>Теперь my-first-app готово предсказывать возраст всем гостям на Новый год, а сервер готов к новым экспериментам! 🎄 Пожалуй оставлю его для будущих экспериментов. Прижился как-то быстро. Кстати у Dokku есть коммерческая PRO версия, а точнее не версия, а полноценный UI с кнопочками и стоит он 900$. <a href=\"https:\/\/dokku.com\/docs\/enterprise\/pro\/\">https:\/\/dokku.com\/docs\/enterprise\/pro\/<\/a><\/p>\n<p>Пора чего-нибудь накатить новогоднего еще :)<\/p>\n",
            "date_published": "2026-01-01T22:59:46+03:00",
            "date_modified": "2026-01-05T13:51:37+03:00",
            "tags": [
                "Dev",
                "DevOps",
                "IT",
                "Management"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-01-01-v-22.56.17.png",
            "_date_published_rfc2822": "Thu, 01 Jan 2026 22:59:46 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "307",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "highlight\/highlight.js",
                    "highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-01-01-v-22.56.17.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-01-01-v-22.53.49.png"
                ]
            }
        },
        {
            "id": "304",
            "url": "https:\/\/gavrilov.info\/all\/epoha-tolstogo-brauzera-i-revolyuciya-lokalnyh-dannyh-na-wasm\/",
            "title": "Эпоха «Толстого» браузера и революция локальных данных на WASM",
            "content_html": "<p>В истории IT-архитектуры маятник всегда качался между двумя крайностями: централизацией и децентрализацией. Сначала были мейнфреймы (центр), затем «толстые» клиенты на ПК (локальные вычисления), а потом пришла эра веб-приложений, и индустрия массово мигрировала в Облака.<\/p>\n<p>Мы привыкли считать браузер лишь «тонким окном», интерфейсом, где вся магия, сложные вычисления и хранение происходят где-то далеко — на серверах AWS или Google. Но сегодня правила игры меняются. Благодаря технологиям WebAssembly (WASM), современному «железу» и новым подходам, браузер превращается в полноценную операционную систему для анализа данных или еще чего-то <a href=\"https:\/\/blog.openreplay.com\/ru\/%D1%80%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE-%D0%BD%D0%BE%D0%B2%D0%B8%D1%87%D0%BA%D0%B0-%D0%BB%D0%BE%D0%BA%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0\">blog.openreplay.com<\/a>. Посмотрите статью о “Руководство по Разработке Local-First Приложений”.<\/p>\n<h3>Почему мы уходили в облака и почему возвращаемся?<\/h3>\n<p><b>Эра миграции в облака:<\/b><br \/>\nВ 2010-х локальные машины были «бутылочным горлышком». Чтобы обработать гигабайты данных, требовались серверные стойки. Облака давали бесконечную масштабируемость. Архитектура сводилась к простой формуле: *данные пользователя → загрузка через сеть (latency) → обработка на сервере ($$$) → результат обратно клиенту*.<\/p>\n<p><b>Проблемы сегодняшнего дня:<\/b><\/p>\n<ol start=\"1\">\n<li><b>Избыточность мощностей:<\/b> Современный ноутбук аналитика (даже базовый MacBook Air на M-чипе) обладает вычислительной мощностью, сопоставимой с сервером десятилетней давности. Эти ресурсы простаивают, пока компании платят за облачные CPU.<\/li>\n<li><b>Сетевые задержки и стоимость:<\/b> Передать CSV-файл на 2 ГБ в облако для простой фильтрации или агрегации — это долго и дорого (ingress\/egress трафик).<\/li>\n<li><b>Приватность:<\/b> Передача чувствительных отчетов или персональных данных на чужой сервер для разового анализа всегда несет риски утечки и нарушений регуляторики.<\/li>\n<\/ol>\n<p><b>Решение: Приложения Local-First<\/b><\/p>\n<p>Технология WebAssembly (WASM) позволила запускать нативный код (C++, Rust, Go) прямо в песочнице браузера со скоростью, близкой к нативной <a href=\"https:\/\/habr.com\/ru\/articles\/892052\">habr.com<\/a>. Это породило новый класс ПО, которое выглядит как веб-сайт, но работает как десктопное приложение. Вы заходите на страницу, она загружает легковесный движок, и далее вы можете отключить интернет — приложение продолжит «перемалывать» ваши данные локально.<\/p>\n<h3>Новые герои: Сервер внутри вкладки<\/h3>\n<p>Уже сейчас существуют продукты, которые меняют представление о работе с данными. Они объединяют UX веб-приложений с мощностью десктопного софта, создавая ощущение, что сервер находится прямо у вас в RAM.<\/p>\n<h4>1. DataKit — Швейцарский нож аналитика<\/h4>\n<p>Проект <b>DataKit.page<\/b> — яркий пример такой архитектуры. Это не просто “просмотрщик файлов”, это полноценная ETL\/Analytics платформа, живущая в вашем браузере.<\/p>\n<ul>\n<li><b>Как это работает:<\/b> Вы перетаскиваете массивные файлы (CSV, JSON, Excel, Parquet) в окно. Они <b>не загружаются<\/b> на внешний сервер. Браузер получает доступ к файлу через `File System Access API`, а движок (основанный на DuckDB WASM) монтирует их виртуально.<\/li>\n<li><b>Функционал:<\/b>\n<ul>\n  <li><b>SQL и Python в одном окне:<\/b> Внутри работает не только SQL-движок, но и Python (через Pyodide). Вы можете использовать `pandas`, `polars`,  `numpy` и строить графики `matplotlib`, обращаясь к данным прямо с вашего диска.<\/li>\n  <li><b>AI на борту:<\/b> Интеграция с локальными LLM (через Ollama) или облачными провайдерами позволяет писать запросы на естественном языке, при этом сама схема и данные остаются у вас.<\/li>\n  <li><b>Умные форматы и коннекторы:<\/b> Платформа «нативно» понимает Parquet и вложенные JSON, автоматически определяя типы данных и аномалии. Кроме того, она может подключаться к S3, Google Sheets и базам данных PostgreSQL, выполняя федеративные запросы.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h4>2. DuckDB Local UI — SQL без инсталляции<\/h4>\n<p>Команда DuckDB в сотрудничестве с MotherDuck выпустила официальный локальный UI, работающий через расширение. Это прямой ответ на боль пользователей консольных утилит и отличный пример гибридного подхода <a href=\"https:\/\/habr.com\/ru\/companies\/cinimex\/articles\/913878\">habr.com<\/a>.<\/p>\n<ul>\n<li><b>Сценарий:<\/b> Раньше, чтобы поработать с локальной базой данных, нужно было либо мучиться в CLI, либо ставить тяжелый DBeaver. Теперь одной командой `duckdb -ui` или SQL-вызовом `CALL start_ui();` запускается локальный веб-сервер и открывается современный Notebook-интерфейс.<\/li>\n<li><b>Гибридность:<\/b> Вы работаете локально, но интерфейс имеет встроенную бесшовную интеграцию с облачным сервисом MotherDuck. Если для разового анализа локальных ресурсов достаточно, вы делаете это приватно. Как только требуется коллаборация или более мощные вычисления, вы можете переключить контекст выполнения в облако в том же окне.<\/li>\n<\/ul>\n<h4>3. Marimo – тетрадки, почти тот же подход имеет<\/h4>\n<p><a href=\"https:\/\/gavrilov.info\/all\/tetradki-nashe-vsyo-marimo-io-i-utochkadb\/\">https:\/\/gavrilov.info\/all\/tetradki-nashe-vsyo-marimo-io-i-utochkadb\/<\/a><\/p>\n<h4>3. PGlite и PondPilot — Postgres и SQL-песочницы<\/h4>\n<ul>\n<li><b>PGlite:<\/b> Этот проект идет еще дальше и компилирует полноценный PostgreSQL в WASM, позволяя запускать его в браузере или Node.js без эмуляции ОС <a href=\"https:\/\/habr.com\/ru\/articles\/873112\">habr.com<\/a>. Это идеально для тестирования, прототипирования и создания приложений, которые требуют совместимости с Postgres.<\/li>\n<li><b>PondPilot:<\/b> Пример open-source SQL-редактора, построенного вокруг DuckDB-WASM <a href=\"https:\/\/habr.com\/ru\/articles\/913682\">habr.com<\/a>. Он позволяет быстро анализировать локальные файлы (CSV, Parquet, JSON), сохраняет историю, поддерживает вкладки и даже предлагает виджет для встраивания интерактивных SQL-примеров в блоги и документацию.<\/li>\n<\/ul>\n<h3>Сдвиг парадигмы: От DBeaver к Браузеру<\/h3>\n<p>Многие аналитики и инженеры привыкли к классическим клиентам баз данных (DBeaver, DataGrip). Это мощные, но «тяжелые» инструменты, требующие установки, настройки драйверов и обновлений. Новый WASM-тренд предлагает более гибкую альтернативу.<\/p>\n<p><b>Сценарий «Мгновенной аналитики»:<\/b><br \/>\nПредставьте, что вам прислали ссылку на лог-файл в S3 размером 5 ГБ или Parquet-дамп.<\/p>\n<ul>\n<li><b>Старый путь:<\/b> Скачать файл → Установить\/открыть DBeaver → Настроить драйвер → Импортировать → Ждать загрузки → Писать SQL.<\/li>\n<li><b>Новый путь (WASM):<\/b> Открыть ссылку веб-приложения → Перетащить файл (или указать S3 URL) → Мгновенно писать SQL.<\/li>\n<\/ul>\n<p>Еще вариант, лог 30ГБ и вы заказали функционал в другой команде, она с радостью сказала, что через два спринта сделает пайплайн за неделю, но ей надо требования. Вы их конечно написали на основе небольшого семпла строк из excel или на основе документации и отдали в разработку. А через месяц получили отличный пайплайн или, который не нужен или его нужно еще доработать.<\/p>\n<p><b>Технологическая магия за кулисами:<\/b><\/p>\n<ol start=\"1\">\n<li><b>Apache Arrow:<\/b> Это скрытый герой революции. Бинарный колоночный формат Arrow позволяет передавать данные из SQL-движка (DuckDB) в JavaScript-интерфейс или Python-ячейку <b>без копирования и сериализации памяти<\/b> (Zero-copy). Это обеспечивает мгновенную реакцию интерфейса на миллионах строк — то, чего раньше было невозможно добиться при работе с DOM. (все помним D3JS)<\/li>\n<li><b>Федеративные запросы:<\/b> Локальное приложение умеет «ходить» в интернет. Вы можете написать `SELECT * FROM ‘s3:\/\/my-bucket\/file.parquet’` прямо из браузера. Движок скачает только нужные байты (range requests), обработает их локально и покажет результат. Данные не оседают на промежуточных серверах разработчика софта.<\/li>\n<\/ol>\n<h3>Органическое масштабирование и новая экономика<\/h3>\n<p>Для архитекторов платформ данных этот тренд открывает удивительную экономическую модель <b>«Bring Your Own Compute» или «Client-side computing» (Принеси Свои Вычисления)<\/b>.<\/p>\n<ul>\n<li><b>Масштабирование без усилий:<\/b> Вам не нужно создавать сложный кластер, чтобы тысячи пользователей могли фильтровать свои Excel-файлы. Вы просто хостите статические JS\/WASM файлы на CDN.<\/li>\n<li><b>Органическая нагрузка:<\/b> Вычислительная мощность вашего “облака” растет линейно с количеством пользователей, потому что каждый новый пользователь приносит свой CPU и RAM. Пользователи выключают компьютеры — ваше “облако” естественным образом уменьшается.<\/li>\n<li>Коллаборация и Воспроизводимость:**\n<ul>\n  <li>*Разовая задача:* Сделал анализ локально, закрыл вкладку — данные исчезли из памяти (полная приватность).<\/li>\n  <li>*Командная работа:* Написал SQL\/Python код локально, сохранил его (текст скрипта весит килобайты) и отправил коллеге. Коллега открыл ту же ссылку, подгрузился код, и магия вычислений произошла уже на его машине над теми же данными (если они в общем S3) или над его локальной копией.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h3>Итого<\/h3>\n<p>Мы движемся к миру, где браузер — это не тонкий клиент, а <b>универсальная песочница для гибридных вычислений<\/b>.<\/p>\n<p><b>Разработчикам и Архитекторам:<\/b><\/p>\n<ol start=\"1\">\n<li><b>Присмотритесь к Serverless 2.0:<\/b> Истинный `serverless` — это не AWS Lambda, за которую вы платите. Это когда сервера нет вообще, а код исполняется на клиенте (`client-side computing`). Это дешевле, быстрее для пользователя и безопаснее, удобно разрабатывать и обновлять код.<\/li>\n<li><b>Privacy-first как преимущество:<\/b> Позиционируйте такие решения как безопасные по умолчанию. Аргумент “Ваши данные никогда не покидают ваш компьютер” становится решающим для Enterprise-сектора.<\/li>\n<li><b>Гибридная архитектура:<\/b> Не отказывайтесь от сервера полностью. Пусть браузер берет на себя интерактивную работу, парсинг и предобработку, а сервер подключается для тяжелых “батчей” или работы с петабайтами данных в том же привычном окне.<\/li>\n<\/ol>\n<p><b>Пользователям и Аналитикам:<\/b><\/p>\n<ol start=\"1\">\n<li><b>Осваивайте инструменты:<\/b> Попробуйте <a href=\"https:\/\/datakit.page,\">https:\/\/datakit.page,<\/a> <a href=\"https:\/\/app.pondpilot.io\">https:\/\/app.pondpilot.io<\/a> или <a href=\"https:\/\/shell.duckdb.org\">DuckDB WASM Shell<\/a> для разведочного анализа данных. Это часто быстрее, чем запускать локальный Jupyter.<\/li>\n<li><b>Используйте облачные хранилища напрямую:<\/b> Учитесь подключать S3, Google Sheets и другие облачные источники напрямую к таким инструментам. Это дает мощь облачного хранения в сочетании со скоростью и приватностью локального интерфейса.<\/li>\n<\/ol>\n<p>Ренессанс локальных вычислений начался. Ваш браузер способен на большее, чем просто отображать HTML. Он становится вашей персональной дата-лабораторией.<\/p>\n",
            "date_published": "2025-12-13T01:20:55+03:00",
            "date_modified": "2025-12-13T01:20:35+03:00",
            "tags": [
                "Architecture",
                "Data",
                "Dev",
                "Platform"
            ],
            "_date_published_rfc2822": "Sat, 13 Dec 2025 01:20:55 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "304",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "302",
            "url": "https:\/\/gavrilov.info\/all\/obzor-pg-clickhouse-kak-obedinit-mosch-clickhouse-i-udobstvo-pos\/",
            "title": "Обзор pg_clickhouse: Как объединить мощь ClickHouse и удобство PostgreSQL",
            "content_html": "<p>Недавно компания ClickHouse представила новый инструмент — расширение <b>pg_clickhouse<\/b>. Это событие стало ответом на одну из самых частых болей разработчиков: сложность миграции аналитических запросов из классических реляционных баз данных в колоночные аналитические СУБД.<\/p>\n<p>Оригинал статьи: <a href=\"https:\/\/clickhouse.com\/blog\/introducing-pg_clickhouse\">A Postgres extension for querying ClickHouse<\/a><\/p>\n<p>или берем сразу тут: <a href=\"https:\/\/github.com\/ClickHouse\/pg_clickhouse\/releases\">https:\/\/github.com\/ClickHouse\/pg_clickhouse\/releases<\/a><\/p>\n<p>В этой статье мы разберем, что представляет собой этот инструмент, в чем его фундаментальный смысл для архитектуры приложений и куда проект хочет двигаться дальше.<\/p>\n<h3>Проблема: Данные переехали, а запросы остались<\/h3>\n<p>Типичный сценарий роста стартапа выглядит так: приложение строится на PostgreSQL. В какой-то момент данных (логов, метрик, транзакций) становится так много, что аналитические отчеты начинают тормозить. Обычные реплики для чтения (read replicas) перестают спасать.<\/p>\n<p>Команда принимает решение внедрить ClickHouse. Перенос данных сейчас решается просто (например, с помощью ClickPipes), но возникает другая проблема:<br \/>\n<b>Как быть с тысячами строк SQL-кода в ORM, дашбордах и скриптах, которые написаны под синтаксис Postgres?<\/b><\/p>\n<p>Переписывание всей логики приложения под диалект ClickHouse — это месяцы работы и риск новых багов. Именно эту проблему решает `pg_clickhouse`.<\/p>\n<h3>Что такое pg_clickhouse?<\/h3>\n<p><b>pg_clickhouse<\/b> — это расширение для PostgreSQL (Foreign Data Wrapper — FDW), которое позволяет создавать в Postgres «внешние таблицы», фактически ссылающиеся на таблицы в ClickHouse.<\/p>\n<p><b>Суть технологии:<\/b> Вы пишете запросы на привычном SQL диалекте PostgreSQL, обращаясь к этим таблицам. Расширение на лету транслирует запрос в диалект ClickHouse, отправляет его на исполнение в аналитическую базу и возвращает результат обратно в Postgres.<\/p>\n<p>Для приложения это выглядит прозрачно: таблицы ClickHouse могут находиться просто в отдельной схеме (schema). Достаточно изменить путь поиска (`search_path`), и старые запросы начнут работать с данными, лежащими в ClickHouse.<\/p>\n<h3>В чем «соль»: Технология Pushdown<\/h3>\n<p>Главная ценность и сложность такого расширения заключается не просто в соединении двух баз, а в эффективности этого соединения. Этот механизм называется <b>Pushdown<\/b> (спуск или делегирование вычислений).<\/p>\n<p>Если вы делаете запрос `SELECT sum(price) FROM orders`, есть два пути его выполнения:<\/p>\n<ol start=\"1\">\n<li><b>Плохой путь:<\/b> Postgres выкачивает *все* миллионы строк из ClickHouse и сам считает сумму. Это уничтожает весь смысл аналитической базы.<\/li>\n<li><b>Путь pg_clickhouse:<\/b> Расширение понимает, что это агрегация, и отправляет в ClickHouse команду «посчитай сумму». Обратно по сети возвращается только одна цифра.<\/li>\n<\/ol>\n<h4>Умная трансляция функций<\/h4>\n<p>Авторы `pg_clickhouse` пошли дальше простой трансляции. Они научили расширение переводить специфические функции Postgres в аналоги ClickHouse, даже если синтаксис кардинально отличается.<\/p>\n<p>*Пример:*<br \/>\nВ Postgres есть функция для расчета медианы: `percentile_cont(0.5) WITHIN GROUP (ORDER BY price)`.<br \/>\nВ ClickHouse такой синтаксис не поддерживается.<br \/>\n`pg_clickhouse` автоматически переписывает это в нативную функцию ClickHouse: `quantile(0.5)(price)`.<\/p>\n<p>Также поддерживается трансляция конструкции `FILTER (WHERE ...)` в специфичные для ClickHouse комбинаторы `-If` (например, `sumIf`).<\/p>\n<h4>Ускорение подзапросов (Semi-Join)<\/h4>\n<p>В версии 0.1.0 была реализована поддержка <b>SEMI JOIN Pushdown<\/b>. Это критически важно для запросов с конструкцией `WHERE ... IN (SELECT ...)` или `EXISTS`. Тесты на бенчмарке TPC-H показали, что благодаря этому время выполнения сложных запросов сократилось с нескольких секунд (или даже минут) до миллисекунд, так как фильтрация теперь происходит на стороне ClickHouse.<\/p>\n<h3>Планы развития (Roadmap)<\/h3>\n<p>Проект находится в стадии активной разработки (версия 0.1.0), и команда ClickHouse нацелена на полное покрытие аналитических сценариев.<\/p>\n<p><b>Ключевые пункты плана:<\/b><\/p>\n<ol start=\"1\">\n<li><b>Полное покрытие TPC-H и ClickBench:<\/b> Оптимизация планировщика, чтобы все стандартные аналитические бенчмарки выполнялись с максимальным pushdown-ом.<\/li>\n<li><b>Расширенная поддержка функций:<\/b> Трансляция *всех* агрегатных и обычных функций PostgreSQL в их эквиваленты в ClickHouse.<\/li>\n<li><b>DML операции:<\/b> Поддержка легковесных удалений (`DELETE`) и обновлений (`UPDATE`), а также пакетной вставки данных через `COPY`.<\/li>\n<li><b>Управление настройками:<\/b> Возможность передавать настройки ClickHouse (settings) через команды создания пользователей или серверов в Postgres.<\/li>\n<li><b>Passthrough-режим:<\/b> Возможность отправить произвольный SQL-запрос (на диалекте ClickHouse) и получить результат в виде таблицы, обходя парсер Postgres.<\/li>\n<\/ol>\n<h3>Заключение<\/h3>\n<p>`pg_clickhouse` — это попытка построить «лучшее из двух миров»: взять скорость колоночной СУБД и объединить её с богатой экосистемой и инструментарием PostgreSQL. Это позволяет разработчикам плавно мигрировать нагрузку, не переписывая приложение с нуля, и оставляет Postgres в качестве единой точки входа для данных.<\/p>\n",
            "date_published": "2025-12-12T23:27:54+03:00",
            "date_modified": "2025-12-12T23:32:31+03:00",
            "tags": [
                "Data",
                "Data Engineer",
                "Database",
                "Dev"
            ],
            "_date_published_rfc2822": "Fri, 12 Dec 2025 23:27:54 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "302",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "300",
            "url": "https:\/\/gavrilov.info\/all\/kubevela-sovremennaya-dostavka-prilozheniy\/",
            "title": "KubeVela: Современная доставка приложений",
            "content_html": "<p>В мире Cloud-Native технологий Kubernetes стал операционной системой облака. Однако, как было отмечено в материалах про Rainbond, «ванильный» Kubernetes сложен для разработчиков. Если Rainbond решает эту проблему, предлагая готовый <b>PaaS «из коробки»<\/b> с упором на UI, то <b>KubeVela<\/b> подходит к задаче с другой стороны: это <b>двигатель для построения собственной платформы<\/b> (Platform Engine), основанный на модели OAM (Open Application Model).<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-01.09.35.png\" width=\"558\" height=\"632\" alt=\"\" \/>\n<div class=\"e2-text-caption\"><a href=\"https:\/\/kubevela.io\">https:\/\/kubevela.io<\/a><\/div>\n<\/div>\n<p>KubeVela позволяет создавать простые и ориентированные на приложение (Application-centric) абстракции, сохраняя при этом полную гибкость и управляемость через код (Infrastructure as Code).<\/p>\n<h3>Основная философия: OAM и разделение ответственности<\/h3>\n<p>В основе KubeVela лежит стандарт <b>OAM (Open Application Model)<\/b>. Эта модель разделяет ответственность между двумя ролями:<\/p>\n<ol start=\"1\">\n<li><b>Разработчиĸи (Developers):<\/b> Описывают <b>что<\/b> нужно запустить (образ контейнера, порт, параметры запуска).<\/li>\n<li><b>Платформенные инженеры (Platform Engineers):<\/b> Описывают <b>ĸаĸ<\/b> это должно работать (инфраструктура, политики масштабирования, Ingress, безопасность).<\/li>\n<\/ol>\n<p>Математически модель приложения в KubeVela можно выразить формулой:<\/p>\n<p>$$ Application = Components + Traits + Workflow $$<\/p>\n<p>Где:<\/p>\n<ul>\n<li><b>Components<\/b>: Основная рабочая нагрузка (Workload). Например, Docker-образ, Helm-чарт или даже Terraform-модуль.<\/li>\n<li><b>Traits<\/b> (Свойства\/Черты): Операционные характеристики, подключаемые к компоненту. Например: `ingress`, `scaler`, `sidecar`.<\/li>\n<li><b>Workflow<\/b>: Цепочка шагов доставки (Deploy -> Test -> Promote).<\/li>\n<\/ul>\n<h4>Пример манифеста KubeVela<\/h4>\n<p>Вместо десятков Kubernetes-ресурсов (Deployment, Service, Ingress, HPA), разработчик пишет один упрощенный файл:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">apiVersion: core.oam.dev\/v1beta1\nkind: Application\nmetadata:\n  name: website\nspec:\n  components:\n    - name: frontend\n      type: webservice\n      properties:\n        image: nginx\n      traits:\n        - type: scaler\n          properties:\n            replicas: 3\n        - type: gateway\n          properties:\n            domain: test.example.com<\/code><\/pre><h3>Сравнение: KubeVela vs Rainbond<\/h3>\n<p>Основываясь на прошлой статье про <a href=\"https:\/\/gavrilov.info\/all\/rainbond-oblachnaya-platforma-dlya-upravleniya-prilozheniyami\/\">Rainbond<\/a>, сделаем детальное сравнение. Оба инструмента решают проблему сложности Kubernetes, но нацелены на разные аудитории.<\/p>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td style=\"text-align: center\">Хараĸтеристиĸа<\/td>\n<td style=\"text-align: center\">Rainbond<\/td>\n<td style=\"text-align: center\">KubeVela<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Философия<\/b><\/td>\n<td style=\"text-align: center\"><b>No-Code \/ Low-Code PaaS.<\/b> Готовая платформа с полным UI. Ориентация на визуальное управление.<\/td>\n<td style=\"text-align: center\"><b>Platform Engine \/ IaC.<\/b> Инструментарий для создания платформы. Ориентация на GitOps и конфигурацию как код.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Входной порог<\/b><\/td>\n<td style=\"text-align: center\"><b>Очень низкий.<\/b> Не нужно знать Kubernetes. Можно собрать приложение из `.jar` или исходного кода одной кнопкой.<\/td>\n<td style=\"text-align: center\"><b>Средний.<\/b> Требует понимания концепций OAM. Инженерам платформы нужно знать CUE (язык конфигурации).<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Гибĸость<\/b><\/td>\n<td style=\"text-align: center\">Ограничена возможностями UI платформы. Сложно кастомизировать внутреннюю логику деплоя нестандартных вещей.<\/td>\n<td style=\"text-align: center\"><b>Высочайшая.<\/b> Любая абстракция настраивается через X-Definitions (на языке CUE). Можно описать любой ресурс K8s или Terraform.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Интеграция IaC<\/b><\/td>\n<td style=\"text-align: center\">Базируется на внутренних механизмах.<\/td>\n<td style=\"text-align: center\">Нативная интеграция с <b>Terraform<\/b>. KubeVela может разворачивать облачные базы данных (AWS RDS, Cloud SQL) как часть приложения.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Multi-cluster<\/b><\/td>\n<td style=\"text-align: center\">Есть управление несколькими кластерами, но фокус на единой панели управления.<\/td>\n<td style=\"text-align: center\"><b>Сильная сторона.<\/b> Мощный движок развертывания приложений сразу в несколько кластеров с политиками (Placement Policies).<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Для ĸого<\/b><\/td>\n<td style=\"text-align: center\">SMB, стартапы, команды без сильной экспертизы в K8s, желающие получить опыт Heroku на своих серверах.<\/td>\n<td style=\"text-align: center\">Enterprise, Platform Engineering команды, желающие построить <b>свой<\/b> внутренний PaaS (IDP) по стандартам Spotify\/Netflix.<\/td>\n<\/tr>\n<\/table>\n<h4>Сравнение с другими аналогами<\/h4>\n<ol start=\"1\">\n<li><b>Crossplane<\/b>:\n<ul>\n  <li><b>Crossplane<\/b> фокусируется на «Инфраструктуре» (создание баз данных, кластеров, сетей в облаках через K8s API).<\/li>\n  <li><b>KubeVela<\/b> фокусируется на «Приложении».<\/li>\n  <li><b>Итог:<\/b> Они часто используются вместе. KubeVela использует Crossplane для заказа ресурсов.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<ol start=\"2\">\n<li><b>ArgoCD \/ Flux (GitOps)<\/b>:\n<ul>\n  <li>Это инструменты непрерывной доставки (CD), которые синхронизируют Git и K8s.<\/li>\n  <li>KubeVela <b>может<\/b> использовать их под капотом или использовать свой собственный Workflow-контроллер для сложных сценариев (например, «засуспендить деплой, пока не пройдет тест, затем отправить уведомление в Slack»).<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<ol start=\"3\">\n<li><b>Backstage<\/b>:\n<ul>\n  <li>Backstage — это «Портал» (Frontend). KubeVela — это «Движок» (Backend).<\/li>\n  <li>Существует плагин `vela-backstage`, который позволяет визуализировать приложения KubeVela внутри интерфейса Backstage. Это идеальная связка для построения IDP.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<h3>Ключевые возможности KubeVela<\/h3>\n<h4>1. Программируемая абстраĸция (CUE Language)<\/h4>\n<p>В отличие от Helm, где шаблонизация — это просто подстановка строк, KubeVela использует язык <b>CUE<\/b> (Configure Unify Execute). Это позволяет платформенным инженерам создавать «умные» шаблоны.<\/p>\n<p>Пример логики на CUE внутри KubeVela: «Если пользователь не указал CPU, автоматически поставить `requests: 100m`, но если это ‘prod’ окружение, то поставить `500m`».<\/p>\n<h4>2. Единый Workflow для всего<\/h4>\n<p>KubeVela позволяет оркестрировать не только Kubernetes-ресурсы. В одном пайплайне вы можете:<\/p>\n<ol start=\"1\">\n<li>Создать S3 бакет в AWS (через Terraform\/Crossplane).<\/li>\n<li>Дождаться готовности.<\/li>\n<li>Задеплоить Deployment в Kubernetes.<\/li>\n<li>Отправить уведомление в Telegram.<\/li>\n<\/ol>\n<h4>3. Отсуствие «Config Drift»<\/h4>\n<p>KubeVela активно борется с дрейфом конфигураций, постоянно сверяя желаемое состояние приложения с реальным (State Reconciliation).<\/p>\n<h3>Итог и реĸомендации<\/h3>\n<p>Выбор между Rainbond и KubeVela зависит от того, <b>ĸто<\/b> будет обслуживать платформу и <b>ĸаĸие<\/b> цели стоят перед бизнесом.<\/p>\n<h4>Выбирайте Rainbond, если:<\/h4>\n<ul>\n<li>У вас небольшая или средняя команда разработчиков.<\/li>\n<li>Нет выделенного отдела Platform Engineering \/ DevOps.<\/li>\n<li>Нужно «вчера» перенести легаси (Java\/PHP\/Monolith) в контейнеры без переписывания кода.<\/li>\n<li>Вам нужен визуальный интерфейс для управления связями сервисов и мониторинга без написания YAML.<\/li>\n<li><b>Цель:<\/b> Быстрый Time-to-market с минимальными затратами на инженерию.<\/li>\n<\/ul>\n<h4>Выбирайте KubeVela, если:<\/h4>\n<ul>\n<li>Вы строите серьезный Internal Developer Platform (IDP) в крупной компании.<\/li>\n<li>У вас есть инженеры, знающие Kubernetes, но вы хотите скрыть его сложность от продуктовых разработчиков.<\/li>\n<li>Вам нужен строгий GitOps подход (все через репозиторий).<\/li>\n<li>Требуется гибридное развертывание: часть в K8s, часть в Serverless, часть в облачных RDS.<\/li>\n<li>Вы планируете использовать Backstage в качестве фронтенда.<\/li>\n<li><b>Цель:<\/b> Стандартизация, масштабируемость, полный контроль над абстракциями (Platform as Product).<\/li>\n<\/ul>\n<p><b>Рекомендация по стеĸу для Enterprise:<\/b><br \/>\nДля максимальной эффективности современный стек платформенной инженерии часто выглядит так:<br \/>\n$$ \\text{Backstage (UI)} + \\text{KubeVela (Engine)} + \\text{Crossplane (Infra)} $$<br \/>\nЭта связка дает удобство портала (как в Rainbond), мощь оркестрации (KubeVela) и управление облаком (Crossplane).<\/p>\n",
            "date_published": "2025-12-08T01:10:10+03:00",
            "date_modified": "2025-12-08T01:10:06+03:00",
            "tags": [
                "Dev",
                "DevOps",
                "Programming"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-01.09.35.png",
            "_date_published_rfc2822": "Mon, 08 Dec 2025 01:10:10 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "300",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "highlight\/highlight.js",
                    "highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-01.09.35.png"
                ]
            }
        },
        {
            "id": "299",
            "url": "https:\/\/gavrilov.info\/all\/sravnitelny-analiz-self-hosted-s3-sovmestimyh-hranilisch\/",
            "title": "Сравнительный анализ self-hosted S3-совместимых хранилищ",
            "content_html": "<p>Четкое сравнение семи self-hosted S3-совместимых решений для хранения данных.<\/p>\n<p>Оригинал тут: <a href=\"https:\/\/www.repoflow.io\/blog\/benchmarking-self-hosted-s3-compatible-storage-a-practical-performance-comparison\">Команда RepoFlow. 9 августа 2025 г.<\/a><\/p>\n<p>Локальное (self-hosted) объектное хранилище — это отличный выбор для разработчиков и команд, которые хотят иметь полный контроль над хранением и доступом к своим данным. Независимо от того, заменяете ли вы Amazon S3, размещаете внутренние файлы, создаете CI-конвейер или обслуживаете репозитории пакетов, уровень хранения может значительно повлиять на скорость и стабильность.<\/p>\n<p>Мы протестировали семь популярных решений для объектного хранения, поддерживающих протокол S3. Цель состояла в том, чтобы сравнить их производительность в идентичных условиях, используя реальные операции загрузки и скачивания.<\/p>\n<h3>Тестируемые решения<\/h3>\n<p>Каждое из следующих решений было развернуто с помощью Docker на одном и том же сервере без монтирования томов и без специальной настройки:<\/p>\n<ol start=\"1\">\n<li>`MinIO`<\/li>\n<li>`Ceph`<\/li>\n<li>`SeaweedFS`<\/li>\n<li>`Garage`<\/li>\n<li>`Zenko` (Scality Cloudserver)<\/li>\n<li>`LocalStack`<\/li>\n<li>`RustFS`<\/li>\n<\/ol>\n<h3>Скорость последовательного скачивания<\/h3>\n<p>Средняя скорость скачивания одного файла разного размера.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.42.26.png\" width=\"1270\" height=\"656\" alt=\"\" \/>\n<\/div>\n<p>[Изображение: График скорости последовательного скачивания для малых файлов размером 50 КБ и 200 КБ. По оси Y — скорость в МБ\/с, по оси X — размер файла. Сравниваются Garage, Localstack, Minio, Zenko, Ceph, RustFS, SeaweedFS.]<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.42.57.png\" width=\"1264\" height=\"650\" alt=\"\" \/>\n<\/div>\n<p>[Изображение: График скорости последовательного скачивания для больших файлов размером 10 МБ, 50 МБ, 100 МБ и 1 ГБ. По оси Y — скорость в МБ\/с, по оси X — размер файла. Сравниваются те же решения.]<\/p>\n<h3>Скорость последовательной загрузки<\/h3>\n<p>Средняя скорость загрузки одного файла разного размера.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.43.18.png\" width=\"1278\" height=\"648\" alt=\"\" \/>\n<\/div>\n<p>[Изображение: График скорости последовательной загрузки для малых файлов размером 50 КБ и 200 КБ. По оси Y — скорость в МБ\/с, по оси X — размер файла. Сравниваются те же решения.]<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.43.34.png\" width=\"1252\" height=\"636\" alt=\"\" \/>\n<\/div>\n<p>[Изображение: График скорости последовательной загрузки для больших файлов размером 10 МБ, 50 МБ, 100 МБ и 1 ГБ. По оси Y — скорость в МБ\/с, по оси X — размер файла. Сравниваются те же решения.]<\/p>\n<h3>Производительность листинга<\/h3>\n<p>Измеряет время, необходимое для получения списка всех 2000 тестовых объектов в бакете с использованием разных размеров страницы (100, 500 и 1000 результатов на запрос).<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.44.02.png\" width=\"1280\" height=\"648\" alt=\"\" \/>\n<\/div>\n<p>[Изображение: График производительности листинга. По оси Y — время в мс, по оси X — количество результатов на страницу (100, 500, 1000). Сравниваются те же решения.]<\/p>\n<h3>Скорость параллельной загрузки<\/h3>\n<p>Измеряет время, необходимое для параллельной загрузки нескольких файлов одинакового размера. Скорость загрузки рассчитывается по формуле:<\/p>\n<p>(number of files × file size) ÷ total time<\/p>\n<h4>Скорость параллельной загрузки – файлы 1 МБ<\/h4>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.44.22.png\" width=\"1304\" height=\"748\" alt=\"\" \/>\n<\/div>\n<p>[Изображение: График скорости параллельной загрузки файлов размером 1 МБ. По оси Y — скорость в МБ\/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]<\/p>\n<h4>Скорость параллельной загрузки – файлы 10 МБ<\/h4>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.45.06.png\" width=\"1254\" height=\"650\" alt=\"\" \/>\n<\/div>\n<p>[Изображение: График скорости параллельной загрузки файлов размером 10 МБ. По оси Y — скорость в МБ\/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]<\/p>\n<h4>Скорость параллельной загрузки – файлы 100 МБ<\/h4>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.45.23.png\" width=\"1278\" height=\"652\" alt=\"\" \/>\n<\/div>\n<p>[Изображение: График скорости параллельной загрузки файлов размером 100 МБ. По оси Y — скорость в МБ\/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]<\/p>\n<h3>Скорость параллельного скачивания<\/h3>\n<p>Измеряет время, необходимое для параллельного скачивания нескольких файлов одинакового размера. Скорость скачивания рассчитывается по формуле:<\/p>\n<p>(number of files × file size) ÷ total time<\/p>\n<h4>Скорость параллельного скачивания – файлы 1 МБ<\/h4>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.45.45.png\" width=\"1278\" height=\"650\" alt=\"\" \/>\n<\/div>\n<p>[Изображение: График скорости параллельного скачивания файлов размером 1 МБ. По оси Y — скорость в МБ\/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]<\/p>\n<h4>Скорость параллельного скачивания – файлы 10 МБ<\/h4>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.46.02.png\" width=\"1280\" height=\"644\" alt=\"\" \/>\n<\/div>\n<p>[Изображение: График скорости параллельного скачивания файлов размером 10 МБ. По оси Y — скорость в МБ\/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]<\/p>\n<h4>Скорость параллельного скачивания – файлы 100 МБ<\/h4>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.46.17.png\" width=\"1284\" height=\"670\" alt=\"\" \/>\n<\/div>\n<p>[Изображение: График скорости параллельного скачивания файлов размером 100 МБ. По оси Y — скорость в МБ\/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]<\/p>\n<h3>Как проводились тесты<\/h3>\n<p>Для каждого решения мы:<\/p>\n<ol start=\"1\">\n<li>Загружали и скачивали файлы 7 различных размеров: 50 КБ, 200 КБ, 1 МБ, 10 МБ, 50 МБ, 100 МБ и 1 ГБ.<\/li>\n<li>Повторяли каждую загрузку и скачивание 20 раз для получения стабильных средних значений.<\/li>\n<li>Измеряли среднюю скорость загрузки и скачивания в мегабайтах в секунду (МБ\/с).<\/li>\n<li>Выполняли все тесты на одной и той же машине, используя стандартный Docker-контейнер для каждой системы хранения, без внешних томов, монтирования или кешей.<\/li>\n<\/ol>\n<p>Все решения тестировались в одноузловой конфигурации для обеспечения согласованности. Хотя некоторые системы (например, `Ceph`) спроектированы для лучшей производительности в кластерной среде, мы использовали одинаковые условия для всех решений, чтобы гарантировать справедливое сравнение.<\/p>\n<h3>Заключительные мысли<\/h3>\n<p>Эти результаты показывают, как каждое решение вело себя в нашей конкретной тестовой среде с одним узлом. Их следует рассматривать как относительное сравнение соотношений производительности, а не как абсолютные жесткие значения, которые будут применимы в любой конфигурации.<\/p>\n<p>При выборе подходящего решения для хранения данных учитывайте типичные размеры файлов, которые вы будете хранить, поскольку одни системы лучше справляются с маленькими файлами, а другие преуспевают с большими. Также подумайте об основных возможностях, которые вам требуются, таких как масштабируемость, репликация, долговечность или встроенный графический интерфейс. Наконец, помните, что производительность может сильно отличаться между одноузловыми и многоузловыми кластерами.<\/p>\n<p>Наши тесты предоставляют базовый уровень для понимания того, как эти системы соотносятся в идентичных условиях, но ваша реальная производительность будет зависеть от вашего конкретного оборудования, рабочей нагрузки и конфигурации.<\/p>\n",
            "date_published": "2025-12-08T00:50:17+03:00",
            "date_modified": "2025-12-08T00:50:03+03:00",
            "tags": [
                "big data",
                "Data Engineer",
                "Dev",
                "k3s",
                "Programming",
                "s3"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.42.26.png",
            "_date_published_rfc2822": "Mon, 08 Dec 2025 00:50:17 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "299",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.42.26.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.42.57.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.43.18.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.43.34.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.44.02.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.44.22.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.45.06.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.45.23.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.45.45.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.46.02.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-12-08-v-00.46.17.png"
                ]
            }
        },
        {
            "id": "282",
            "url": "https:\/\/gavrilov.info\/all\/open-source-portaly-razrabotki-i-chto-takoe-idp\/",
            "title": "Open Source порталы разработки и что такое IDP",
            "content_html": "<p>На рынке внутренних порталов разработчика существует один явный лидер в категории open source — <b>Backstage<\/b>. Большинство других популярных решений, таких как Port, являются коммерческими (SaaS) продуктами, хотя они и могут предлагать open source компоненты для интеграции <a href=\"https:\/\/internaldeveloperplatform.org\/developer-portals\/port\/\">https:\/\/internaldeveloperplatform.org\/developer-portals\/port\/<\/a><\/p>\n<p>Поэтому основной фокус в open source сегменте приходится именно на Backstage, который был создан в Spotify и позже передан в Cloud Native Computing Foundation (CNCF).<\/p>\n<h5><b>Ключевое решение: Backstage<\/b><\/h5>\n<p>Backstage — это не готовый продукт, а <b>фреймворк<\/b> для создания собственного портала разработчика <a href=\"https:\/\/cloudomation.com\/cloudomation-blog\/5-internal-developer-portals-and-what-software-engineers-say-about-them\/.\">https:\/\/cloudomation.com\/cloudomation-blog\/5-internal-developer-portals-and-what-software-engineers-say-about-them\/.<\/a> Это его главное преимущество и одновременно главный недостаток. Он предоставляет базовые строительные блоки и архитектуру, на основе которых компании могут построить портал, идеально соответствующий их процессам и инструментам.<\/p>\n<p>Кстати очень интересная статья про порталы, платформы и их различия.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.11.04.png\" width=\"2084\" height=\"1010\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Картинка от портала  Cortex – ну прям огонь сайт у них <a href=\"https:\/\/www.cortex.io.\">https:\/\/www.cortex.io.<\/a><\/div>\n<\/div>\n<p><a href=\"https:\/\/a.gavrilov.info\/data\/posts\/Cloudomation%20Guide%20-%20Building%20Internal%20Developer%20Platforms.pdf\">Cloudomation Guide – Building Internal Developer Platforms.pdf<\/a> есть еще гайд обобщенный.  А основная концепция конечно тут <a href=\"https:\/\/internaldeveloperplatform.org\">https:\/\/internaldeveloperplatform.org<\/a><\/p>\n<p><b>Основные компоненты Backstage:<\/b><\/p>\n<ol start=\"1\">\n<li><b>Software Catalog:<\/b> Единый реестр для всех программных активов компании (микросервисы, библиотеки, веб-сайты, ML-модели и т.д.). Позволяет централизовать метаданные, информацию о владельцах, зависимостях и состоянии.<\/li>\n<li><b>Software Templates (Scaffolder):<\/b> Инструмент для создания новых проектов по заранее подготовленным шаблонам. Это стандартизирует первоначальную настройку сервисов, CI\/CD пайплайнов, репозиториев и т.д.<\/li>\n<li><b>TechDocs:<\/b> Решение для создания, поддержки и отображения технической документации по принципу “docs-as-code”, когда документация хранится вместе с кодом.<\/li>\n<li><b>Плагины:<\/b> Экосистема Backstage строится вокруг плагинов. Существует огромное количество готовых плагинов для интеграции с AWS, Kubernetes, GitHub, CI\/CD системами, системами мониторинга и многими другими. Если нужного плагина нет, его можно разработать самостоятельно.<\/li>\n<\/ol>\n<h4>Сравнение подходов: Build vs. Buy<\/h4>\n<p>Поскольку настоящий open source конкурент у Backstage практически отсутствует, наиболее корректно сравнить его не с другим open source решением, а с подходом использования коммерческих SaaS-платформ, ярким представителем которых является Port.<\/p>\n<ul>\n<li>Port** — это коммерческий продукт, который предлагает готовый к использованию портал. Его философия заключается в гибкой модели данных на основе “blueprints” (шаблонов сущностей) и взаимосвязей между ними. Port позволяет быстро агрегировать данные из различных источников и построить каталог без необходимости развертывания и поддержки сложной инфраструктуры <a href=\"https:\/\/www.qovery.com\/blog\/10-best-internal-developer-portals-to-consider\/\">10-best-internal-developer-portals-to-consider<\/a>. Хотя ядро продукта закрыто, его интеграции и экспортеры данных являются открытыми [internaldeveloperplatform.org](<a href=\"https:\/\/internaldeveloperplatform.org\/developer-portals\/port\/).\">https:\/\/internaldeveloperplatform.org\/developer-portals\/port\/).<\/a><\/li>\n<\/ul>\n<h4>Сравнительная таблица: Backstage vs. Коммерческие IDP (на примере Port)<\/h4>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td style=\"text-align: center\">Критерий<\/td>\n<td style=\"text-align: center\">Backstage (Open Source)<\/td>\n<td style=\"text-align: center\">Коммерческие решения типа Port (SaaS)<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Модель лицензирования<\/b><\/td>\n<td style=\"text-align: center\">Open Source (Apache 2.0). Бесплатно.<\/td>\n<td style=\"text-align: center\">Коммерческая (SaaS). Платная подписка.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Философия \/ Подход<\/b><\/td>\n<td style=\"text-align: center\">Фреймворк для <b>создания<\/b> портала. “Построй свой дом”.<\/td>\n<td style=\"text-align: center\">Готовый продукт для <b>настройки<\/b> портала. “Купи и настрой квартиру”.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Сложность внедрения<\/b><\/td>\n<td style=\"text-align: center\"><b>Высокая.<\/b> Требуется разработка, развертывание и поддержка. Есть кривая обучения [cloudomation.com](<a href=\"https:\/\/cloudomation.com\/cloudomation-blog\/5-internal-developer-portals-and-what-software-engineers-say-about-them\/).\">https:\/\/cloudomation.com\/cloudomation-blog\/5-internal-developer-portals-and-what-software-engineers-say-about-them\/).<\/a><\/td>\n<td style=\"text-align: center\"><b>Низкая \/ Средняя.<\/b> Быстрый старт, не требует своей инфраструктуры.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Требования к команде<\/b><\/td>\n<td style=\"text-align: center\">Нужна выделенная команда платформенных инженеров для разработки и поддержки портала.<\/td>\n<td style=\"text-align: center\">Может управляться одним или несколькими DevOps-инженерами. Не требует навыков фронтенд-разработки.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: right\"><b>Гибкость и кастомизация<\/b><\/td>\n<td style=\"text-align: center\"><b>Максимальная.<\/b> Можно изменить и доработать абсолютно все, создать уникальные плагины и логику.<\/td>\n<td style=\"text-align: center\"><b>Высокая, но ограничена<\/b> возможностями платформы. Кастомизация интерфейса и логики возможна в рамках, заданных вендором.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Инфраструктура<\/b><\/td>\n<td style=\"text-align: center\">Требует собственной инфраструктуры для хостинга (обычно Kubernetes), базы данных, CI\/CD для самого портала.<\/td>\n<td style=\"text-align: center\">Не требует. Хостится и управляется вендором.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Экосистема и интеграции<\/b><\/td>\n<td style=\"text-align: center\">Огромная, управляемая сообществом. Большое количество open source плагинов.<\/td>\n<td style=\"text-align: center\">Управляется вендором. Интеграции создаются вендором, но часто есть открытые API и экспортеры данных.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Общая стоимость владения (TCO)<\/b><\/td>\n<td style=\"text-align: center\"><b>Скрытая и высокая.<\/b> Лицензия бесплатна, но основные затраты — это зарплаты команды разработки и поддержки, а также стоимость инфраструктуры.<\/td>\n<td style=\"text-align: center\"><b>Прозрачная и предсказуемая.<\/b> Основные затраты — стоимость подписки.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Поддержка<\/b><\/td>\n<td style=\"text-align: center\">Сообщество (Slack, GitHub Issues).<\/td>\n<td style=\"text-align: center\">Коммерческая поддержка от вендора (SLA, выделенный менеджер).<\/td>\n<\/tr>\n<\/table>\n<p>Выбор между open source фреймворком вроде `Backstage` и коммерческим продуктом — это классический выбор между <b>“Build” (создавать)<\/b> и <b>“Buy” (покупать)<\/b>.<\/p>\n<ol start=\"1\">\n<li><b>`Backstage` — это стратегическая инвестиция.<\/b> Это мощное решение для крупных или технологически зрелых компаний, у которых уже есть выделенная платформенная команда и которые готовы вкладывать ресурсы в создание идеально подогнанного под себя инструмента. `Backstage` дает полный контроль, избавляет от зависимости от вендора (vendor lock-in) и позволяет решать уникальные задачи, которые не могут покрыть коробочные продукты.<\/li>\n<\/ol>\n<ol start=\"2\">\n<li><b>Коммерческие IDP (такие как Port) — это тактическое решение для быстрого результата.<\/b> Они идеально подходят для малых и средних компаний, или для крупных организаций, которые хотят быстро запустить портал и проверить гипотезы, не формируя для этого отдельную команду разработки. Этот подход обеспечивает быстрый старт, предсказуемые затраты и перекладывает всю головную боль по поддержке и развитию платформы на плечи вендора.<\/li>\n<\/ol>\n<h5>Рекомендации<\/h5>\n<p><b>Выбирайте `Backstage`, если:<\/b><\/p>\n<ul>\n<li>У вас есть (или вы готовы создать) выделенная команда платформенных инженеров.<\/li>\n<li>У вас есть уникальные и сложные внутренние процессы, которые не укладываются в рамки готовых решений.<\/li>\n<li>Вы хотите максимальной гибкости для интеграции со своими самописными инструментами.<\/li>\n<li>Вы — крупная организация, для которой затраты на команду разработки портала оправданы в долгосрочной перспективе.<\/li>\n<li>Принципиально важно избежать зависимости от стороннего вендора.<\/li>\n<\/ul>\n<p><b>Рассмотрите коммерческие решения (типа Port), если:<\/b><\/p>\n<ul>\n<li>Вам нужен результат “здесь и сейчас” с минимальными первоначальными усилиями.<\/li>\n<li>У вас нет ресурсов на формирование команды для разработки собственного портала.<\/li>\n<li>Стандартного или предложенного вендором функционала достаточно для решения ваших задач.<\/li>\n<li>Вы предпочитаете прозрачную модель оплаты (SaaS-подписка) вместо скрытых затрат на разработку и поддержку.<\/li>\n<li>Вам важна гарантированная коммерческая поддержка с четким SLA.<\/li>\n<\/ul>\n<p>Вне зависимости от выбора, начинать следует с определения ключевых проблем разработчиков, которые должен решить портал. Инструмент — это лишь средство для достижения цели, будь то упрощение создания новых сервисов, централизация знаний или автоматизация рутинных задач.<\/p>\n<p>Ниже небольшой гайд на основе дока выше Cloudomation Guide – Building Internal Developer Platforms.pdf<\/p>\n<h4>Руководство<\/h4>\n<h2>Создание внутренних платформ для разработчиков: лучшие практики, инструменты и стратегические выводы для технических лидов<\/h2>\n<p>***<\/p>\n<h4>Кратко о чем все это?<\/h4>\n<p>Ниже представлен обзор внутренних платформ для разработчиков (Internal Developer Platforms, или IDP). Поскольку инженерные команды сталкиваются с растущей сложностью, IDP становятся решением для снижения разногласий между разработкой и эксплуатацией.<\/p>\n<p>Независимо от того, оцениваете ли вы готовые платформы или создаете собственное решение, этот документ предлагает ценные сведения и тщательно подобранные ресурсы, которые помогут вам эффективно пройти путь внедрения IDP.<\/p>\n<p><b>Основные тезисы:<\/b><\/p>\n<ul>\n<li><b>IDP<\/b> — это платформы самообслуживания, созданные инженерами платформ для оптимизации разработки программного обеспечения за счет автоматизации развертываний, конфигураций и управления средами.<\/li>\n<li><b>Преимущества:<\/b> Сокращение времени, затрачиваемого на настройку и отладку, снижение когнитивной нагрузки на разработчиков, повышение надежности и соответствия требованиям, а также более высокая операционная эффективность.<\/li>\n<li>Каждая IDP уникальна, но обычно состоит из фронтенда, бэкенда и других интегрированных инструментов.<\/li>\n<li><b>Ключевые возможности IDP<\/b> должны включать: API, пользовательский интерфейс, автоматизацию, механизмы ограничений (например, политики), документацию и возможность обнаружения сервисов (discoverability).<\/li>\n<li>Для создания по-настоящему целостной IDP необходимо сосредоточиться на интеграции всех необходимых инструментов и сервисов.<\/li>\n<li>При внедрении IDP могут возникнуть следующие <b>проблемы:<\/b> попытка сделать все сразу (и не достичь ничего), нехватка ресурсов и бюджета, невозможность поддерживать каталог программного обеспечения в актуальном состоянии и недостаток коммуникации между людьми.<\/li>\n<li>Обосновывая необходимость внедрения IDP, подкрепляйте свои аргументы данными и связывайте их с рисками и результатами, которые больше всего волнуют ваше руководство.<\/li>\n<\/ul>\n<p>***<\/p>\n<h4>Содержание<\/h4>\n<ol start=\"1\">\n<li>Что такое IDP?<\/li>\n<li>Зачем нужны IDP?<\/li>\n<li>Как работают IDP?<\/li>\n<li>Обоснование необходимости IDP для бизнеса<\/li>\n<li>Лучшие практики для создания IDP<\/li>\n<li>Инструменты платформенной инженерии для создания IDP<\/li>\n<li>3 проблемы при создании IDP<\/li>\n<li>Ресурсы<\/li>\n<\/ol>\n<hr \/>\n<h4>1. Что такое IDP?<\/h4>\n<p>Внутренние платформы для разработчиков (IDP) лежат в основе дисциплины платформенной инженерии (Platform Engineering).<\/p>\n<blockquote>\n<p><b>Пояснение:<\/b><br \/>\nВнутренняя платформа для разработчиков — это, по сути, продукт, предназначенный для разработчиков внутри организации. Она предоставляет им доступ по принципу самообслуживания к технической инфраструктуре и рабочим процессам, таким как конвейеры развертывания или облачные ресурсы. <a href=\"https:\/\/dev.to\/e77\/what-is-an-internal-developer-platforms-17o9\">пост на dev.to<\/a>. Ключевая идея — относиться к своей внутренней платформе как к продукту, а к разработчикам — как к клиентам. <a href=\"https:\/\/dev.to\/akshaymittal143\/from-cloud-chaos-to-developer-delight-your-practical-guide-to-building-an-internal-developer-3o7n\">еще пост с dev.to<\/a>. Это позволяет им не ждать выполнения заявок в отдел эксплуатации и не нести полную ответственность за инфраструктуру, как в модели «you build it, you run it».<\/p>\n<\/blockquote>\n<p>IDP призваны решить вечную проблему, которая преследует всех разработчиков ПО: программное обеспечение чрезвычайно сложно, и ни один человек не может знать всего, что требуется для создания целого программного продукта.<\/p>\n<h5>Понимание внутренних платформ для разработчиков<\/h5>\n<p>На схеме ниже показаны ключевые концепции, лежащие в основе IDP.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.46.02.png\" width=\"996\" height=\"796\" alt=\"\" \/>\n<\/div>\n<ul>\n<li><b>Подходы «Инфраструктура как код» (As-Code Approaches):<\/b> Акцент на автоматизацию и документирование через код.<\/li>\n<li><b>«Золотые пути» (Golden Paths):<\/b> Предоставление заранее определенных, проверенных и поддерживаемых путей для выполнения типовых задач (например, создание нового сервиса, развертывание в среде). Разработчики могут легко следовать этим путям, будучи уверенными в результате.<\/li>\n<li><b>Самообслуживание (Self-Service):<\/b> Позволяет разработчикам самостоятельно использовать платформу без необходимости обращаться в другие команды.<\/li>\n<li><b>Управление как продуктом (Managed like a product):<\/b> У платформы есть свой жизненный цикл выпуска, владелец продукта и дорожная карта развития.<\/li>\n<li><b>Инженеры платформы (Platform Engineers):<\/b> Создают и поддерживают IDP, фокусируясь на ценности для разработчиков.<\/li>\n<li><b>Разработчики ПО (Software Developers):<\/b> Основные пользователи, которые взаимодействуют с IDP.<\/li>\n<\/ul>\n<h5>Функции IDP<\/h5>\n<p>IDP предоставляют функции, которые являются центральными в повседневной работе разработчиков программного обеспечения.<\/p>\n<p>Это лишь примеры функций, которые может иметь IDP. Каждая IDP уникальна для организации, которая ее использует. Часто они создаются с нуля или сильно кастомизируются под нужды компании.<\/p>\n<hr \/>\n<h4>2. Зачем нужны IDP?<\/h4>\n<p>По мере усложнения процесса поставки ПО организации сталкиваются с фрагментированными практиками DevOps, несогласованными рабочими процессами и операционной неэффективностью. От разработчиков ожидают, что они будут управлять инфраструктурой, конвейерами CI\/CD, политиками безопасности и мониторингом, что часто приводит к когнитивной перегрузке и снижению производительности. Именно здесь на помощь приходят платформенная инженерия и IDP.<\/p>\n<h5>Раскрывая мощь IDP<\/h5>\n<ol start=\"1\">\n<li><b>Ускорение циклов разработки:<\/b> Оптимизированное развертывание сокращает время, затрачиваемое на настройку и отладку.<\/li>\n<li><b>Снижение когнитивной нагрузки на разработчиков:<\/b> Упрощенное управление инфраструктурой позволяет сосредоточиться на написании кода.<\/li>\n<li><b>Повышение надежности и соответствия требованиям (Compliance):<\/b> Обеспечивает последовательное применение политик безопасности и соответствия во всех развертываниях.<\/li>\n<li><b>Повышение инженерной эффективности:<\/b> Автоматизирует управление ресурсами, повышая операционную эффективность.<\/li>\n<\/ol>\n<hr \/>\n<h4>3. Как работают IDP?<\/h4>\n<p>Каждая IDP уникальна, но есть некоторые общие характеристики, присущие большинству из них. В самом простом виде каждая IDP состоит примерно из трех «частей»:<\/p>\n<ul>\n<li>Фронтенд IDP<\/li>\n<li>Бэкенд IDP<\/li>\n<li>Множество других инструментов, интегрированных с IDP<\/li>\n<\/ul>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.44.01.png\" width=\"1062\" height=\"432\" alt=\"\" \/>\n<\/div>\n<ul>\n<li><b>Фронтенд:<\/b> Пользовательский интерфейс для доступа разработчиков к IDP. Часто это внутренний портал разработчика (Internal Developer Portal).<\/li>\n<li><b>Бэкенд:<\/b> Управляет интеграцией и автоматизацией с другими инструментами. Эту роль часто выполняет оркестратор платформы.<\/li>\n<li><b>Интегрированные инструменты:<\/b> Различные инструменты, которые работают с IDP для выполнения ключевых процессов (CI\/CD, мониторинг, безопасность и т.д.).<\/li>\n<\/ul>\n<h5>Архитектура<\/h5>\n<p>Следующая диаграмма архитектуры, основанная на модели CNOE (Cloud Native Operational Excellence), дает более детальное представление.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.39.52.png\" width=\"972\" height=\"368\" alt=\"\" \/>\n<\/div>\n<p><a href=\"https:\/\/gavrilov.info\/all\/rainbond-oblachnaya-platforma-dlya-upravleniya-prilozheniyami\/\">Ранее писал про Rainbond китайский, там немного другой акцент, но их архитектура тоже интересная, а так как это опенсорс, то можно свой такой запилить, но переводить придется :) <\/a><\/p>\n<p>В этой диаграмме «Портал разработчика» (`Developer Portal`) является фронтендом IDP. Компонент «Оркестрация рабочих процессов» (`Workflow Orchestration`) будет бэкендом.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.40.18.png\" width=\"946\" height=\"674\" alt=\"\" \/>\n<\/div>\n<p>Ниже приведен более подробный пример архитектуры, показывающий, какие типы инструментов и сервисов могут быть частью IDP, сгруппированные по функциональным уровням (плоскостям).<\/p>\n<h5>Ключевая функциональность IDP<\/h5>\n<p>Основная идея IDP — объединить инструменты, сервисы, конфигурации и другую информацию в одном месте. Инженеры-программисты, а также другие заинтересованные стороны (например, команды эксплуатации) должны иметь возможность использовать IDP как единую точку входа для обнаружения и взаимодействия с приложениями и инфраструктурой компании.<\/p>\n<p>Таким образом, бэкенд IDP, как правило, должен быть сильным в двух типах функциональности: <b>№1 Интеграция<\/b> и <b>№2 Автоматизация<\/b>.<\/p>\n<ul>\n<li><b>Интеграция:<\/b> Объединение разнообразных инструментов и сервисов в единую систему.<\/li>\n<li><b>Автоматизация:<\/b> Связывание и оркестрация существующих конвейеров автоматизации.<\/li>\n<\/ul>\n<hr \/>\n<h4>4. Обоснование необходимости IDP для бизнеса<\/h4>\n<p>По мере того как организации масштабируют и модернизируют поставку своего программного обеспечения, сложность управления инфраструктурой, рабочими процессами разработчиков и управлением (governance) растет экспоненциально.<\/p>\n<p>Внутренняя платформа для разработчиков (IDP) предлагает стратегический ответ на этот вызов, обеспечивая более быструю доставку, более сильное управление и снижение операционных рисков. Однако, чтобы получить одобрение руководства, крайне важно сформулировать преимущества IDP в терминах бизнеса.<\/p>\n<p>Вот как можно обосновать необходимость IDP, обращаясь к четырем ключевым проблемам руководителей: <b>Масштаб, Затраты, Риски и Управление.<\/b><\/p>\n<h5>1. Масштаб: Предоставление организации возможности двигаться быстрее<\/h5>\n<ul>\n<li><b>Проблема руководителя:<\/b> Как мы можем масштабировать наши инженерные команды и поставку ПО без узких мест?<\/li>\n<li><b>Обоснование IDP:<\/b> IDP повышает производительность, абстрагируя повторяющиеся, низкоценные задачи. Она дает командам приложений возможность самостоятельно обслуживать инфраструктуру, CI\/CD, тестирование и развертывание стандартизированным и безопасным способом.<\/li>\n<li><b>Бизнес-результаты:<\/b>\n<ul>\n  <li>Повышение скорости работы команд приложений и организации в целом.<\/li>\n  <li>Быстрая доставка большей бизнес-ценности, поскольку команда разработки может сосредоточиться на коде.<\/li>\n  <li>Возможность масштабирования без линейного увеличения найма DevOps-инженеров.<\/li>\n<\/ul>\n<\/li>\n<li><b>Как это сделать:<\/b> Оцените, сколько времени команды приложений тратят на борьбу с инфраструктурой и инструментами развертывания, и сколько — на работу над своим основным приложением. Используйте эти данные, чтобы обосновать необходимость IDP и показать, как она может высвободить время для основной задачи, что напрямую влияет на бизнес-ценность. Визуализируйте это, чтобы подчеркнуть, каким объемом инфраструктуры приходится управлять командам приложений, и сравните это с тем, как это могло бы выглядеть.<\/li>\n<\/ul>\n<p>*(В оригинальном документе здесь показаны два слайда из презентации PlatformCon23, представляющие “текущее состояние” и “будущее состояние”. Текущее состояние показывает, как команда из 50 разработчиков приложений вынуждена вручную взаимодействовать с разрозненным набором инструментов. Будущее состояние показывает, как команда платформы предоставляет единый, унифицированный слой, который абстрагирует эту сложность, позволяя командам приложений работать более эффективно.)*<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.42.47.png\" width=\"1008\" height=\"1222\" alt=\"\" \/>\n<\/div>\n<p>Обратите внимание сколько кубиков вверху, а сколько внизу. В России кстати очень быстро вырывается вперед разработка на фреймворках streamlit, они почти ничего не делают повторно, если развернули хоть раз его с авторизацией и ипишками – в основном только ui колбасят. Но часто такие инициативы не вырастают сильно, их обычно давят в зародыше, так как они не соответствуют общему формату и не хотят делать все остальные кубики или не умеют – в общем похожи они на shadow it. Но если же им каким, то образом это удалось, то потом их не остановить и придя к ним через год, можно увидел второй прод, полностью зеркальный :) и сделал его кто-то один вечерами.<\/p>\n<h5>2. Затраты: Оптимизация за счет масштабирования и повторного использования<\/h5>\n<ul>\n<li><b>Проблема руководителя:<\/b> Как нам контролировать растущие расходы на облако и инженерию?<\/li>\n<li><b>Обоснование IDP:<\/b> Платформенная инженерия сокращает дублирование усилий и консолидирует управление инфраструктурой. IDP способствует экономически эффективному масштабированию, обеспечивая прозрачность и контроль на протяжении всего жизненного цикла ПО. Централизация позволяет совместно использовать ресурсы, проактивно отслеживать затраты и автоматически высвобождать неиспользуемые активы (например, тестовые среды).<\/li>\n<li><b>Бизнес-результаты:<\/b>\n<ul>\n  <li>Улучшенная прозрачность и предсказуемость затрат.<\/li>\n  <li>Снижение общей стоимости владения (TCO) за счет оптимизации ресурсов.<\/li>\n  <li>Большая рентабельность инвестиций (ROI) в облачную инфраструктуру.<\/li>\n<\/ul>\n<\/li>\n<li><b>Важный момент:<\/b> Команды платформы могут отслеживать метрики использования и отключать неиспользуемые среды.<\/li>\n<\/ul>\n<h5>3. Риски: Сокращение точек отказа и операционных угроз<\/h5>\n<ul>\n<li><b>Проблема руководителя:<\/b> Какие риски угрожают нашей способности поставлять продукт надежно и безопасно?<\/li>\n<li><b>Обоснование IDP:<\/b> IDP минимизирует операционные риски и риски безопасности путем стандартизации процессов по всем направлениям — конвейеры CI\/CD, развертывание, наблюдаемость (observability), оповещения и аутентификация.<\/li>\n<li><b>Бизнес-результаты:<\/b>\n<ul>\n  <li>Снижение риска сбоев в продакшене.<\/li>\n  <li>Централизация ключевых сервисов, таких как развертывание, управление идентификацией и логирование.<\/li>\n  <li>Принудительное применение политик безопасности и соответствия на уровне платформы.<\/li>\n<\/ul>\n<\/li>\n<li><b>Примеры устраняемых рисков:<\/b>\n<ul>\n  <li>Задержки в поставке из-за нестабильных конвейеров.<\/li>\n  <li>Утечки данных из-за неверно настроенных систем аутентификации.<\/li>\n  <li>Непрохождение аудита из-за несогласованного логирования или дрифта соответствия требованиям.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h5>4. Управление (Governance): Обеспечение согласованности и соответствия требованиям в масштабе<\/h5>\n<ul>\n<li><b>Проблема руководителя:<\/b> Как нам поддерживать контроль, не замедляя команды?<\/li>\n<li><b>Обоснование IDP:<\/b> С IDP управление становится встроенным. От шаблонов до API, команды платформы могут кодировать стандарты и лучшие практики непосредственно в опыт разработчика.<\/li>\n<li><b>Бизнес-результаты:<\/b>\n<ul>\n  <li>Проактивное управление и применение политик.<\/li>\n  <li>Улучшенная аудитопригодность и соответствие нормативным требованиям.<\/li>\n  <li>Формирование культуры инженерного совершенства.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h5>Подкрепление доводов данными<\/h5>\n<p>Ключевым фактором для вашего бизнес-обоснования являются данные. Проведите опрос в вашей инженерной организации, чтобы собрать информацию, например, о времени, затрачиваемом на инфраструктурные задачи по сравнению с разработкой новой функциональности.<\/p>\n<p><b>Итоговые мысли: Что не дает спать руководителям?<\/b><\/p>\n<p>При формировании своего предложения обращайтесь непосредственно к рискам и результатам, которые больше всего волнуют ваших руководителей. Например:<\/p>\n<ul>\n<li><b>Скорость выхода на рынок (Speed to market):<\/b> Сможем ли мы поставлять продукт быстрее конкурентов?<\/li>\n<li><b>Надежность:<\/b> Выдержат ли наши системы нагрузку?<\/li>\n<li><b>Безопасность и соответствие требованиям (Security & Compliance):<\/b> Уязвимы ли мы для взломов или аудитов?<\/li>\n<li><b>Масштабируемость:<\/b> Сможем ли мы расти, не теряя контроля?<\/li>\n<\/ul>\n<p>Внутренняя платформа для разработчиков — это не просто технический инструмент, это стратегический актив. С правильной постановкой вопроса, данными и видением вы можете продемонстрировать, как хорошо реализованная IDP поддерживает не только инженерию, но и весь бизнес.<\/p>\n<hr \/>\n<h4>5. Лучшие практики для создания IDP<\/h4>\n<p>Этот раздел основан на идеях, вдохновленных видео Виктора Фарчича «От нуля до полностью работающей платформы для разработчиков за 5 шагов!». Он описывает не столько шаги, сколько ключевые возможности, которые должна иметь IDP, чтобы быть полезной.<\/p>\n<p><b>5 ключевых возможностей IDP (по версии Виктора Фарчича):<\/b><\/p>\n<ol start=\"1\">\n<li>API<\/li>\n<li>Управление состоянием (State management)<\/li>\n<li>Одноразовые действия \/ Рабочие процессы (One-shot actions \/ Workflows)<\/li>\n<li>RBAC и Политики (RBAC & Policies)<\/li>\n<li>Пользовательские интерфейсы (опционально)<\/li>\n<\/ol>\n<p><b>Наш взгляд на ключевые возможности (немного измененный и дополненный):<\/b><\/p>\n<ol start=\"1\">\n<li><b>API:<\/b> Программный интерфейс для взаимодействия с платформой.<\/li>\n<li><b>Пользовательские интерфейсы (не опционально):<\/b> Удобный способ для разработчиков взаимодействовать с платформой.<\/li>\n<li><b>Автоматизация:<\/b> Включает как одноразовые действия (например, запуск сборки), так и управление состоянием (например, поддержание среды в нужном состоянии).<\/li>\n<li><b>Ограничения (Constraints):<\/b> Политики, управление доступом на основе ролей (RBAC) и т.д.<\/li>\n<li><b>Документация и обнаруживаемость (Discoverability):<\/b> Возможность легко находить сервисы, их владельцев и документацию.<\/li>\n<\/ol>\n<h5>Как это поможет мне построить платформу?<\/h5>\n<p>Если вы подумаете о проблемах, с которыми вы недавно сталкивались как инженер платформы или DevOps-инженер, вы, вероятно, сможете соотнести их с одной из описанных возможностей.<\/p>\n<p><b>Некоторые примеры:<\/b><\/p>\n<ul>\n<li>Если у вас проблемы с простоями инстансов или случайными высокими затратами из-за оставленных облачных ресурсов, у вас недостаточные возможности по <b>управлению состоянием<\/b>.<\/li>\n<li>Если у вас проблемы с тем, что у инженеров-программистов нет доступа к нужной им инфраструктуре, или с тем, что младшие инженеры вмешиваются в развертывания, в которые им не следует вмешиваться, вы плохо управляете <b>ограничениями<\/b>.<\/li>\n<li>Если ваши разработчики не могут самостоятельно запустить систему на основе feature-ветки или запустить сборку и тест для определенного коммита, вам нужно взглянуть на ваши возможности <b>автоматизации одноразовых действий<\/b>.<\/li>\n<li>Если ваши инженеры-программисты просто не используют предоставляемые вами API и сервисы, вам, вероятно, следует взглянуть на предоставляемые вами <b>пользовательские интерфейсы<\/b> или проверить, <b>обнаруживаемы \/ документированы<\/b> ли ваши сервисы.<\/li>\n<\/ul>\n<p>Цель и ценность этих ключевых возможностей — помочь вам понять, почему вы продолжаете терпеть неудачи в некоторых вопросах, и как вы можете начать исправлять ситуацию таким образом, чтобы это было долговечно и устойчиво управляемо.<\/p>\n<hr \/>\n<h4>6. Инструменты платформенной инженерии для создания IDP<\/h4>\n<p>В этой статье рассматривается, как структурировать IDP, с разбивкой по ключевым компонентам и с примерами инструментов, которые вы можете использовать.<\/p>\n<h5>Категоризация инструментов и компонентов<\/h5>\n<p>Мы классифицируем эти инструменты, используя «референсную архитектуру», популяризированную `platformengineering.org`. Эта структура разбивает экосистему на пять основных компонентов, известных как «плоскости» (`planes`):<\/p>\n<ul>\n<li><b>Плоскость управления разработчика (`Developer Control Plane`):<\/b> Все компоненты, через которые разработчики взаимодействуют с платформой. Обычно включает GUI\/порталы, контроль версий, облачные среды разработки (CDE), а также стандарты конфигурации, которые разработчики поддерживают сами.<\/li>\n<li><b>Плоскость интеграции и доставки (`Integration & Delivery Plane`):<\/b> Здесь происходит вся автоматизация. Инструменты CI\/CD, автоматизация инфраструктуры и другие оркестраторы платформы обычно являются частью этой плоскости.<\/li>\n<li><b>Плоскость мониторинга и логирования (`Monitoring & Logging Plane`):<\/b> Как следует из названия, здесь находятся все инструменты наблюдаемости (observability).<\/li>\n<li><b>Плоскость безопасности (`Security Plane`):<\/b> Управление секретами, инструменты политик и другие инструменты безопасности.<\/li>\n<li><b>Плоскость ресурсов (`Resource Plane`):<\/b> Вычислительные ресурсы и хранилища.<\/li>\n<\/ul>\n<h5>Пример: Создание внутренней платформы для разработчиков<\/h5>\n<p>Вот разбивка инструментов, которые вы могли бы использовать для создания IDP. Важное замечание: существует множество доступных инструментов. Упомянутые здесь — лишь примеры.<\/p>\n<h5>Плоскость управления разработчика<\/h5>\n<p><b>№1 Портал разработчика (`Developer Portal`)<\/b><\/p>\n<ul>\n<li><b>Почему это важно:<\/b> Внутренние порталы разработчиков служат единым интерфейсом и позволяют разработчикам, командам и инженерам-менеджерам обнаруживать сервисы, отслеживать владение, применять стандарты и улучшать программное обеспечение.<\/li>\n<li><b>Инструменты для рассмотрения:<\/b>\n<ul>\n  <li><b>Backstage:<\/b> Популярный open-source фреймворк для создания порталов разработчиков, созданный Spotify.<\/li>\n  <li><b>Port:<\/b> Платформа для создания внутреннего портала разработчика с no-code подходом, что облегчает быстрый старт.<\/li>\n  <li><b>Cortex:<\/b> Корпоративный внутренний портал разработчика, созданный для ускорения пути к инженерному совершенству. [cloudomation.com](<a href=\"https:\/\/cloudomation.com\/cloudomation-blog\/5-internal-developer-portals-and-what-software-engineers-say-about-them\/)\">https:\/\/cloudomation.com\/cloudomation-blog\/5-internal-developer-portals-and-what-software-engineers-say-about-them\/)<\/a><\/li>\n  <li><b>Atlassian Compass:<\/b> Компонентный каталог для отслеживания компонентов и команд, которые за ними стоят.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><b>№2 Облачные среды разработки (`Cloud Development Environments, CDEs`)<\/b><\/p>\n<ul>\n<li><b>Почему это важно:<\/b> CDE — это удаленные среды разработки, размещенные в облаке или локально. CDE позволяют разработчикам работать в согласованных, стандартизированных средах, что устраняет проблемы «у меня на машине все работает».<\/li>\n<li><b>Инструменты для рассмотрения:<\/b>\n<ul>\n  <li><b>Gitpod:<\/b> Позволяет запускать безопасные, контекстно-насыщенные среды для разработчиков в корпоративном масштабе.<\/li>\n  <li><b>Coder:<\/b> Предоставляет безопасные среды разработки для разработчиков и их агентов.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h5>Плоскость интеграции и доставки<\/h5>\n<p><b>№1 Конвейер CI (`CI Pipeline`)<\/b><\/p>\n<ul>\n<li><b>Почему это важно:<\/b> Автоматизирует проверку кода, тестирование и обеспечивает более быстрые циклы обратной связи.<\/li>\n<li><b>Инструменты для рассмотрения:<\/b>\n<ul>\n  <li><b>GitHub Actions:<\/b> Нативный CI для GitHub с настраиваемыми рабочими процессами.<\/li>\n  <li><b>CircleCI:<\/b> Высокомасштабируемый CI с поддержкой расширенного параллелизма.<\/li>\n  <li><b>Buildkite:<\/b> CI, ориентированный на разработчиков, с масштабируемой инфраструктурой.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><b>№2 Конвейер CD (`CD Pipeline`)<\/b><\/p>\n<ul>\n<li><b>Почему это важно:<\/b> Конвейеры CD автоматизируют безопасное, повторяемое развертывание программного обеспечения.<\/li>\n<li><b>Инструменты для рассмотрения:<\/b>\n<ul>\n  <li><b>Argo CD:<\/b> GitOps-ориентированная доставка для Kubernetes.<\/li>\n  <li><b>Flux:<\/b> Контроллер GitOps для Kubernetes.<\/li>\n  <li><b>Octopus Deploy:<\/b> Подходит для мультиоблачных и локальных (on-prem) сред.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><b>№3 Оркестратор платформы (`Platform Orchestrator`)<\/b><\/p>\n<ul>\n<li><b>Почему это важно:<\/b> Инструменты оркестрации предоставляют логику для связывания рабочих процессов между различными инструментами и сервисами.<\/li>\n<li><b>Инструменты для рассмотрения:<\/b>\n<ul>\n  <li><b>Humanitec:<\/b> Оркестратор платформы, предоставляющий динамические среды. Является лидером рынка IDP. [internaldeveloperplatform.org](<a href=\"https:\/\/internaldeveloperplatform.org\/)\">https:\/\/internaldeveloperplatform.org\/)<\/a><\/li>\n  <li><b>Собственные решения\/фреймворки:<\/b> Многие команды используют общие инструменты, такие как <b>Argo Workflows<\/b> или пишут собственные скрипты на Python\/Go для объединения своих процессов.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h5>Плоскость мониторинга и логирования<\/h5>\n<p><b>№1 Наблюдаемость (`Observability`)<\/b><\/p>\n<ul>\n<li><b>Почему это важно:<\/b> Инструменты наблюдаемости обеспечивают видимость состояния, производительности и надежности приложений и инфраструктуры.<\/li>\n<li><b>Инструменты для рассмотрения:<\/b>\n<ul>\n  <li><b>Prometheus:<\/b> Набор инструментов для мониторинга и оповещения, особенно для Kubernetes.<\/li>\n  <li><b>Grafana:<\/b> Инструмент для создания дашбордов, часто используемый в паре с Prometheus.<\/li>\n  <li><b>Datadog:<\/b> Облачный мониторинг и аналитика.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h5>Плоскость безопасности<\/h5>\n<p><b>№1 Менеджер секретов (`Secret Manager`)<\/b><\/p>\n<ul>\n<li><b>Почему это важно:<\/b> Менеджеры секретов безопасно хранят и распространяют учетные данные, ключи API и другие конфиденциальные данные.<\/li>\n<li>Инструменты для рассмотрения:**\n<ul>\n  <li><b>HashiCorp Vault:<\/b> Ведущее в отрасли решение для управления секретами.<\/li>\n  <li><b>AWS Secrets Manager \/ Azure Key Vault \/ GCP Secret Manager:<\/b> Решения от крупных облачных провайдеров.<\/li>\n  <li><b>Sealed Secrets (Bitnami):<\/b> Шифрует секреты для Kubernetes.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h5>Вывод: Строительные блоки, а не список покупок<\/h5>\n<p>Если из этой главы и стоит что-то вынести, так это то, что платформенная инженерия — это не выбор самых модных инструментов с полки, а подбор правильных строительных блоков для создания бесшовного опыта для разработчиков. Думайте меньше о том, «какой инструмент мне выбрать?», и больше о том, «как я могу спроектировать платформу, которая будет незаметной и мощной для моих разработчиков и принесет пользу бизнесу?»<\/p>\n<p>Настоящая магия происходит тогда, когда эти инструменты перестают быть отдельными частями пазла и становятся частью целостной платформы для разработчиков, где разработчики едва замечают лежащую в основе сложность, потому что платформа работает с ними, а не против них.<\/p>\n<hr \/>\n<h4>7. 3 проблемы при создании IDP<\/h4>\n<p>Этот раздел основан на идеях Гая Менахема (Guy Menahem), архитектора решений в Amazon.<\/p>\n<p><b>Проблема 1: Попытаться поймать всех зайцев одним выстрелом<\/b><\/p>\n<p>Многие команды платформенной инженерии пытаются сделать все сразу и в итоге не достигают ничего. Объединение всех инструментов в единое решение может привести к тому, что вы упустите основной рабочий процесс пользователя, что приведет к отказу от платформы. Вместо этого оттачивайте свои продуктовые навыки, чтобы понять, какую пользу пользователи извлекут из платформы, даже если на начальном этапе она будет включать всего несколько инструментов.<\/p>\n<p><b>Проблема 2: Оценка затрат на создание и эксплуатацию<\/b><\/p>\n<p>Создание ценной платформы требует ресурсов, включая выделенную команду платформенной инженерии, бюджет на облачную инфраструктуру и сотрудничество. Также необходимо учитывать операционные расходы, такие как обновления и патчи безопасности. Оценивайте ресурсы, определяя размер и продолжительность работы команды, сосредотачиваясь на минимально жизнеспособном продукте (MVP) и рассчитывая облачные и операционные затраты.<\/p>\n<p><b>Проблема 3: Создание и управление каталогом программного обеспечения<\/b><\/p>\n<p>Управление каталогом программного обеспечения, который представляет собой сложную базу данных ПО, систем и документации, может быть непростой задачей. Вовлечение всех команд в обновление и поддержание каталога имеет решающее значение для его качества и принятия. Упростите управление каталогом, автоматизировав сбор информации, принудительно обновляя его в процессах CI\/CD и поощряя ежедневное использование платформы.<\/p>\n<h5>Наш взгляд<\/h5>\n<p>Проблемы, которые описывает Гай, реальны. Однако одна фундаментальная истина, которую он не упоминает, заключается в том, что <b>большинство проблем при создании IDP не являются техническими.<\/b><\/p>\n<p>Вместо этого наиболее распространенные проблемы возникают из-за <b>недостатка коммуникации между людьми.<\/b> Это типично для многих инженерных инициатив, поскольку инженеры, как правило, имеют очень специфический взгляд на инструменты, которые они создают, и этот взгляд часто сильно отличается от точки зрения их пользователей.<\/p>\n<p>То же самое часто происходит и в командах платформенной инженерии: они могут создавать ценную автоматизацию и сервисы, но если их нелегко использовать, в них отсутствуют ключевые функции, необходимые инженерам-программистам, или они просто не решают самые большие проблемы, с которыми сталкиваются разработчики, то они просто не будут использовать IDP.<\/p>\n<p>Самое важное, что вы должны делать как инженер платформы, — <b>регулярно спрашивать своих инженеров-программистов!<\/b> Просите их протестировать то, что вы создаете, сказать, полезно ли это для них, и если ответ «нет», то изменяйте то, что вы создаете, чтобы ваши инженеры-программисты захотели это использовать.<\/p>\n<p>В конце концов, в этом и заключается вся суть IDP: она должна быть полезной для инженеров-программистов.<\/p>\n<hr \/>\n<h4>8. <b>Ресурсы и ссылки<\/b><\/h4>\n<ul>\n<li><a href=\"https:\/\/platformengineering.org\">https:\/\/platformengineering.org<\/a><\/li>\n<li><a href=\"https:\/\/internaldeveloperplatform.org\">https:\/\/internaldeveloperplatform.org<\/a><\/li>\n<li><a href=\"https:\/\/www.infoq.com\/platformengineering\">https:\/\/www.infoq.com\/platformengineering<\/a><\/li>\n<\/ul>\n<p><b>Сообщества<\/b><\/p>\n<ul>\n<li>Reddit – <a href=\"https:\/\/www.reddit.com\/r\/platform_engineering\">https:\/\/www.reddit.com\/r\/platform_engineering<\/a><\/li>\n<li>Platformers – <a href=\"https:\/\/platformers.community\">https:\/\/platformers.community<\/a><\/li>\n<\/ul>\n<p><b>Рассылки<\/b><\/p>\n<ul>\n<li><a href=\"https:\/\/platformweekly.com\">https:\/\/platformweekly.com<\/a><\/li>\n<\/ul>\n<hr \/>\n<p>Ранее еще писал немного на другую тему, но про разработку и стандарты апишек,интересно, мало у кого они есть, выглядят вот так: <a href=\"https:\/\/gavrilov.info\/all\/analiz-zalando-restful-api-and-event-guidelines\/\">https:\/\/gavrilov.info\/all\/analiz-zalando-restful-api-and-event-guidelines\/<\/a><\/p>\n",
            "date_published": "2025-09-24T23:12:48+03:00",
            "date_modified": "2025-09-24T23:36:23+03:00",
            "tags": [
                "Dev",
                "Management",
                "Product",
                "Programming"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.11.04.png",
            "_date_published_rfc2822": "Wed, 24 Sep 2025 23:12:48 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "282",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.11.04.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.46.02.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.44.01.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.39.52.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.40.18.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.42.47.png"
                ]
            }
        }
    ],
    "_e2_version": 4171,
    "_e2_ua_string": "Aegea 11.4 (v4171e)"
}