Yuriy Gavrilov: posts tagged Dev

Hugr: Data Mesh-платформа и GraphQL-бэкенд на базе DuckDB

Sun, 20 Sep 2026 09:00:00 +0300

1. Что такое Hugr и зачем он нужен

Hugr — это open-source платформа класса Data Mesh и высокопроизводительный GraphQL-бэкенд, построенный поверх аналитического движка DuckDB. Проект развивается командой hugr-lab под руководством Владимира Грибанова и распространяется под лицензией MIT.

Назначение — решить конкретную инженерную боль: данные в организации разбросаны по десяткам систем (PostgreSQL, SQL Server, S3, REST API, Kafka, Redis), и каждая команда строит собственный слой доступа. Классические ETL-пайплайны и дублирование данных в единое хранилище дают задержку актуальности, удваивают инфраструктуру и создают узкое горлышко на дата-инженерах.

Hugr предлагает иную модель: данные остаются на месте, а поверх них выстраивается единый GraphQL-слой, который компилирует декларативные схемы в исполняемые запросы к каждому источнику. Для аналитика — один интерфейс вместо десятков коннекторов. Для разработчика — типизированный GraphQL API без ручного CRUD. Для дата-инженера — декларативное описание схемы через SDL-директивы вместо поддержки ETL.

Ключевые характеристики:

Параметр	Значение
Лицензия	MIT
Ядро	DuckDB (in-process, колоночный, OLAP)
Интерфейс	GraphQL (queries, mutations, subscriptions)
Язык реализации	Go
Репозитории	`hugr-lab/hugr`, `hugr-lab/query-engine`
Развёртывание	Docker, Kubernetes, embedded в Go-сервисы

2. Архитектура: почему именно такая

2.1. Мотивация

Традиционный подход «единое хранилище» (Data Warehouse / Lakehouse) предполагает перемещение данных в одну точку. Это создаёт три проблемы:

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

Data Mesh инвертирует модель: каждый домен владеет своими данными и публикует их как продукт, а платформа обеспечивает федеративный доступ. Hugr — инфраструктура этого доступа.

2.2. Компоненты

┌────────────────────────────────────────────────┐
│                  Клиенты                       │
│   Web · BI · Python · MCP/AI                   │
└───────────────────────┬────────────────────────┘
                        │ GraphQL / IPC / REST
┌───────────────────────▼────────────────────────┐
│              Hugr Server (Go)                  │
│  ┌──────────┐ ┌──────────┐ ┌────────────────┐  │
│  │ GraphQL  │ │ Schema   │ │ Access Control │  │
│  │ API+Subs │ │ Compiler │ │ OAuth2 / RBAC  │  │
│  └──────────┘ └──────────┘ └────────────────┘  │
│  ┌──────────────────────────────────────────┐  │
│  │     DuckDB Analytical Engine (Go)        │  │
│  │  In-process · Колоночный · Vectorized    │  │
│  └──────────────────────────────────────────┘  │
│  ┌──────────┐ ┌──────────┐ ┌────────────────┐  │
│  │  Cache   │ │  CoreDB  │ │ IPC Protocol   │  │
│  │Mem+Redis │ │ metadata │ │  (Arrow)       │  │
│  └──────────┘ └──────────┘ └────────────────┘  │
└──┬──────────┬──────────┬───────────┬───────────┘
   │          │          │           │
┌──▼───┐  ┌───▼────┐ ┌───▼────┐ ┌────▼──────┐
│ PG / │  │SQL Srv │ │DuckLake│ │ REST API  │
│MySQL │  │Azure   │ │Iceberg │ │Arrow Fl.  │
│Parq. │  │        │ │S3/CSV  │ │ Redis KV  │
└──────┘  └────────┘ └────────┘ └───────────┘

DuckDB как ядро — in-process колоночная СУБД для OLAP. Не требует отдельного процесса и сетевого порта, работает с десятками форматов (Parquet, CSV, JSON, GeoParquet, Delta Lake), обеспечивает векторизованное исполнение. Для Hugr это нулевая сетевая задержка между движком и логикой и возможность кросс-источниковых JOIN’ов в памяти.

CoreDB хранит метаданные: источники, каталоги схем, роли, политики доступа. Может быть DuckDB-файлом или PostgreSQL (обязателен для кластера).

Компилятор схем преобразует GraphQL SDL с директивами (`@table`, `@view`, `@function`, `@field_references`, `@join`, `@module`) в логическую модель, из которой генерируются типы, фильтры, агрегации, мутации и sub-query поля для связей.

3. Источники данных: единая точка входа

3.1. Поддерживаемые типы

Категория	Источники	Особенности
Реляционные	PostgreSQL (PostGIS, TimescaleDB, pgvector), MySQL, SQL Server / Azure SQL	Pushdown фильтров, сортировки, агрегаций и JOIN’ов
Озёра данных	DuckLake, Apache Iceberg (REST, Glue, S3 Tables)	Time-travel, snapshot-based DDL/DML
Файлы	Parquet, Delta Lake, CSV, JSON, GeoParquet, Shapefiles	Через DuckDB, поддержка S3 и Hive-партиционирования
Сервисы	REST API, Arrow Flight gRPC, GraphQL (в разработке)	Basic, ApiKey, OAuth2
AI/ML	Embeddings, LLM (OpenAI, Anthropic, Gemini)	Единый tool calling, streaming
Key-Value	Redis	Pub/Sub, keyspace events, TTL
Расширения	Extension-источник, Hugr Apps	Кросс-источниковые представления, кастомные функции

3.2. Декларативная регистрация

Источник описывается мутацией `insert_data_sources`, после чего его схема компилируется и попадает в общее GraphQL-дерево. Адаптеры и коннекторы писать не нужно.

mutation {
  core {
    insert_data_sources(data: {
      name: "my_llm"
      type: "llm-openai"
      prefix: "my_llm"
      path: "http://localhost:1234/v1/chat/completions?model=gemma-4&timeout=120s"
    }) { name }
  }
}

Новый источник появляется в API за одну мутацию, без пересборки и перезапуска.

4. GraphQL как универсальный слой доступа

4.1. Автогенерация из схемы

Для каждого табличного объекта компилятор создаёт:

запросы с `filter`, `order_by`, `distinct_on`, `limit`, `offset`;
запрос по первичному ключу (`object_name_by_pk`) и уникальным полям;
агрегации (`object_name_aggregation`) и корзинные агрегации (`object_name_bucket_aggregation`);
мутации `insert`, `update`, `delete` с типизированными входными структурами;
фильтровые типы с операторами `eq`, `in`, `gt`, `lt` и вложенными фильтрами по связям;
sub-query поля для связей (включая M2M), query-time JOIN’ы и пространственные JOIN’ы.

Дата-инженер описывает логическую модель — полный CRUD, агрегации и связи появляются автоматически.

4.2. Подписки

Streaming LLM completions — токены с событиями `content_delta`, `reasoning`, `tool_use`, `finish`, `error`.
Pub/Sub — подписка на каналы Redis.
Keyspace events — мониторинг изменений ключей по паттерну.

4.3. JQ-трансформации

Серверные JQ-преобразования: встроенный `jq()` в GraphQL, REST-эндпоинт `/jq-query`, доступ к переменным через `$var_name`, вложенные GraphQL-запросы из JQ через `queryHugr()`. Это постобработка без выгрузки в Python — группировка, фильтрация, реструктуризация на сервере.

5. AI-возможности: LLM и Embeddings

5.1. Модуль `core.models`

Функция	Назначение
`embedding` / `embeddings`	Векторные эмбеддинги (одиночный и батч)
`completion`	Простая генерация текста
`chat_completion`	Многооборотный диалог с tool calling
`model_sources`	Список зарегистрированных моделей

Провайдеры: OpenAI (и совместимые: Ollama, LM Studio, vLLM, Mistral, Qwen, Azure OpenAI), Anthropic (Claude), Google Gemini. Различия форматов абстрагированы.

5.2. Tool Calling и Round-trip

Вызовы инструментов нормализованы. Для Gemini 2.5+ поддерживается `thought_signature` — обязательное поле при отправке результатов инструментов обратно модели. Пайплайн: запрос → `tool_calls` + `thought_signature` → исполнение инструмента → сообщение с `role: “tool”` → полная история в `chat_completion`.

5.3. Thinking Budget

Параметр `thinking_budget` управляет chain-of-thought: задаётся на уровне источника (максимум) и запроса (кап). Модель сначала выдаёт `reasoning`-события, затем `content_delta`.

5.4. MCP-интеграция

Поддержка Model Context Protocol позволяет AI-ассистентам (Claude, Cursor) исследовать схему, выполнять семантический поиск и генерировать/валидировать GraphQL-запросы. Основа для «vibe-аналитики»: LLM строит запросы на естественном языке, Hugr их исполняет.

6. Hugr Apps: расширяемость через Arrow Flight

6.1. Концепция

Hugr Apps — внешние Go-приложения, подключаемые через DuckDB Airport extension (Apache Arrow Flight gRPC). Публикуют в общую GraphQL-схему скалярные функции, таблицы, табличные функции и собственные источники данных (например, PostgreSQL с миграциями).

6.2. Жизненный цикл

Сценарий	Обнаружение	Восстановление	Потеря данных
Graceful shutdown	Немедленно	N/A	Нет
Краш приложения	Heartbeat (~90 сек)	Мгновенно при рестарте	Нет
Рестарт Hugr	Startup load	LoadDataSource	Нет
Обновление версии	Изменение пути	Мгновенно (миграция)	Нет

Heartbeat: интервал 30 сек, таймаут 10 сек, 3 неудачи → приостановка каталога. При восстановлении каталог перекомпилируется.

6.3. Практический смысл

Бизнес-логику (геокодирование, скоринг, расчёты) можно вынести в отдельный сервис и опубликовать как SQL/GraphQL-функции без изменения основного конвейера.

7. Production-readiness и работа под нагрузкой

7.1. Кластерный режим

CLUSTER_ROLE: `management` или `worker`.
Management-нода координирует синхронизацию схем, жизненный цикл источников и конфигурацию хранилищ.
Worker-ноды получают обновления через push (broadcast) и pull (polling).
PostgreSQL CoreDB обязателен — все ноды разделяют единую метабазу.

7.2. Кеширование

In-memory — горячие данные на каждой ноде.
Внешний кеш (Redis / Memcached) — разделяемый, инвалидация при мутациях.

Директива `@cache` управляет кешированием на уровне схемы.

7.3. Производительность

Нулевая сетевая задержка между логикой и движком.
Векторизованное колоночное исполнение.
Поддержка десятков форматов без конвертации.
Кросс-источниковые JOIN’ы в памяти.
Filter pushdown — условия `WHERE` передаются на сторону источника (особенно PostgreSQL).

7.4. Безопасность

OAuth2 / OpenID Connect, field-level и row-level security, ролевая модель с предопределёнными фильтрами, автозаполнение контекста пользователя/роли в мутациях.

7.5. Развёртывание

Docker: `docker run -d --name hugr -p 15000:15000 -v ./schemas:/schemas ghcr.io/hugr-lab/automigrate:latest`
Kubernetes: Helm-чарты в `hugr-lab/docker` (multi-node, load balancing, кеширование).
Embedded: Go-пакет `hugr-lab/query-engine`.

7.6. Ограничения

Планируются коннекторы к SQLite (через DuckDB) и ClickHouse.
GraphQL как источник данных — в разработке.
«Talk-to-data» (естественный язык) — анонсирован.

Для высоких нагрузок рекомендуется кластерный режим с PostgreSQL CoreDB и Redis-кешем.

8. Области применения и примеры

8.1. Бэкенд данных для приложений

Единый GraphQL-слой поверх существующих БД: быстрый запуск API, централизованная схема, контроль доступа.

{
  marketing {
    campaigns_aggregation_bucket {
      key { channel { name } }
      aggregations { payments { amount { sum } } }
    }
  }
}

8.2. Data Mesh-платформа

Каждый домен публикует свою схему как модуль. Федеративный доступ через единый API, децентрализованное владение.

8.3. Аналитика и MLOps

OLAP-запросы и пространственные агрегации через GraphQL, экспорт в Arrow IPC → Python (pandas, GeoDataFrame, Jupyter), JQ-трансформации на сервере, цикл Ingestion → Processing → ML → API Access.

8.4. Агентная аналитика (Vibe Analytics)

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

8.5. Реал-тайм дашборды

Подключение Grafana/Metabase к Hugr → данные обновляются на каждый запрос, без ETL-задержек, с комбинацией нескольких источников.

8.6. Геопространственные задачи

Нативные пространственные типы, кросс-источниковые spatial JOIN’ы, поддержка GeoParquet, GeoJSON, Shapefiles, агрегации по пространственным отношениям.

9. Итог

Hugr занимает нишу между «тяжёлыми» платформами данных (Databricks, Snowflake) и лёгкими GraphQL-обёртками над одной БД. Его ценность:

Декларативность — схема через SDL-директивы, полный CRUD генерируется автоматически.
Федеративность — данные не перемещаются, доступ на месте.
Производительность — DuckDB in-process даёт колоночную векторизацию без сетевых накладных расходов.
Расширяемость — Hugr Apps, Extension-источники, AI-модуль, Redis.
Открытость — MIT, Go-стек, Docker/K8s, embedded-режим.

Для команды, которая хочет дать аналитикам и приложениям единый доступ к разнородным данным без ETL-империи, Hugr — зрелый и прагматичный выбор с понятной траекторией масштабирования.

10. Что ещё: другие инструменты и события из рассылки DuckDB (сентябрь 2026)

Ежемесячная рассылка DuckDB #45 (16 сентября 2026) принесла несколько значимых новостей.

Крупные события

AWS приобретает DuckLabs (компанию-создателя DuckDB). Проекты DuckDB, DuckLake, Quack остаются под MIT-лицензией и управлением DuckDB Foundation. Сообщество восприняло новость со сдержанным оптимизмом благодаря независимому фонду и открытой лицензии. Однако аналитики предупреждают: «разработчики не должны путать неизменность лицензии с неизменностью проекта — люди, пишущие код DuckDB, теперь получают зарплату от AWS, а зарплата влияет на дорожную карту».
MotherDuck приобретает Tower.dev для интеграции рантайм-инфраструктуры в MotherDuck Flights — AI-агенты смогут выполнять задачи дата-инжиниринга и публиковать данные как API. Tower — это hosted-рантайм для Python-пайплайнов, обеспечивающий песочницу, планирование и наблюдаемость для кода, написанного LLM.

DuckDB 2.0 preview (кодовое имя «Cyanoptera»)

Доступна preview-версия с клиент/серверным режимом через Quack и `CONNECT`, новым PEG-парсером SQL, переработанным C API для расширений, новым форматом хранения по умолчанию. Асинхронный I/O для S3, переписанный движок рекурсивных CTE и оптимизированный тип VARIANT. Релиз запланирован на октябрь 2026.

Экосистема

Инструмент / Статья	Суть
sql.garden	Open-source бесконечный холст для данных на Wails (Go + Vue 3) с MCP-сервером для AI-взаимодействия
DuckDB Table Functions in Java	Регистрация табличных функций на чистом Java без C++ расширений; векторизованный батч 2048 строк, pushdown предикатов
JetBrains Parquet/Avro/ORC Viewer	Плагин для IDE: 1 млрд строк / 29 ГБ Parquet открывается за ~1 сек
Bulk Load в SQL Server (В. Грибанов)	Параллельные писатели и явные типы (`MSSQL_NVARCHAR(200)`) ускоряют загрузку 38 млн строк с 933 до 96 сек
DuckLake vs Iceberg (CDC)	DuckLake решает проблему мелких файлов в Postgres→DuckDB CDC: 6 576 мс против 269 344 мс у Iceberg COW
duckdb-zarr	Rust-расширение для запросов к Zarr-хранилищам (N-мерные массивы) через SQL, поддержка S3/GCS
DuckDB for Apache Iceberg	Полноценный read/write lifecycle через REST-каталоги, MERGE INTO, ALTER TABLE, Iceberg V3
SQLite vs DuckDB на $16-железе	Для observability-данных DuckDB отодвигает «обрыв чтения» в 100 раз дальше и даёт 4× на метриках, 15× на логах

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

Apache Airflow или Temporal: выбор между оркестрацией данных и бизнес-логикой

Mon, 07 Sep 2026 22:11:01 +0300

В мире разработки и инженерии данных инструменты Apache Airflow и Temporal часто могут восприниматься как конкуренты, поскольку оба решают задачу управления многошаговыми процессами. Однако на практике их философия, архитектура и сценарии использования настолько разные, что сравнивать их корректно можно лишь с четким пониманием контекста задачи.

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

1. В чем суть каждого инструмента?

Apache Airflow — это классический оркестратор batch-процессов. Он создавался как решение для управления ETL/ELT-пайплайнами, регулярной загрузки данных, построения отчетов и ML-циклов. Центральная концепция Airflow — DAG (направленный ациклический граф), который описывает зависимости между задачами и обычно запускается по расписанию (например, ежедневно в 6 утра).

Temporal — это платформа для надежного исполнения распределенных бизнес-процессов. Она не просто «запускает задачи», а управляет долгоживущими workflow с сохранением состояния, автоматическими повторами, обработкой сбоев и возможностью ждать внешние события (ответ пользователя, платеж, подтверждение от другой системы). Workflow в Temporal пишутся на обычном коде и выполняются детерминированно.

2. Главное различие

Airflow — это продвинутый планировщик для задач по расписанию в мире данных.
Temporal — это движок надежного исполнения бизнес-логики в распределенных системах, который «помнит» состояние процесса даже через неделю.

3. Сравнительная таблица

Критерий	Apache Airflow	Temporal
Основное назначение	Оркестрация batch-задач и data pipeline’ов	Надежное выполнение бизнес-процессов и workflow
Типичные сценарии	ETL, загрузка данных, отчеты, ML-обучение, backfill	Оформление заказов, платежи, onboarding, Saga-паттерны, фоновые операции
Модель выполнения	DAG из задач (Task)	Workflow + Activities
Основной фокус	Планирование и запуск по расписанию	Состояние, устойчивость, ретраи, долгие ожидания
Работа с расписанием	Отлично (родная функциональность)	Возможна, но не основная цель
Долгоживущие процессы (дни/недели)	Не подходит (сложно и неэффективно)	Одно из ключевых преимуществ
Управление состоянием	Ограниченное (обычно через внешние хранилища)	Встроенная, полная история выполнения
Повторные попытки (retries)	Есть, на уровне задач	Гибкие стратегии, таймауты, компенсации
Устойчивость к сбоям	Хорошая для batch-задач	Исключительная (продолжает с места сбоя)
Язык разработки	Python (DAG-файлы)	Go, Java, TypeScript, Python и другие
Наблюдаемость	UI для DAG, логи, статусы задач	UI с историей событий, ретраями и состоянием workflow
Сложность внедрения	Относительно низкая для data-команд	Выше (требует проектирования workflow и инфраструктуры)
Идеально подходит для Data Engineering	✅ Да	❌ Часто избыточно
Идеально подходит для микросервисов	❌ Ограниченно	✅ Да
Масштабирование	Хорошее, но требует тонкой настройки	Рассчитан на распределенные системы с рождения
Основная аудитория	Data Engineers, ML Engineers, аналитики	Backend Engineers, Platform Engineers, команды микросервисов

4. Сложности и подводные камни

4.1. Когда Airflow становится тяжелым

На старте Airflow кажется простым, но по мере роста числа DAG’ов и их сложности возникают типичные проблемы:

Зоопарк DAG’ов — тысячи графов трудно поддерживать и отлаживать.
Жесткая привязка к расписанию — неудобно моделировать процессы, зависящие от событий, а не от времени.
Слабая работа с долгими процессами — если задача выполняется несколько часов, Airflow справится, но если процесс длится дни с ожиданием внешнего действия — начнутся трудности.
Промежуточное состояние — его нужно сохранять во внешних системах (S3, Redis, БД), что усложняет архитектуру.
Риск превращения в «универсальный Cron» — когда в Airflow пытаются запихнуть всё подряд, поддержка становится кошмаром.

Вывод: Airflow хорош для периодических, четко структурированных задач с понятным началом и концом. Для сложной бизнес-логики он не предназначен.

4.2. Когда Temporal требует дисциплины

Temporal дает суперспособности, но платой за них является более высокая инженерная культура:

Детерминированность — код Workflow обязан быть детерминированным (например, нельзя использовать `time.Now()` или случайные числа без специальной обертки).
Управление версиями — обновление логики workflow требует аккуратной миграции, иначе сломаются уже запущенные процессы.
Инфраструктура — Temporal требует собственного кластера (Cassandra/PostgreSQL + сервисы), это сложнее, чем поднять Airflow с локальной БД.
Порог входа — разработчикам нужно усвоить модель Workflow/Activity, понять, как работают таймауты и сигналы.

Вывод: Temporal не нужен для простых ETL-задач, но незаменим там, где процесс должен «жить» и не умирать при сбоях.

5. Temporal на платформах данных: когда он может быть полезен

Хотя в классическом data‑инжиниринге безраздельно правит Airflow, современные платформы данных становятся всё более распределёнными, событийно‑ориентированными и критичными к задержкам. В таких экосистемах появляются сценарии, где Temporal оказывается не избыточным, а очень даже востребованным.

Вот несколько примеров, когда Temporal может усилить вашу data‑платформу:

Долгие и многоэтапные ML‑пайплайны
Обучение модели может занимать часы и включать этапы подготовки данных, экспериментирования, валидации и деплоя. Если какой‑то этап упал, Temporal восстановит процесс с последней успешной точки, не перезапуская всё заново.

Координация распределённых трансформаций
В архитектурах типа Data Mesh или при использовании множества независимых сервисов (например, микросервисы, каждый из которых обновляет свои витрины) Temporal выступает как надёжный координатор, гарантирующий согласованность обновлений даже при частичных отказах.

Event‑driven data pipelines
Вместо жёсткого расписания вы можете запускать workflow по событиям — поступление нового файла в S3, сообщение в Kafka или завершение внешнего процесса. Temporal отлично поддерживает ожидание сигналов, что делает его естественным выбором для реактивных пайплайнов.

Компенсации и исправление данных
Если в процессе загрузки обнаруживается ошибка в уже обработанных данных, Temporal позволяет реализовать компенсирующие действия (откат, дозагрузка, пересчёт) как часть workflow, с полным сохранением контекста.

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

Обеспечение exactly‑once семантики в критичных data‑операциях
Когда повторная обработка одних и тех же данных недопустима (финансовые отчёты, списания), Temporal с его идемпотентными Activity и уникальными идентификаторами workflow даёт высокие гарантии.

При этом Temporal не заменяет Airflow для стандартных ETL по расписанию. Однако если на вашей платформе данных есть процессы, которые:

длятся дольше пары часов,
требуют строгого состояния,
зависят от внешних событий,
должны безупречно восстанавливаться после сбоев,

— то Temporal может стать вторым (и очень мощным) инструментом в вашем арсенале, работающим плечом к плечу с Airflow.

6. Рекомендации по выбору

Выбирайте Airflow, если:

Ваша задача — регулярный запуск batch-процессов (ежедневно, почасово).
Вы строите ETL/ELT, витрины данных, ML-пайплайны.
Процесс укладывается в DAG с четкими шагами.
Команда хорошо знает Python и работает в среде data-инженерии.
Вам нужен backfill (перезапуск за прошлые периоды).

Примеры: загрузка из CRM в DWH, пересчет отчетов, обучение модели по ночам.

Выбирайте Temporal, если:

Процесс длится часы, дни или недели.
Важен строгий контроль состояния — система должна запомнить, на каком шаге остановилась.
Требуются сложные retries, таймауты и компенсационные транзакции (Saga).
Есть ожидание событий от пользователя или внешнего сервиса.
Вы строите микросервисную архитектуру или современную событийно‑управляемую платформу данных.

Примеры: оформление заказа, прохождение KYC, обработка платежей, доставка товара, долгий процесс верификации, а также упомянутые выше сложные data‑пайплайны с внешними зависимостями.

7. Можно ли использовать их вместе?

Да, и это частая практика в крупных компаниях:

Airflow берет на себя все data-пайплайны и подготовку данных для аналитики.
Temporal отвечает за критичные бизнес-процессы, а также за те data‑процессы, которые требуют повышенной надёжности и управления долгим состоянием.

Например, Airflow утром подготавливает агрегированные данные, а Temporal запускает workflow их распределённой валидации и отправки во внешние системы с гарантией доставки. Инструменты не конфликтуют, а дополняют друг друга.

Итог

	Airflow	Temporal
Слоган	Планировщик для data-задач	Движок надежных процессов (бизнес и data)
Сила	Расписание, простота, Python-экосистема	Состояние, устойчивость, долгие workflow, события
Слабость	Сложность с долгими процессами, состоянием	Высокий порог входа, избыточен для простого расписания

Коротко:

Нужны данные, расписание, отчёты → Airflow.
Нужны бизнес-логика, надёжность, долгие операции, событийная оркестрация (включая сложные сценарии на платформе данных) → Temporal.

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

Зря я ему память ставил больше 🥲 ... проект – “Монолит”

Sat, 03 Jan 2026 19:30:34 +0300

вот же блин, не ждал я тут подвоха 😭

сдулся мой старенький asustor, придется бутылки сдавать ... и еще накатить чего-то с горя, что бы было что сдавать.

🥹

а вот еще тряхнул стариной и решил понарошку собрать комп нестыдный на сегодня :)) ну даже очень.
вот что вышло:

ну прям мечта сисадмина и не только))) это по сути 4 в одном. через proxmox 4 виртуалки. Первая True Nas Scale для массива, вторая ubuntu server для докеров и Portainer тоже с gpu и третья виндовая для gpu в виндовой среде. Встречайте...

Проект “Монолит”: Как собрать домашний сервер мечты за миллион (и зачем это вообще нужно)

Говорят, что универсальных инструментов не бывает. Что “Швейцарский нож” режет хуже скальпеля, а универсальная шина хуже зимней. Мы решили бросить вызов этому утверждению. Ну я и мой электронный друг Gemini.

Задача звучала амбициозно: собрать в одном компактном корпусе устройство, которое заменит целый IT-отдел. Оно должно быть:

AI-станцией для запуска “тяжелых” нейросетей (LLM) локально.
Графическим ПК топового уровня (4K/8K видео).
Корпоративным хранилищем (NAS) на 100+ ТБ с надежностью банка.
Лабораторией виртуализации для Docker, Kubernetes и DevOps-экспериментов.

И всё это должно работать 24/7, стоять дома и не напоминать шумом взлетающий Боинг. Спойлер: у нас получилось.

Почему не Mac Pro и не облака?

Первый вопрос, который задают рациональные люди: *“Зачем тратить 1.2 млн рублей на самосбор, если есть MacBook Pro, AWS и простая дисковая шуршалка в углу?”*

MacBook M4 Max прекрасен, но это “золотая клетка”. На нем не развернешь серьезный кластер виртуализации, в нем нет 100 ТБ памяти, и он все еще слабее в AI-обучении, чем топовые GPU. Ну и закрыл крышку – прод упал.
Облака — это игла подписки. Аренда мощностей уровня нашей сборки (A100/H100) будет стоить те же деньги за год-полтора, но в итоге у вас не останется ничего.

Мы выбрали путь “Digital Sovereignty” (Цифровой суверенитет). Своё железо, свои данные, свои правила.

Анатомия Монстра: Разбор “железа”

Каждый компонент здесь — результат компромиссов и долгих споров. Вот наша “Золотая конфигурация”:

1. Сердце: Архитектура “Всё в одном”

Мы отказались от серверных Threadripper в пользу AMD Ryzen 9 9950X3D.

*Зачем?* Нам важна однопоточная производительность для графики и отзывчивости системы. 16 ядер Zen 5 — это избыточно для дома, но идеально для виртуализации. А X3D-кэш делает этот “сервер” лучшим графическим ПК в мире.
*Материнская плата:* MSI MAG X870E Tomahawk. Надежная база с хорошим VRM, способная переварить этот процессор 24/7. Есть еще Eco режим, что позволит немного снизить мощность, но выиграть в теплоотдач и работе 24x7.

2. Мозг AI: Революция 5090 D

Сначала мы смотрели на RTX 4090. Но потом решили взглянуть на NVIDIA RTX 5090 D (32GB).
Это “Game Changer”.

Потребительские карты обычно имеют 24 ГБ памяти. Этого мало для серьезных языковых моделей (LLM). Llama-3-70B туда влезает только “порезанной”.
32 ГБ GDDR7 памяти у 5090 D открывают портал в мир взрослого AI.
Двухслотовая турбина выбрасывает горячий воздух из корпуса, спасая остальные компоненты от перегрева. Да, это стоит 340 000 рублей, но альтернатива (профессиональные карты RTX 6000) стоит в 3 раза дороже. Это отличный истребитель, но не космический крейсер enterprise уровня.

3. Хранилище: Надежность прежде всего

Диски: 8 штук **WD Ultrastar по 22 ТБ. Это 176 ТБ “сырого” объема.
Контроллер: Настоящий серверный HBA-адаптер **LSI 9300-8i в прошивке IT-Mode. Никаких программных RAID на материнской плате, только хардкор.
Файловая система: ZFS в режиме **RAIDZ2 (аналог RAID 6). Могут умереть любые два диска одновременно — данные выживут.

4. Память: Золотая (в прямом смысле) DDR5 ECC

Самая болезненная строка бюджета. 128 ГБ DDR5 ECC.
Из-за бума ИИ цены на память взлетели. Комплект из 4 планок по 32 ГБ сейчас стоит около 200 000+ рублей.

Можно ли сэкономить и взять обычную?* Нет. ZFS активно использует оперативную память. Ошибка в бите памяти может разрушить файловую систему. Для сервера 24/7 ECC (коррекция ошибок) — обязательное требование. Лучше этим не пренебрегать.

5. Корпус: Jonsbo N5

Это магия инженерии. Красивый черный куб, куда помещается E-ATX плата, полноразмерная видеокарта и 8 жестких дисков. Мечта с красивыми деревяшками на лицевой панеле :)

Программная магия: Как этим управлять?

Железо — это только половина дела. Вся мощь раскрывается в софте.
Мы используем Proxmox VE как гипервизор. Это “слоеный пирог”:

VM TrueNAS: Прямой проброс контроллера LSI. Эта виртуалка управляет дисками и раздает файлы по сети.
VM Windows 11: Прямой проброс RTX 5090. Подключаем монитор/клавиатуру — и это мощнейший графический ПК. Или подключаемся удаленно через Moonlight.
VM Ubuntu Server + Docker (Portainer): Здесь живут “слуги”: Home Assistant (умный дом), Plex (кинотеатр), Nextcloud (ваше личное облако) и среды для разработки.

Экономика: Игрушка или Инвестиция?

Цена сборки чуть переваливает за 1 250 000 рублей. Безумие?
Смотря как посмотреть.

Если рассматривать это как консоль для игр — безумие.
Но если вы IT-инженер, DevOps или AI-энтузиаст, это устройство становится активом:

Аренда мощностей: В простое карту 5090 можно сдавать в аренду на площадках типа Vast.ai для обучения чужих нейросетей, отбивая стоимость “железа”.
Обучение и Карьера: Навыки поднятия Kubernetes-кластера дома или тонкой настройки LLM стоят на рынке труда гораздо дороже миллиона.
Свой стартап: Это готовый MVP-стенд для запуска своего AI-сервиса без трат на облака.

Итог

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

Добро пожаловать в клуб владельцев виртуальных “Monolith”. 🤪

UPD: 25.01.2026

Первый шаг к монолиту сделан.

Кстати, конфигурация немного поменялась. Самсунг ssd заменил в плане на Микрон серверный по 960gb, но 4 штуки. У них оказался срок службы гораздо большое. в 5-7 раз где-то. Они будут работать в Raid10 или raidz1 с блоком 32к. Места будет чуть меньше в raidz1, где то 2.7tb.

Почему Micron 7450 MAX 1.6TB лучше Samsung 990 PRO UPD: не подходит, надо 2280, будет или 800gb или найду Trancend с PLP

Сравниваем, опираясь на мануал материнской платы и датащит диска:

Бессмертие (Endurance):
- Samsung 990 PRO (2TB):** Ресурс ~1,200 TBW.
- Micron 7450 MAX (1.6TB): Ресурс **8,700 TBW (См. Table 3 в инструкции).
- Итог: Micron выносливее **в 7 раз. Вы можете писать на него базы данных и логи круглосуточно, и он переживет сам сервер.

Over-provisioning (Резервная область):
Почему объем такой странный — 1.6 ТБ, а не 2 ТБ?
Micron намеренно “скрыл” около 400 ГБ флеш-памяти. Контроллер использует это скрытое место, чтобы перемещать данные, выравнивать износ и поддерживать высокую скорость, когда диск заполнен.
У Samsung 990 PRO этой резервной области почти нет, поэтому при заполнении на 90% он начнет тормозить. Micron 7450 MAX будет работать на полной скорости даже если вы забьете его под завязку.

Скорость случайной записи (IOPS):
Для виртуалок важна запись мелких файлов (4K Random Write).

Micron 7450 PRO:** 120,000 IOPS.
Micron 7450 MAX: **250,000 IOPS (См. Table 2).
Модель MAX в два раза быстрее обычной серверной PRO-версии на запись. Это идеально для баз данных и ZFS SLOG.

Математика массива на Micron 1.6TB

Если берем 4 таких диска и делаем ZFS RAID10:

$$1.6 \text{ ТБ} \times 4 = 6.4 \text{ ТБ (Сырой объем)}$$
$$\text{Полезный объем (RAID10)} = 3.2 \text{ ТБ}$$

Еще большой плюс: PLP (Power Loss Protection) — Защита от потери питания, которая есть в Micron. На плате распаяны танталовые конденсаторы. Если питание пропадает, у диска есть еще несколько миллисекунд, чтобы сбросить всё из оперативной памяти в ячейки NAND = защита от отключения электропитания и потери данных.

Почему это важно для ZFS, он очень зависит от синхронной записи (Sync Writes) для баз данных и виртуальных машин. Зная, что у диска есть защита PLP, ZFS может безопасно отключать некоторые программные тормоза (O_DSYNC), работая значительно быстрее на мелких операциях записи.

Итого:
3.2 ТБ сверхбыстрого, защищенного от потери питания (PLP), “бессмертного” серверного пространства — это мечта для гипервизора Proxmox.

Короче берем Micron 7450 MAX 1.6TB. Это лучший компонент во всей сборке с точки зрения профессионального подхода. Главное найти его в форм-факторе 2280, а то на материнской плате есть только один длинный порт.

UPD: 22.02.2026

Проц едет.

Диски ssd пришлось заменить на Synology m2 1.6 – других с поддержкой PLP нету в наличии вообще. PLP нужна для защиты от обрывов питания резких. 4 планки будут в 10 массиве, стрейп и зеркало.

Память нашлась в наличии 90к – 48gb ecc ddr5 – но еще не брал(( надо сдать бутылки.

Свой Heroku: запустил Dokku дома и накатил новогоднего :)

Thu, 01 Jan 2026 22:59:46 +0300

Мы привыкли, что для развертывания веб-приложений нужно платить за VPS или разбираться в дебрях Kubernetes. Но если у вас есть домашний сервер (в моем случае — Asustor), вы можете создать свою собственную PaaS-платформу (Platform as a Service), которая работает по принципу *“git push — и готово”*.

Сегодня я расскажу, как настроить Dokku через Portainer, запустить веселое Python-приложение к Новому 2026 году и поделюсь лайфхаками по оптимизации сборки и масштабированию.

Часть 1. Фундамент: Запуск Dokku в Portainer

Dokku — это Docker-контейнер, который управляет другими Docker-контейнерами. Чтобы он заработал на NAS, его нужно правильно запустить. Я использовал Portainer Stack.

Docker Compose конфигурация

Вот рабочий `docker-compose.yml`, который решает главную проблему — доступность приложений из локальной сети.

# version: '3.2'
services:
  agent:
    image: dokku/dokku:${VERSION}
    pid: host.  # ⚠️ важно для работы на NAS
    network_mode: bridge # ⚠️ важно для работы на NAS
    environment:
      DOKKU_HOSTNAME: ${DOKKU_HOSTNAME}
      DOKKU_HOST_ROOT: ${DOKKU_HOST_ROOT}
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ${VOLUME_PATH:-/var/lib/dokku}:/mnt/dokku
    ports:
      - "3022:22" # ⚠️ важно для работы через ssh и что бы не конфликтовал с 22 
      - "80:80"    # Внешний порт 80 -> порт 80 внутри контейнера Dokku
      - "443:443"

Нюансы сети:
Чтобы обращаться к приложениям по красивым домегам типа `my-app.dokku.datahub.mother`, я настроил AdGuard Home в качестве локального DNS-сервера (фильтры получил бонусом – где-то 20% это всякие счетчики, ужас:). Добавил правило Rewrite: `*.dokku.datahub.mother` → `192.168.0.20` (IP моего NAS). Теперь все поддомены (приложения) автоматически ведут на Dokku.

Также для удобства я настроил `~/.ssh/config` на ноутбуке, чтобы не вводить порты вручную:

Host dokku.datahub.mother
  HostName 192.168.0.20
  Port 3022
  User dokku

ну и ключ сам так можно добавить

echo "ВАШ_ПУБЛИЧНЫЙ_КЛЮЧ" | dokku ssh-keys:add dokku

Часть 2. Приложение “my-first-app”: Новогоднее гадание

Для теста я написал простое Flask-приложение, которое рассчитывает ваш возраст в наступающем 2026 году.

Код приложения (`app.py`)

from flask import Flask, request

app = Flask(__name__)

@app.route('/')
def home():
    return """
    <h1>Приветствую в игре Нового 2026 года! 🎉</h1>
    <p>Это веселая интерактивная игра в честь Нового года. Угадай свой возраст на 1 января 2026!</p>
    <p>Введи свой год рождения:</p>
    <form action="/result" method="get">
        <input type="number" name="birth_year" min="1900" max="2025" required>
        <button type="submit">Угадать возраст на Новогодний 2026!</button>
    </form>
    """

@app.route('/result')
def result():
    birth_year = request.args.get('birth_year')
    if not birth_year or not birth_year.isdigit():
        return "Ошибка: введи корректный год рождения!"
    
    birth_year = int(birth_year)
    age_in_2026 = 2026 - birth_year
    return f"""
    <h2>Результат: 🎇</h2>
    <p>В 2026 году тебе будет {age_in_2026} лет!</p>
    <p>Счастливого Нового 2026 года! Пусть все твои желания сбудутся!</p>
    <a href="/">Играть снова</a>
    """

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Подготовка к деплою

Чтобы Dokku понял, как запускать это чудо, нужны два файла в корне проекта:

`requirements.txt` (зависимости):

Flask==2.3.2
gunicorn==20.1.0
Werkzeug==2.3.3

`Procfile` (команда запуска):

web: gunicorn app:app --bind 0.0.0.0:5000

`.python-version` (опционально, явная версия Python):

3.11.14

Процесс деплоя

Все делается через Git, как на “взрослых” платформах:

Создаем приложение на сервере:

ssh dokku@dokku.datahub.mother apps:create my-first-app

Отправляем код:

git init
    git add .
    git commit -m "Happy New Year 2026 version"
    git remote add dokku dokku@dokku.datahub.mother:my-first-app
    git push dokku master

Если вы до этого еще что-то деплоили, то лучше проверить куда гит смотрит

git remote -v

ну и поменяем еще не верное

git remote remove dokku

git init
    git add .
    git commit -m "Happy New Year 2026 version"
    git remote add dokku dokku@dokku.datahub.mother:my-first-app
    git push dokku master

После пуша Dokku сам скачает Python, установит Flask и запустит Gunicorn. Через минуту-две приложение доступно по адресу `http://my-first-app.dokku.datahub.mother`.

Еще нужно домен установить

ssh dokku@dokku.datahub.mother domains:set my-first-app my-first-app.dokku.datahub.mother

или можно сразу глобально его установить:

ssh dokku@dokku.datahub.mother domains:set-global dokku.datahub.mother
# но тогда придется удалить ручную привязку 
ssh dokku@dokku.datahub.mother domains:clear my-first-app

# не забыть перебрать nginx ( на всякий случай ) 
ssh dokku@dokku.datahub.mother proxy:build-config my-first-app

Сертификат сгенерировать

ssh dokku@dokku.datahub.mother certs:generate my-first-app my-first-app.dokku.datahub.mother

и проверить порты

ssh dokku@dokku.datahub.mother ports:report my-first-app

если порты не корректные, то можно их установить так:

ssh dokku@dokku.datahub.mother ports:set my-first-app http:80:5000 https:443:5000

Часть 3. Уровень PRO: Скорость (uv) и Marimo

Аппетит приходит во время еды. После простого Flask-приложения я решил развернуть что-то посерьезнее — Data Science ноутбук на Marimo, и столкнулся с реальными сложностями и особенностями. Для примера брал их дело ноутбук https://marimo.app

1. Ускорение сборки с `uv`

Стандартный `pip` устанавливает пакеты медленно. Если проект большой, деплой может висеть минутами.
Я перешел на uv — новый менеджер пакетов на Rust.

Вместо `requirements.txt` я использовал `pyproject.toml` и `uv.lock`. Dokku (благодаря современным buildpacks) увидел `uv.lock` и переключился на быстрый режим. Время сборки сократилось в разы.

2. Ловушка масштабирования (Scaling)

Marimo — это stateful приложение (хранит состояние в памяти). Flask, который мы делали выше — stateless.

Когда я задеплоил Marimo, Dokku по умолчанию все было хорошо, но потом я решил масштабировать его и сделал так

ssh dokku@dokku.datahub.mother ps:scale my-marimo-app web=3

далее Dokku запустил 3 копии контейнера (`web=3`).
Начался хаос:

Интерфейс открывался.
При нажатии кнопок вылетала ошибка `Invalid server token`.

Почему? Браузер загружал страницу с *Контейнера 1*, а WebSocket-запрос улетал в *Контейнер 2*, который ничего не знал про мою сессию.

Решение:
Для интерактивных приложений (Streamlit, Marimo, Jupyter) всегда принудительно ставьте одну реплику:
Ну ли придется делать липкие сессии на nginx или еще что-то.

ssh dokku.datahub.mother ps:scale my-marimo-app web=1 # все вернуло в рабочее состояние.

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

Вот так можно установить лимиты или повысить их:

ssh dokku.datahub.mother resource:limit my-marimo-app --memory 2G --cpu 2

3. SSL в локальной сети

Браузеры блокируют микрофон и иногда WebSockets на HTTP-сайтах. Для локальной сети Let’s Encrypt не сработает (нет публичного IP), ну и его чуть сложнее запускать.
Я решил вопрос генерацией самоподписанного сертификата одной командой Dokku:

ssh dokku.datahub.mother certs:generate my-first-app my-first-app.dokku.datahub.mother

Браузер ругается, но приложение работает полноценно.

Еще я прогнал стресс тесты

ab -n 10000 -k -c 2000 ...

Много они не показали, решением было подкрутить nginx, настроить кеш ssl, горизонтальное масштабирование не приносило больших результатов. я упирался в ограничения клиента при тестах нагрузки.

Итог

Dokku на домашнем сервере — это отличный инструмент.

Для простых API (Flask/FastAPI): Работает “из коробки” идеально.
Для сложных задач: Использование `uv` делает работу комфортной, а понимание разницы между *Stateless* и *Stateful* приложениями спасает от занудных ошибок и отладки.

Теперь my-first-app готово предсказывать возраст всем гостям на Новый год, а сервер готов к новым экспериментам! 🎄 Пожалуй оставлю его для будущих экспериментов. Прижился как-то быстро. Кстати у Dokku есть коммерческая PRO версия, а точнее не версия, а полноценный UI с кнопочками и стоит он 900$. https://dokku.com/docs/enterprise/pro/

Пора чего-нибудь накатить новогоднего еще :)

Эпоха «Толстого» браузера и революция локальных данных на WASM

Sat, 13 Dec 2025 01:20:55 +0300

В истории IT-архитектуры маятник всегда качался между двумя крайностями: централизацией и децентрализацией. Сначала были мейнфреймы (центр), затем «толстые» клиенты на ПК (локальные вычисления), а потом пришла эра веб-приложений, и индустрия массово мигрировала в Облака.

Мы привыкли считать браузер лишь «тонким окном», интерфейсом, где вся магия, сложные вычисления и хранение происходят где-то далеко — на серверах AWS или Google. Но сегодня правила игры меняются. Благодаря технологиям WebAssembly (WASM), современному «железу» и новым подходам, браузер превращается в полноценную операционную систему для анализа данных или еще чего-то blog.openreplay.com. Посмотрите статью о “Руководство по Разработке Local-First Приложений”.

Почему мы уходили в облака и почему возвращаемся?

Эра миграции в облака:
В 2010-х локальные машины были «бутылочным горлышком». Чтобы обработать гигабайты данных, требовались серверные стойки. Облака давали бесконечную масштабируемость. Архитектура сводилась к простой формуле: *данные пользователя → загрузка через сеть (latency) → обработка на сервере ($$$) → результат обратно клиенту*.

Проблемы сегодняшнего дня:

Избыточность мощностей: Современный ноутбук аналитика (даже базовый MacBook Air на M-чипе) обладает вычислительной мощностью, сопоставимой с сервером десятилетней давности. Эти ресурсы простаивают, пока компании платят за облачные CPU.
Сетевые задержки и стоимость: Передать CSV-файл на 2 ГБ в облако для простой фильтрации или агрегации — это долго и дорого (ingress/egress трафик).
Приватность: Передача чувствительных отчетов или персональных данных на чужой сервер для разового анализа всегда несет риски утечки и нарушений регуляторики.

Решение: Приложения Local-First

Технология WebAssembly (WASM) позволила запускать нативный код (C++, Rust, Go) прямо в песочнице браузера со скоростью, близкой к нативной habr.com. Это породило новый класс ПО, которое выглядит как веб-сайт, но работает как десктопное приложение. Вы заходите на страницу, она загружает легковесный движок, и далее вы можете отключить интернет — приложение продолжит «перемалывать» ваши данные локально.

Новые герои: Сервер внутри вкладки

Уже сейчас существуют продукты, которые меняют представление о работе с данными. Они объединяют UX веб-приложений с мощностью десктопного софта, создавая ощущение, что сервер находится прямо у вас в RAM.

1. DataKit — Швейцарский нож аналитика

Проект DataKit.page — яркий пример такой архитектуры. Это не просто “просмотрщик файлов”, это полноценная ETL/Analytics платформа, живущая в вашем браузере.

Как это работает: Вы перетаскиваете массивные файлы (CSV, JSON, Excel, Parquet) в окно. Они не загружаются на внешний сервер. Браузер получает доступ к файлу через `File System Access API`, а движок (основанный на DuckDB WASM) монтирует их виртуально.
Функционал:
- SQL и Python в одном окне: Внутри работает не только SQL-движок, но и Python (через Pyodide). Вы можете использовать `pandas`, `polars`, `numpy` и строить графики `matplotlib`, обращаясь к данным прямо с вашего диска.
- AI на борту: Интеграция с локальными LLM (через Ollama) или облачными провайдерами позволяет писать запросы на естественном языке, при этом сама схема и данные остаются у вас.
- Умные форматы и коннекторы: Платформа «нативно» понимает Parquet и вложенные JSON, автоматически определяя типы данных и аномалии. Кроме того, она может подключаться к S3, Google Sheets и базам данных PostgreSQL, выполняя федеративные запросы.

2. DuckDB Local UI — SQL без инсталляции

Команда DuckDB в сотрудничестве с MotherDuck выпустила официальный локальный UI, работающий через расширение. Это прямой ответ на боль пользователей консольных утилит и отличный пример гибридного подхода habr.com.

Сценарий: Раньше, чтобы поработать с локальной базой данных, нужно было либо мучиться в CLI, либо ставить тяжелый DBeaver. Теперь одной командой `duckdb -ui` или SQL-вызовом `CALL start_ui();` запускается локальный веб-сервер и открывается современный Notebook-интерфейс.
Гибридность: Вы работаете локально, но интерфейс имеет встроенную бесшовную интеграцию с облачным сервисом MotherDuck. Если для разового анализа локальных ресурсов достаточно, вы делаете это приватно. Как только требуется коллаборация или более мощные вычисления, вы можете переключить контекст выполнения в облако в том же окне.

3. Marimo – тетрадки, почти тот же подход имеет

https://gavrilov.info/all/tetradki-nashe-vsyo-marimo-io-i-utochkadb/

3. PGlite и PondPilot — Postgres и SQL-песочницы

PGlite: Этот проект идет еще дальше и компилирует полноценный PostgreSQL в WASM, позволяя запускать его в браузере или Node.js без эмуляции ОС habr.com. Это идеально для тестирования, прототипирования и создания приложений, которые требуют совместимости с Postgres.
PondPilot: Пример open-source SQL-редактора, построенного вокруг DuckDB-WASM habr.com. Он позволяет быстро анализировать локальные файлы (CSV, Parquet, JSON), сохраняет историю, поддерживает вкладки и даже предлагает виджет для встраивания интерактивных SQL-примеров в блоги и документацию.

Сдвиг парадигмы: От DBeaver к Браузеру

Многие аналитики и инженеры привыкли к классическим клиентам баз данных (DBeaver, DataGrip). Это мощные, но «тяжелые» инструменты, требующие установки, настройки драйверов и обновлений. Новый WASM-тренд предлагает более гибкую альтернативу.

Сценарий «Мгновенной аналитики»:
Представьте, что вам прислали ссылку на лог-файл в S3 размером 5 ГБ или Parquet-дамп.

Старый путь: Скачать файл → Установить/открыть DBeaver → Настроить драйвер → Импортировать → Ждать загрузки → Писать SQL.
Новый путь (WASM): Открыть ссылку веб-приложения → Перетащить файл (или указать S3 URL) → Мгновенно писать SQL.

Еще вариант, лог 30ГБ и вы заказали функционал в другой команде, она с радостью сказала, что через два спринта сделает пайплайн за неделю, но ей надо требования. Вы их конечно написали на основе небольшого семпла строк из excel или на основе документации и отдали в разработку. А через месяц получили отличный пайплайн или, который не нужен или его нужно еще доработать.

Технологическая магия за кулисами:

Apache Arrow: Это скрытый герой революции. Бинарный колоночный формат Arrow позволяет передавать данные из SQL-движка (DuckDB) в JavaScript-интерфейс или Python-ячейку без копирования и сериализации памяти (Zero-copy). Это обеспечивает мгновенную реакцию интерфейса на миллионах строк — то, чего раньше было невозможно добиться при работе с DOM. (все помним D3JS)
Федеративные запросы: Локальное приложение умеет «ходить» в интернет. Вы можете написать `SELECT * FROM ‘s3://my-bucket/file.parquet’` прямо из браузера. Движок скачает только нужные байты (range requests), обработает их локально и покажет результат. Данные не оседают на промежуточных серверах разработчика софта.

Органическое масштабирование и новая экономика

Для архитекторов платформ данных этот тренд открывает удивительную экономическую модель «Bring Your Own Compute» или «Client-side computing» (Принеси Свои Вычисления).

Масштабирование без усилий: Вам не нужно создавать сложный кластер, чтобы тысячи пользователей могли фильтровать свои Excel-файлы. Вы просто хостите статические JS/WASM файлы на CDN.
Органическая нагрузка: Вычислительная мощность вашего “облака” растет линейно с количеством пользователей, потому что каждый новый пользователь приносит свой CPU и RAM. Пользователи выключают компьютеры — ваше “облако” естественным образом уменьшается.
Коллаборация и Воспроизводимость:**
- *Разовая задача:* Сделал анализ локально, закрыл вкладку — данные исчезли из памяти (полная приватность).
- *Командная работа:* Написал SQL/Python код локально, сохранил его (текст скрипта весит килобайты) и отправил коллеге. Коллега открыл ту же ссылку, подгрузился код, и магия вычислений произошла уже на его машине над теми же данными (если они в общем S3) или над его локальной копией.

Итого

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

Разработчикам и Архитекторам:

Присмотритесь к Serverless 2.0: Истинный `serverless` — это не AWS Lambda, за которую вы платите. Это когда сервера нет вообще, а код исполняется на клиенте (`client-side computing`). Это дешевле, быстрее для пользователя и безопаснее, удобно разрабатывать и обновлять код.
Privacy-first как преимущество: Позиционируйте такие решения как безопасные по умолчанию. Аргумент “Ваши данные никогда не покидают ваш компьютер” становится решающим для Enterprise-сектора.
Гибридная архитектура: Не отказывайтесь от сервера полностью. Пусть браузер берет на себя интерактивную работу, парсинг и предобработку, а сервер подключается для тяжелых “батчей” или работы с петабайтами данных в том же привычном окне.

Пользователям и Аналитикам:

Осваивайте инструменты: Попробуйте https://datakit.page, https://app.pondpilot.io или DuckDB WASM Shell для разведочного анализа данных. Это часто быстрее, чем запускать локальный Jupyter.
Используйте облачные хранилища напрямую: Учитесь подключать S3, Google Sheets и другие облачные источники напрямую к таким инструментам. Это дает мощь облачного хранения в сочетании со скоростью и приватностью локального интерфейса.

Ренессанс локальных вычислений начался. Ваш браузер способен на большее, чем просто отображать HTML. Он становится вашей персональной дата-лабораторией.

Обзор pg_clickhouse: Как объединить мощь ClickHouse и удобство PostgreSQL

Fri, 12 Dec 2025 23:27:54 +0300

Недавно компания ClickHouse представила новый инструмент — расширение pg_clickhouse. Это событие стало ответом на одну из самых частых болей разработчиков: сложность миграции аналитических запросов из классических реляционных баз данных в колоночные аналитические СУБД.

Оригинал статьи: A Postgres extension for querying ClickHouse

или берем сразу тут: https://github.com/ClickHouse/pg_clickhouse/releases

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

Проблема: Данные переехали, а запросы остались

Типичный сценарий роста стартапа выглядит так: приложение строится на PostgreSQL. В какой-то момент данных (логов, метрик, транзакций) становится так много, что аналитические отчеты начинают тормозить. Обычные реплики для чтения (read replicas) перестают спасать.

Команда принимает решение внедрить ClickHouse. Перенос данных сейчас решается просто (например, с помощью ClickPipes), но возникает другая проблема:
Как быть с тысячами строк SQL-кода в ORM, дашбордах и скриптах, которые написаны под синтаксис Postgres?

Переписывание всей логики приложения под диалект ClickHouse — это месяцы работы и риск новых багов. Именно эту проблему решает `pg_clickhouse`.

Что такое pg_clickhouse?

pg_clickhouse — это расширение для PostgreSQL (Foreign Data Wrapper — FDW), которое позволяет создавать в Postgres «внешние таблицы», фактически ссылающиеся на таблицы в ClickHouse.

Суть технологии: Вы пишете запросы на привычном SQL диалекте PostgreSQL, обращаясь к этим таблицам. Расширение на лету транслирует запрос в диалект ClickHouse, отправляет его на исполнение в аналитическую базу и возвращает результат обратно в Postgres.

Для приложения это выглядит прозрачно: таблицы ClickHouse могут находиться просто в отдельной схеме (schema). Достаточно изменить путь поиска (`search_path`), и старые запросы начнут работать с данными, лежащими в ClickHouse.

В чем «соль»: Технология Pushdown

Главная ценность и сложность такого расширения заключается не просто в соединении двух баз, а в эффективности этого соединения. Этот механизм называется Pushdown (спуск или делегирование вычислений).

Если вы делаете запрос `SELECT sum(price) FROM orders`, есть два пути его выполнения:

Плохой путь: Postgres выкачивает *все* миллионы строк из ClickHouse и сам считает сумму. Это уничтожает весь смысл аналитической базы.
Путь pg_clickhouse: Расширение понимает, что это агрегация, и отправляет в ClickHouse команду «посчитай сумму». Обратно по сети возвращается только одна цифра.

Умная трансляция функций

Авторы `pg_clickhouse` пошли дальше простой трансляции. Они научили расширение переводить специфические функции Postgres в аналоги ClickHouse, даже если синтаксис кардинально отличается.

*Пример:*
В Postgres есть функция для расчета медианы: `percentile_cont(0.5) WITHIN GROUP (ORDER BY price)`.
В ClickHouse такой синтаксис не поддерживается.
`pg_clickhouse` автоматически переписывает это в нативную функцию ClickHouse: `quantile(0.5)(price)`.

Также поддерживается трансляция конструкции `FILTER (WHERE ...)` в специфичные для ClickHouse комбинаторы `-If` (например, `sumIf`).

Ускорение подзапросов (Semi-Join)

В версии 0.1.0 была реализована поддержка SEMI JOIN Pushdown. Это критически важно для запросов с конструкцией `WHERE ... IN (SELECT ...)` или `EXISTS`. Тесты на бенчмарке TPC-H показали, что благодаря этому время выполнения сложных запросов сократилось с нескольких секунд (или даже минут) до миллисекунд, так как фильтрация теперь происходит на стороне ClickHouse.

Планы развития (Roadmap)

Проект находится в стадии активной разработки (версия 0.1.0), и команда ClickHouse нацелена на полное покрытие аналитических сценариев.

Ключевые пункты плана:

Полное покрытие TPC-H и ClickBench: Оптимизация планировщика, чтобы все стандартные аналитические бенчмарки выполнялись с максимальным pushdown-ом.
Расширенная поддержка функций: Трансляция *всех* агрегатных и обычных функций PostgreSQL в их эквиваленты в ClickHouse.
DML операции: Поддержка легковесных удалений (`DELETE`) и обновлений (`UPDATE`), а также пакетной вставки данных через `COPY`.
Управление настройками: Возможность передавать настройки ClickHouse (settings) через команды создания пользователей или серверов в Postgres.
Passthrough-режим: Возможность отправить произвольный SQL-запрос (на диалекте ClickHouse) и получить результат в виде таблицы, обходя парсер Postgres.

Заключение

`pg_clickhouse` — это попытка построить «лучшее из двух миров»: взять скорость колоночной СУБД и объединить её с богатой экосистемой и инструментарием PostgreSQL. Это позволяет разработчикам плавно мигрировать нагрузку, не переписывая приложение с нуля, и оставляет Postgres в качестве единой точки входа для данных.

KubeVela: Современная доставка приложений

Mon, 08 Dec 2025 01:10:10 +0300

В мире Cloud-Native технологий Kubernetes стал операционной системой облака. Однако, как было отмечено в материалах про Rainbond, «ванильный» Kubernetes сложен для разработчиков. Если Rainbond решает эту проблему, предлагая готовый PaaS «из коробки» с упором на UI, то KubeVela подходит к задаче с другой стороны: это двигатель для построения собственной платформы (Platform Engine), основанный на модели OAM (Open Application Model).

https://kubevela.io

KubeVela позволяет создавать простые и ориентированные на приложение (Application-centric) абстракции, сохраняя при этом полную гибкость и управляемость через код (Infrastructure as Code).

Основная философия: OAM и разделение ответственности

В основе KubeVela лежит стандарт OAM (Open Application Model). Эта модель разделяет ответственность между двумя ролями:

Разработчиĸи (Developers): Описывают что нужно запустить (образ контейнера, порт, параметры запуска).
Платформенные инженеры (Platform Engineers): Описывают ĸаĸ это должно работать (инфраструктура, политики масштабирования, Ingress, безопасность).

Математически модель приложения в KubeVela можно выразить формулой:

$$ Application = Components + Traits + Workflow $$

Где:

Components: Основная рабочая нагрузка (Workload). Например, Docker-образ, Helm-чарт или даже Terraform-модуль.
Traits (Свойства/Черты): Операционные характеристики, подключаемые к компоненту. Например: `ingress`, `scaler`, `sidecar`.
Workflow: Цепочка шагов доставки (Deploy -> Test -> Promote).

Пример манифеста KubeVela

Вместо десятков Kubernetes-ресурсов (Deployment, Service, Ingress, HPA), разработчик пишет один упрощенный файл:

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: website
spec:
  components:
    - name: frontend
      type: webservice
      properties:
        image: nginx
      traits:
        - type: scaler
          properties:
            replicas: 3
        - type: gateway
          properties:
            domain: test.example.com

Сравнение: KubeVela vs Rainbond

Основываясь на прошлой статье про Rainbond, сделаем детальное сравнение. Оба инструмента решают проблему сложности Kubernetes, но нацелены на разные аудитории.

Хараĸтеристиĸа	Rainbond	KubeVela
Философия	No-Code / Low-Code PaaS. Готовая платформа с полным UI. Ориентация на визуальное управление.	Platform Engine / IaC. Инструментарий для создания платформы. Ориентация на GitOps и конфигурацию как код.
Входной порог	Очень низкий. Не нужно знать Kubernetes. Можно собрать приложение из `.jar` или исходного кода одной кнопкой.	Средний. Требует понимания концепций OAM. Инженерам платформы нужно знать CUE (язык конфигурации).
Гибĸость	Ограничена возможностями UI платформы. Сложно кастомизировать внутреннюю логику деплоя нестандартных вещей.	Высочайшая. Любая абстракция настраивается через X-Definitions (на языке CUE). Можно описать любой ресурс K8s или Terraform.
Интеграция IaC	Базируется на внутренних механизмах.	Нативная интеграция с Terraform. KubeVela может разворачивать облачные базы данных (AWS RDS, Cloud SQL) как часть приложения.
Multi-cluster	Есть управление несколькими кластерами, но фокус на единой панели управления.	Сильная сторона. Мощный движок развертывания приложений сразу в несколько кластеров с политиками (Placement Policies).
Для ĸого	SMB, стартапы, команды без сильной экспертизы в K8s, желающие получить опыт Heroku на своих серверах.	Enterprise, Platform Engineering команды, желающие построить свой внутренний PaaS (IDP) по стандартам Spotify/Netflix.

Сравнение с другими аналогами

Crossplane:
- Crossplane фокусируется на «Инфраструктуре» (создание баз данных, кластеров, сетей в облаках через K8s API).
- KubeVela фокусируется на «Приложении».
- Итог: Они часто используются вместе. KubeVela использует Crossplane для заказа ресурсов.

ArgoCD / Flux (GitOps):
- Это инструменты непрерывной доставки (CD), которые синхронизируют Git и K8s.
- KubeVela может использовать их под капотом или использовать свой собственный Workflow-контроллер для сложных сценариев (например, «засуспендить деплой, пока не пройдет тест, затем отправить уведомление в Slack»).

Backstage:
- Backstage — это «Портал» (Frontend). KubeVela — это «Движок» (Backend).
- Существует плагин `vela-backstage`, который позволяет визуализировать приложения KubeVela внутри интерфейса Backstage. Это идеальная связка для построения IDP.

Ключевые возможности KubeVela

1. Программируемая абстраĸция (CUE Language)

В отличие от Helm, где шаблонизация — это просто подстановка строк, KubeVela использует язык CUE (Configure Unify Execute). Это позволяет платформенным инженерам создавать «умные» шаблоны.

Пример логики на CUE внутри KubeVela: «Если пользователь не указал CPU, автоматически поставить `requests: 100m`, но если это ‘prod’ окружение, то поставить `500m`».

2. Единый Workflow для всего

KubeVela позволяет оркестрировать не только Kubernetes-ресурсы. В одном пайплайне вы можете:

Создать S3 бакет в AWS (через Terraform/Crossplane).
Дождаться готовности.
Задеплоить Deployment в Kubernetes.
Отправить уведомление в Telegram.

3. Отсуствие «Config Drift»

KubeVela активно борется с дрейфом конфигураций, постоянно сверяя желаемое состояние приложения с реальным (State Reconciliation).

Итог и реĸомендации

Выбор между Rainbond и KubeVela зависит от того, ĸто будет обслуживать платформу и ĸаĸие цели стоят перед бизнесом.

Выбирайте Rainbond, если:

У вас небольшая или средняя команда разработчиков.
Нет выделенного отдела Platform Engineering / DevOps.
Нужно «вчера» перенести легаси (Java/PHP/Monolith) в контейнеры без переписывания кода.
Вам нужен визуальный интерфейс для управления связями сервисов и мониторинга без написания YAML.
Цель: Быстрый Time-to-market с минимальными затратами на инженерию.

Выбирайте KubeVela, если:

Вы строите серьезный Internal Developer Platform (IDP) в крупной компании.
У вас есть инженеры, знающие Kubernetes, но вы хотите скрыть его сложность от продуктовых разработчиков.
Вам нужен строгий GitOps подход (все через репозиторий).
Требуется гибридное развертывание: часть в K8s, часть в Serverless, часть в облачных RDS.
Вы планируете использовать Backstage в качестве фронтенда.
Цель: Стандартизация, масштабируемость, полный контроль над абстракциями (Platform as Product).

Рекомендация по стеĸу для Enterprise:
Для максимальной эффективности современный стек платформенной инженерии часто выглядит так:
$$ \text{Backstage (UI)} + \text{KubeVela (Engine)} + \text{Crossplane (Infra)} $$
Эта связка дает удобство портала (как в Rainbond), мощь оркестрации (KubeVela) и управление облаком (Crossplane).

Сравнительный анализ self-hosted S3-совместимых хранилищ

Mon, 08 Dec 2025 00:50:17 +0300

Четкое сравнение семи self-hosted S3-совместимых решений для хранения данных.

Оригинал тут: Команда RepoFlow. 9 августа 2025 г.

Локальное (self-hosted) объектное хранилище — это отличный выбор для разработчиков и команд, которые хотят иметь полный контроль над хранением и доступом к своим данным. Независимо от того, заменяете ли вы Amazon S3, размещаете внутренние файлы, создаете CI-конвейер или обслуживаете репозитории пакетов, уровень хранения может значительно повлиять на скорость и стабильность.

Мы протестировали семь популярных решений для объектного хранения, поддерживающих протокол S3. Цель состояла в том, чтобы сравнить их производительность в идентичных условиях, используя реальные операции загрузки и скачивания.

Тестируемые решения

Каждое из следующих решений было развернуто с помощью Docker на одном и том же сервере без монтирования томов и без специальной настройки:

`MinIO`
`Ceph`
`SeaweedFS`
`Garage`
`Zenko` (Scality Cloudserver)
`LocalStack`
`RustFS`

Скорость последовательного скачивания

Средняя скорость скачивания одного файла разного размера.

[Изображение: График скорости последовательного скачивания для малых файлов размером 50 КБ и 200 КБ. По оси Y — скорость в МБ/с, по оси X — размер файла. Сравниваются Garage, Localstack, Minio, Zenko, Ceph, RustFS, SeaweedFS.]

[Изображение: График скорости последовательного скачивания для больших файлов размером 10 МБ, 50 МБ, 100 МБ и 1 ГБ. По оси Y — скорость в МБ/с, по оси X — размер файла. Сравниваются те же решения.]

Скорость последовательной загрузки

Средняя скорость загрузки одного файла разного размера.

[Изображение: График скорости последовательной загрузки для малых файлов размером 50 КБ и 200 КБ. По оси Y — скорость в МБ/с, по оси X — размер файла. Сравниваются те же решения.]

[Изображение: График скорости последовательной загрузки для больших файлов размером 10 МБ, 50 МБ, 100 МБ и 1 ГБ. По оси Y — скорость в МБ/с, по оси X — размер файла. Сравниваются те же решения.]

Производительность листинга

Измеряет время, необходимое для получения списка всех 2000 тестовых объектов в бакете с использованием разных размеров страницы (100, 500 и 1000 результатов на запрос).

[Изображение: График производительности листинга. По оси Y — время в мс, по оси X — количество результатов на страницу (100, 500, 1000). Сравниваются те же решения.]

Скорость параллельной загрузки

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

(number of files × file size) ÷ total time

Скорость параллельной загрузки – файлы 1 МБ

[Изображение: График скорости параллельной загрузки файлов размером 1 МБ. По оси Y — скорость в МБ/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]

Скорость параллельной загрузки – файлы 10 МБ

[Изображение: График скорости параллельной загрузки файлов размером 10 МБ. По оси Y — скорость в МБ/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]

Скорость параллельной загрузки – файлы 100 МБ

[Изображение: График скорости параллельной загрузки файлов размером 100 МБ. По оси Y — скорость в МБ/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]

Скорость параллельного скачивания

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

(number of files × file size) ÷ total time

Скорость параллельного скачивания – файлы 1 МБ

[Изображение: График скорости параллельного скачивания файлов размером 1 МБ. По оси Y — скорость в МБ/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]

Скорость параллельного скачивания – файлы 10 МБ

[Изображение: График скорости параллельного скачивания файлов размером 10 МБ. По оси Y — скорость в МБ/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]

Скорость параллельного скачивания – файлы 100 МБ

[Изображение: График скорости параллельного скачивания файлов размером 100 МБ. По оси Y — скорость в МБ/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]

Как проводились тесты

Для каждого решения мы:

Загружали и скачивали файлы 7 различных размеров: 50 КБ, 200 КБ, 1 МБ, 10 МБ, 50 МБ, 100 МБ и 1 ГБ.
Повторяли каждую загрузку и скачивание 20 раз для получения стабильных средних значений.
Измеряли среднюю скорость загрузки и скачивания в мегабайтах в секунду (МБ/с).
Выполняли все тесты на одной и той же машине, используя стандартный Docker-контейнер для каждой системы хранения, без внешних томов, монтирования или кешей.

Все решения тестировались в одноузловой конфигурации для обеспечения согласованности. Хотя некоторые системы (например, `Ceph`) спроектированы для лучшей производительности в кластерной среде, мы использовали одинаковые условия для всех решений, чтобы гарантировать справедливое сравнение.

Заключительные мысли

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

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

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

Open Source порталы разработки и что такое IDP

Wed, 24 Sep 2025 23:12:48 +0300

На рынке внутренних порталов разработчика существует один явный лидер в категории open source — Backstage. Большинство других популярных решений, таких как Port, являются коммерческими (SaaS) продуктами, хотя они и могут предлагать open source компоненты для интеграции https://internaldeveloperplatform.org/developer-portals/port/

Поэтому основной фокус в open source сегменте приходится именно на Backstage, который был создан в Spotify и позже передан в Cloud Native Computing Foundation (CNCF).

Ключевое решение: Backstage

Backstage — это не готовый продукт, а фреймворк для создания собственного портала разработчика https://cloudomation.com/cloudomation-blog/5-internal-developer-portals-and-what-software-engineers-say-about-them/. Это его главное преимущество и одновременно главный недостаток. Он предоставляет базовые строительные блоки и архитектуру, на основе которых компании могут построить портал, идеально соответствующий их процессам и инструментам.

Кстати очень интересная статья про порталы, платформы и их различия.

Картинка от портала Cortex – ну прям огонь сайт у них https://www.cortex.io.

Cloudomation Guide – Building Internal Developer Platforms.pdf есть еще гайд обобщенный. А основная концепция конечно тут https://internaldeveloperplatform.org

Основные компоненты Backstage:

Software Catalog: Единый реестр для всех программных активов компании (микросервисы, библиотеки, веб-сайты, ML-модели и т.д.). Позволяет централизовать метаданные, информацию о владельцах, зависимостях и состоянии.
Software Templates (Scaffolder): Инструмент для создания новых проектов по заранее подготовленным шаблонам. Это стандартизирует первоначальную настройку сервисов, CI/CD пайплайнов, репозиториев и т.д.
TechDocs: Решение для создания, поддержки и отображения технической документации по принципу “docs-as-code”, когда документация хранится вместе с кодом.
Плагины: Экосистема Backstage строится вокруг плагинов. Существует огромное количество готовых плагинов для интеграции с AWS, Kubernetes, GitHub, CI/CD системами, системами мониторинга и многими другими. Если нужного плагина нет, его можно разработать самостоятельно.

Сравнение подходов: Build vs. Buy

Поскольку настоящий open source конкурент у Backstage практически отсутствует, наиболее корректно сравнить его не с другим open source решением, а с подходом использования коммерческих SaaS-платформ, ярким представителем которых является Port.

Port** — это коммерческий продукт, который предлагает готовый к использованию портал. Его философия заключается в гибкой модели данных на основе “blueprints” (шаблонов сущностей) и взаимосвязей между ними. Port позволяет быстро агрегировать данные из различных источников и построить каталог без необходимости развертывания и поддержки сложной инфраструктуры 10-best-internal-developer-portals-to-consider. Хотя ядро продукта закрыто, его интеграции и экспортеры данных являются открытыми [internaldeveloperplatform.org](https://internaldeveloperplatform.org/developer-portals/port/).

Сравнительная таблица: Backstage vs. Коммерческие IDP (на примере Port)

Критерий	Backstage (Open Source)	Коммерческие решения типа Port (SaaS)
Модель лицензирования	Open Source (Apache 2.0). Бесплатно.	Коммерческая (SaaS). Платная подписка.
Философия / Подход	Фреймворк для создания портала. “Построй свой дом”.	Готовый продукт для настройки портала. “Купи и настрой квартиру”.
Сложность внедрения	Высокая. Требуется разработка, развертывание и поддержка. Есть кривая обучения [cloudomation.com](https://cloudomation.com/cloudomation-blog/5-internal-developer-portals-and-what-software-engineers-say-about-them/).	Низкая / Средняя. Быстрый старт, не требует своей инфраструктуры.
Требования к команде	Нужна выделенная команда платформенных инженеров для разработки и поддержки портала.	Может управляться одним или несколькими DevOps-инженерами. Не требует навыков фронтенд-разработки.
Гибкость и кастомизация	Максимальная. Можно изменить и доработать абсолютно все, создать уникальные плагины и логику.	Высокая, но ограничена возможностями платформы. Кастомизация интерфейса и логики возможна в рамках, заданных вендором.
Инфраструктура	Требует собственной инфраструктуры для хостинга (обычно Kubernetes), базы данных, CI/CD для самого портала.	Не требует. Хостится и управляется вендором.
Экосистема и интеграции	Огромная, управляемая сообществом. Большое количество open source плагинов.	Управляется вендором. Интеграции создаются вендором, но часто есть открытые API и экспортеры данных.
Общая стоимость владения (TCO)	Скрытая и высокая. Лицензия бесплатна, но основные затраты — это зарплаты команды разработки и поддержки, а также стоимость инфраструктуры.	Прозрачная и предсказуемая. Основные затраты — стоимость подписки.
Поддержка	Сообщество (Slack, GitHub Issues).	Коммерческая поддержка от вендора (SLA, выделенный менеджер).

Выбор между open source фреймворком вроде `Backstage` и коммерческим продуктом — это классический выбор между “Build” (создавать) и “Buy” (покупать).

`Backstage` — это стратегическая инвестиция. Это мощное решение для крупных или технологически зрелых компаний, у которых уже есть выделенная платформенная команда и которые готовы вкладывать ресурсы в создание идеально подогнанного под себя инструмента. `Backstage` дает полный контроль, избавляет от зависимости от вендора (vendor lock-in) и позволяет решать уникальные задачи, которые не могут покрыть коробочные продукты.

Коммерческие IDP (такие как Port) — это тактическое решение для быстрого результата. Они идеально подходят для малых и средних компаний, или для крупных организаций, которые хотят быстро запустить портал и проверить гипотезы, не формируя для этого отдельную команду разработки. Этот подход обеспечивает быстрый старт, предсказуемые затраты и перекладывает всю головную боль по поддержке и развитию платформы на плечи вендора.

Руководство

Создание внутренних платформ для разработчиков: лучшие практики, инструменты и стратегические выводы для технических лидов

***

Кратко о чем все это?

Ниже представлен обзор внутренних платформ для разработчиков (Internal Developer Platforms, или IDP). Поскольку инженерные команды сталкиваются с растущей сложностью, IDP становятся решением для снижения разногласий между разработкой и эксплуатацией.

Независимо от того, оцениваете ли вы готовые платформы или создаете собственное решение, этот документ предлагает ценные сведения и тщательно подобранные ресурсы, которые помогут вам эффективно пройти путь внедрения IDP.

Основные тезисы:

IDP — это платформы самообслуживания, созданные инженерами платформ для оптимизации разработки программного обеспечения за счет автоматизации развертываний, конфигураций и управления средами.
Преимущества: Сокращение времени, затрачиваемого на настройку и отладку, снижение когнитивной нагрузки на разработчиков, повышение надежности и соответствия требованиям, а также более высокая операционная эффективность.
Каждая IDP уникальна, но обычно состоит из фронтенда, бэкенда и других интегрированных инструментов.
Ключевые возможности IDP должны включать: API, пользовательский интерфейс, автоматизацию, механизмы ограничений (например, политики), документацию и возможность обнаружения сервисов (discoverability).
Для создания по-настоящему целостной IDP необходимо сосредоточиться на интеграции всех необходимых инструментов и сервисов.
При внедрении IDP могут возникнуть следующие проблемы: попытка сделать все сразу (и не достичь ничего), нехватка ресурсов и бюджета, невозможность поддерживать каталог программного обеспечения в актуальном состоянии и недостаток коммуникации между людьми.
Обосновывая необходимость внедрения IDP, подкрепляйте свои аргументы данными и связывайте их с рисками и результатами, которые больше всего волнуют ваше руководство.

***

Содержание

Что такое IDP?
Зачем нужны IDP?
Как работают IDP?
Обоснование необходимости IDP для бизнеса
Лучшие практики для создания IDP
Инструменты платформенной инженерии для создания IDP
3 проблемы при создании IDP
Ресурсы

1. Что такое IDP?

Внутренние платформы для разработчиков (IDP) лежат в основе дисциплины платформенной инженерии (Platform Engineering).

Пояснение:
Внутренняя платформа для разработчиков — это, по сути, продукт, предназначенный для разработчиков внутри организации. Она предоставляет им доступ по принципу самообслуживания к технической инфраструктуре и рабочим процессам, таким как конвейеры развертывания или облачные ресурсы. пост на dev.to. Ключевая идея — относиться к своей внутренней платформе как к продукту, а к разработчикам — как к клиентам. еще пост с dev.to. Это позволяет им не ждать выполнения заявок в отдел эксплуатации и не нести полную ответственность за инфраструктуру, как в модели «you build it, you run it».

IDP призваны решить вечную проблему, которая преследует всех разработчиков ПО: программное обеспечение чрезвычайно сложно, и ни один человек не может знать всего, что требуется для создания целого программного продукта.

Понимание внутренних платформ для разработчиков

На схеме ниже показаны ключевые концепции, лежащие в основе IDP.

Подходы «Инфраструктура как код» (As-Code Approaches): Акцент на автоматизацию и документирование через код.
«Золотые пути» (Golden Paths): Предоставление заранее определенных, проверенных и поддерживаемых путей для выполнения типовых задач (например, создание нового сервиса, развертывание в среде). Разработчики могут легко следовать этим путям, будучи уверенными в результате.
Самообслуживание (Self-Service): Позволяет разработчикам самостоятельно использовать платформу без необходимости обращаться в другие команды.
Управление как продуктом (Managed like a product): У платформы есть свой жизненный цикл выпуска, владелец продукта и дорожная карта развития.
Инженеры платформы (Platform Engineers): Создают и поддерживают IDP, фокусируясь на ценности для разработчиков.
Разработчики ПО (Software Developers): Основные пользователи, которые взаимодействуют с IDP.

Функции IDP

IDP предоставляют функции, которые являются центральными в повседневной работе разработчиков программного обеспечения.

Это лишь примеры функций, которые может иметь IDP. Каждая IDP уникальна для организации, которая ее использует. Часто они создаются с нуля или сильно кастомизируются под нужды компании.

2. Зачем нужны IDP?

По мере усложнения процесса поставки ПО организации сталкиваются с фрагментированными практиками DevOps, несогласованными рабочими процессами и операционной неэффективностью. От разработчиков ожидают, что они будут управлять инфраструктурой, конвейерами CI/CD, политиками безопасности и мониторингом, что часто приводит к когнитивной перегрузке и снижению производительности. Именно здесь на помощь приходят платформенная инженерия и IDP.

Раскрывая мощь IDP

Ускорение циклов разработки: Оптимизированное развертывание сокращает время, затрачиваемое на настройку и отладку.
Снижение когнитивной нагрузки на разработчиков: Упрощенное управление инфраструктурой позволяет сосредоточиться на написании кода.
Повышение надежности и соответствия требованиям (Compliance): Обеспечивает последовательное применение политик безопасности и соответствия во всех развертываниях.
Повышение инженерной эффективности: Автоматизирует управление ресурсами, повышая операционную эффективность.

3. Как работают IDP?

Каждая IDP уникальна, но есть некоторые общие характеристики, присущие большинству из них. В самом простом виде каждая IDP состоит примерно из трех «частей»:

Фронтенд IDP
Бэкенд IDP
Множество других инструментов, интегрированных с IDP

Фронтенд: Пользовательский интерфейс для доступа разработчиков к IDP. Часто это внутренний портал разработчика (Internal Developer Portal).
Бэкенд: Управляет интеграцией и автоматизацией с другими инструментами. Эту роль часто выполняет оркестратор платформы.
Интегрированные инструменты: Различные инструменты, которые работают с IDP для выполнения ключевых процессов (CI/CD, мониторинг, безопасность и т.д.).

Архитектура

Следующая диаграмма архитектуры, основанная на модели CNOE (Cloud Native Operational Excellence), дает более детальное представление.

Ранее писал про Rainbond китайский, там немного другой акцент, но их архитектура тоже интересная, а так как это опенсорс, то можно свой такой запилить, но переводить придется :)

В этой диаграмме «Портал разработчика» (`Developer Portal`) является фронтендом IDP. Компонент «Оркестрация рабочих процессов» (`Workflow Orchestration`) будет бэкендом.

Ниже приведен более подробный пример архитектуры, показывающий, какие типы инструментов и сервисов могут быть частью IDP, сгруппированные по функциональным уровням (плоскостям).

Ключевая функциональность IDP

Основная идея IDP — объединить инструменты, сервисы, конфигурации и другую информацию в одном месте. Инженеры-программисты, а также другие заинтересованные стороны (например, команды эксплуатации) должны иметь возможность использовать IDP как единую точку входа для обнаружения и взаимодействия с приложениями и инфраструктурой компании.

Таким образом, бэкенд IDP, как правило, должен быть сильным в двух типах функциональности: №1 Интеграция и №2 Автоматизация.

Интеграция: Объединение разнообразных инструментов и сервисов в единую систему.
Автоматизация: Связывание и оркестрация существующих конвейеров автоматизации.

4. Обоснование необходимости IDP для бизнеса

По мере того как организации масштабируют и модернизируют поставку своего программного обеспечения, сложность управления инфраструктурой, рабочими процессами разработчиков и управлением (governance) растет экспоненциально.

Внутренняя платформа для разработчиков (IDP) предлагает стратегический ответ на этот вызов, обеспечивая более быструю доставку, более сильное управление и снижение операционных рисков. Однако, чтобы получить одобрение руководства, крайне важно сформулировать преимущества IDP в терминах бизнеса.

Вот как можно обосновать необходимость IDP, обращаясь к четырем ключевым проблемам руководителей: Масштаб, Затраты, Риски и Управление.

1. Масштаб: Предоставление организации возможности двигаться быстрее

Проблема руководителя: Как мы можем масштабировать наши инженерные команды и поставку ПО без узких мест?
Обоснование IDP: IDP повышает производительность, абстрагируя повторяющиеся, низкоценные задачи. Она дает командам приложений возможность самостоятельно обслуживать инфраструктуру, CI/CD, тестирование и развертывание стандартизированным и безопасным способом.
Бизнес-результаты:
- Повышение скорости работы команд приложений и организации в целом.
- Быстрая доставка большей бизнес-ценности, поскольку команда разработки может сосредоточиться на коде.
- Возможность масштабирования без линейного увеличения найма DevOps-инженеров.
Как это сделать: Оцените, сколько времени команды приложений тратят на борьбу с инфраструктурой и инструментами развертывания, и сколько — на работу над своим основным приложением. Используйте эти данные, чтобы обосновать необходимость IDP и показать, как она может высвободить время для основной задачи, что напрямую влияет на бизнес-ценность. Визуализируйте это, чтобы подчеркнуть, каким объемом инфраструктуры приходится управлять командам приложений, и сравните это с тем, как это могло бы выглядеть.

*(В оригинальном документе здесь показаны два слайда из презентации PlatformCon23, представляющие “текущее состояние” и “будущее состояние”. Текущее состояние показывает, как команда из 50 разработчиков приложений вынуждена вручную взаимодействовать с разрозненным набором инструментов. Будущее состояние показывает, как команда платформы предоставляет единый, унифицированный слой, который абстрагирует эту сложность, позволяя командам приложений работать более эффективно.)*

Обратите внимание сколько кубиков вверху, а сколько внизу. В России кстати очень быстро вырывается вперед разработка на фреймворках streamlit, они почти ничего не делают повторно, если развернули хоть раз его с авторизацией и ипишками – в основном только ui колбасят. Но часто такие инициативы не вырастают сильно, их обычно давят в зародыше, так как они не соответствуют общему формату и не хотят делать все остальные кубики или не умеют – в общем похожи они на shadow it. Но если же им каким, то образом это удалось, то потом их не остановить и придя к ним через год, можно увидел второй прод, полностью зеркальный :) и сделал его кто-то один вечерами.

2. Затраты: Оптимизация за счет масштабирования и повторного использования

Проблема руководителя: Как нам контролировать растущие расходы на облако и инженерию?
Обоснование IDP: Платформенная инженерия сокращает дублирование усилий и консолидирует управление инфраструктурой. IDP способствует экономически эффективному масштабированию, обеспечивая прозрачность и контроль на протяжении всего жизненного цикла ПО. Централизация позволяет совместно использовать ресурсы, проактивно отслеживать затраты и автоматически высвобождать неиспользуемые активы (например, тестовые среды).
Бизнес-результаты:
- Улучшенная прозрачность и предсказуемость затрат.
- Снижение общей стоимости владения (TCO) за счет оптимизации ресурсов.
- Большая рентабельность инвестиций (ROI) в облачную инфраструктуру.
Важный момент: Команды платформы могут отслеживать метрики использования и отключать неиспользуемые среды.

3. Риски: Сокращение точек отказа и операционных угроз

Проблема руководителя: Какие риски угрожают нашей способности поставлять продукт надежно и безопасно?
Обоснование IDP: IDP минимизирует операционные риски и риски безопасности путем стандартизации процессов по всем направлениям — конвейеры CI/CD, развертывание, наблюдаемость (observability), оповещения и аутентификация.
Бизнес-результаты:
- Снижение риска сбоев в продакшене.
- Централизация ключевых сервисов, таких как развертывание, управление идентификацией и логирование.
- Принудительное применение политик безопасности и соответствия на уровне платформы.
Примеры устраняемых рисков:
- Задержки в поставке из-за нестабильных конвейеров.
- Утечки данных из-за неверно настроенных систем аутентификации.
- Непрохождение аудита из-за несогласованного логирования или дрифта соответствия требованиям.

4. Управление (Governance): Обеспечение согласованности и соответствия требованиям в масштабе

Проблема руководителя: Как нам поддерживать контроль, не замедляя команды?
Обоснование IDP: С IDP управление становится встроенным. От шаблонов до API, команды платформы могут кодировать стандарты и лучшие практики непосредственно в опыт разработчика.
Бизнес-результаты:
- Проактивное управление и применение политик.
- Улучшенная аудитопригодность и соответствие нормативным требованиям.
- Формирование культуры инженерного совершенства.

Подкрепление доводов данными

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

Итоговые мысли: Что не дает спать руководителям?

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

Скорость выхода на рынок (Speed to market): Сможем ли мы поставлять продукт быстрее конкурентов?
Надежность: Выдержат ли наши системы нагрузку?
Безопасность и соответствие требованиям (Security & Compliance): Уязвимы ли мы для взломов или аудитов?
Масштабируемость: Сможем ли мы расти, не теряя контроля?

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

5. Лучшие практики для создания IDP

Этот раздел основан на идеях, вдохновленных видео Виктора Фарчича «От нуля до полностью работающей платформы для разработчиков за 5 шагов!». Он описывает не столько шаги, сколько ключевые возможности, которые должна иметь IDP, чтобы быть полезной.

5 ключевых возможностей IDP (по версии Виктора Фарчича):

API
Управление состоянием (State management)
Одноразовые действия / Рабочие процессы (One-shot actions / Workflows)
RBAC и Политики (RBAC & Policies)
Пользовательские интерфейсы (опционально)

Наш взгляд на ключевые возможности (немного измененный и дополненный):

API: Программный интерфейс для взаимодействия с платформой.
Пользовательские интерфейсы (не опционально): Удобный способ для разработчиков взаимодействовать с платформой.
Автоматизация: Включает как одноразовые действия (например, запуск сборки), так и управление состоянием (например, поддержание среды в нужном состоянии).
Ограничения (Constraints): Политики, управление доступом на основе ролей (RBAC) и т.д.
Документация и обнаруживаемость (Discoverability): Возможность легко находить сервисы, их владельцев и документацию.

Как это поможет мне построить платформу?

Если вы подумаете о проблемах, с которыми вы недавно сталкивались как инженер платформы или DevOps-инженер, вы, вероятно, сможете соотнести их с одной из описанных возможностей.

Некоторые примеры:

Если у вас проблемы с простоями инстансов или случайными высокими затратами из-за оставленных облачных ресурсов, у вас недостаточные возможности по управлению состоянием.
Если у вас проблемы с тем, что у инженеров-программистов нет доступа к нужной им инфраструктуре, или с тем, что младшие инженеры вмешиваются в развертывания, в которые им не следует вмешиваться, вы плохо управляете ограничениями.
Если ваши разработчики не могут самостоятельно запустить систему на основе feature-ветки или запустить сборку и тест для определенного коммита, вам нужно взглянуть на ваши возможности автоматизации одноразовых действий.
Если ваши инженеры-программисты просто не используют предоставляемые вами API и сервисы, вам, вероятно, следует взглянуть на предоставляемые вами пользовательские интерфейсы или проверить, обнаруживаемы / документированы ли ваши сервисы.

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

6. Инструменты платформенной инженерии для создания IDP

В этой статье рассматривается, как структурировать IDP, с разбивкой по ключевым компонентам и с примерами инструментов, которые вы можете использовать.

Категоризация инструментов и компонентов

Мы классифицируем эти инструменты, используя «референсную архитектуру», популяризированную `platformengineering.org`. Эта структура разбивает экосистему на пять основных компонентов, известных как «плоскости» (`planes`):

Плоскость управления разработчика (`Developer Control Plane`): Все компоненты, через которые разработчики взаимодействуют с платформой. Обычно включает GUI/порталы, контроль версий, облачные среды разработки (CDE), а также стандарты конфигурации, которые разработчики поддерживают сами.
Плоскость интеграции и доставки (`Integration & Delivery Plane`): Здесь происходит вся автоматизация. Инструменты CI/CD, автоматизация инфраструктуры и другие оркестраторы платформы обычно являются частью этой плоскости.
Плоскость мониторинга и логирования (`Monitoring & Logging Plane`): Как следует из названия, здесь находятся все инструменты наблюдаемости (observability).
Плоскость безопасности (`Security Plane`): Управление секретами, инструменты политик и другие инструменты безопасности.
Плоскость ресурсов (`Resource Plane`): Вычислительные ресурсы и хранилища.

Пример: Создание внутренней платформы для разработчиков

Вот разбивка инструментов, которые вы могли бы использовать для создания IDP. Важное замечание: существует множество доступных инструментов. Упомянутые здесь — лишь примеры.

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

№1 Портал разработчика (`Developer Portal`)

Почему это важно: Внутренние порталы разработчиков служат единым интерфейсом и позволяют разработчикам, командам и инженерам-менеджерам обнаруживать сервисы, отслеживать владение, применять стандарты и улучшать программное обеспечение.
Инструменты для рассмотрения:
- Backstage: Популярный open-source фреймворк для создания порталов разработчиков, созданный Spotify.
- Port: Платформа для создания внутреннего портала разработчика с no-code подходом, что облегчает быстрый старт.
- Cortex: Корпоративный внутренний портал разработчика, созданный для ускорения пути к инженерному совершенству. [cloudomation.com](https://cloudomation.com/cloudomation-blog/5-internal-developer-portals-and-what-software-engineers-say-about-them/)
- Atlassian Compass: Компонентный каталог для отслеживания компонентов и команд, которые за ними стоят.

№2 Облачные среды разработки (`Cloud Development Environments, CDEs`)

Почему это важно: CDE — это удаленные среды разработки, размещенные в облаке или локально. CDE позволяют разработчикам работать в согласованных, стандартизированных средах, что устраняет проблемы «у меня на машине все работает».
Инструменты для рассмотрения:
- Gitpod: Позволяет запускать безопасные, контекстно-насыщенные среды для разработчиков в корпоративном масштабе.
- Coder: Предоставляет безопасные среды разработки для разработчиков и их агентов.

Плоскость интеграции и доставки

№1 Конвейер CI (`CI Pipeline`)

Почему это важно: Автоматизирует проверку кода, тестирование и обеспечивает более быстрые циклы обратной связи.
Инструменты для рассмотрения:
- GitHub Actions: Нативный CI для GitHub с настраиваемыми рабочими процессами.
- CircleCI: Высокомасштабируемый CI с поддержкой расширенного параллелизма.
- Buildkite: CI, ориентированный на разработчиков, с масштабируемой инфраструктурой.

№2 Конвейер CD (`CD Pipeline`)

Почему это важно: Конвейеры CD автоматизируют безопасное, повторяемое развертывание программного обеспечения.
Инструменты для рассмотрения:
- Argo CD: GitOps-ориентированная доставка для Kubernetes.
- Flux: Контроллер GitOps для Kubernetes.
- Octopus Deploy: Подходит для мультиоблачных и локальных (on-prem) сред.

№3 Оркестратор платформы (`Platform Orchestrator`)

Почему это важно: Инструменты оркестрации предоставляют логику для связывания рабочих процессов между различными инструментами и сервисами.
Инструменты для рассмотрения:
- Humanitec: Оркестратор платформы, предоставляющий динамические среды. Является лидером рынка IDP. [internaldeveloperplatform.org](https://internaldeveloperplatform.org/)
- Собственные решения/фреймворки: Многие команды используют общие инструменты, такие как Argo Workflows или пишут собственные скрипты на Python/Go для объединения своих процессов.

Плоскость мониторинга и логирования

№1 Наблюдаемость (`Observability`)

Почему это важно: Инструменты наблюдаемости обеспечивают видимость состояния, производительности и надежности приложений и инфраструктуры.
Инструменты для рассмотрения:
- Prometheus: Набор инструментов для мониторинга и оповещения, особенно для Kubernetes.
- Grafana: Инструмент для создания дашбордов, часто используемый в паре с Prometheus.
- Datadog: Облачный мониторинг и аналитика.

Плоскость безопасности

№1 Менеджер секретов (`Secret Manager`)

Почему это важно: Менеджеры секретов безопасно хранят и распространяют учетные данные, ключи API и другие конфиденциальные данные.
Инструменты для рассмотрения:**
- HashiCorp Vault: Ведущее в отрасли решение для управления секретами.
- AWS Secrets Manager / Azure Key Vault / GCP Secret Manager: Решения от крупных облачных провайдеров.
- Sealed Secrets (Bitnami): Шифрует секреты для Kubernetes.

Вывод: Строительные блоки, а не список покупок

Если из этой главы и стоит что-то вынести, так это то, что платформенная инженерия — это не выбор самых модных инструментов с полки, а подбор правильных строительных блоков для создания бесшовного опыта для разработчиков. Думайте меньше о том, «какой инструмент мне выбрать?», и больше о том, «как я могу спроектировать платформу, которая будет незаметной и мощной для моих разработчиков и принесет пользу бизнесу?»

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

7. 3 проблемы при создании IDP

Этот раздел основан на идеях Гая Менахема (Guy Menahem), архитектора решений в Amazon.

Проблема 1: Попытаться поймать всех зайцев одним выстрелом

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

Проблема 2: Оценка затрат на создание и эксплуатацию

Создание ценной платформы требует ресурсов, включая выделенную команду платформенной инженерии, бюджет на облачную инфраструктуру и сотрудничество. Также необходимо учитывать операционные расходы, такие как обновления и патчи безопасности. Оценивайте ресурсы, определяя размер и продолжительность работы команды, сосредотачиваясь на минимально жизнеспособном продукте (MVP) и рассчитывая облачные и операционные затраты.

Проблема 3: Создание и управление каталогом программного обеспечения

Управление каталогом программного обеспечения, который представляет собой сложную базу данных ПО, систем и документации, может быть непростой задачей. Вовлечение всех команд в обновление и поддержание каталога имеет решающее значение для его качества и принятия. Упростите управление каталогом, автоматизировав сбор информации, принудительно обновляя его в процессах CI/CD и поощряя ежедневное использование платформы.

Наш взгляд

Проблемы, которые описывает Гай, реальны. Однако одна фундаментальная истина, которую он не упоминает, заключается в том, что большинство проблем при создании IDP не являются техническими.

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

То же самое часто происходит и в командах платформенной инженерии: они могут создавать ценную автоматизацию и сервисы, но если их нелегко использовать, в них отсутствуют ключевые функции, необходимые инженерам-программистам, или они просто не решают самые большие проблемы, с которыми сталкиваются разработчики, то они просто не будут использовать IDP.

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

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

8. Ресурсы и ссылки

Сообщества

Reddit – https://www.reddit.com/r/platform_engineering
Platformers – https://platformers.community

Рассылки

https://platformweekly.com

Ранее еще писал немного на другую тему, но про разработку и стандарты апишек,интересно, мало у кого они есть, выглядят вот так: https://gavrilov.info/all/analiz-zalando-restful-api-and-event-guidelines/