Yuriy Gavrilov: posts tagged Programming

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`) спроектированы для лучшей производительности в кластерной среде, мы использовали одинаковые условия для всех решений, чтобы гарантировать справедливое сравнение.

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

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

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

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

Создание масштабируемого сервиса для скриншотов сайтов на Node.js, Puppeteer и Kubernetes

Mon, 01 Dec 2025 00:28:00 +0300

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

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

Node.js & Express: для создания легковесного API.
Puppeteer: для управления headless-браузером Chromium и создания скриншотов.
Docker: для упаковки нашего приложения в изолированный контейнер.
Kubernetes (k3s): для оркестрации, масштабирования и обеспечения отказоустойчивости нашего сервиса.

В итоге мы получим простое API, которое по GET-запросу с URL-адресом будет возвращать готовую картинку.

Зачем нужен собственный сервис?

Хотя существуют готовые SaaS-решения вроде https://urlbox.com, создание собственного сервиса дает несколько ключевых преимуществ:

Контроль: Вы полностью контролируете окружение, версии браузера и параметры рендеринга.
Безопасность: Вы можете запускать сервис в своей приватной сети для обработки внутренних ресурсов, недоступных извне.
Стоимость: При большом объеме запросов собственный сервис может оказаться значительно дешевле SaaS.
Гибкость: Вы можете легко расширить функциональность, добавив, например, генерацию PDF, выполнение кастомных скриптов на странице и многое другое.

Шаг 1: Создание Node.js приложения

Сначала создадим основу нашего сервиса — Express-приложение, которое будет принимать запросы и управлять Puppeteer.

Структура проекта

Создадим папку для нашего проекта и внутри нее — необходимые файлы.

puppeteer-k8s/
├── dockerb/
│   ├── Dockerfile
│   ├── .dockerignore
│   ├── server.js
│   ├── package.json
│   └── package-lock.json
└── deployment.yaml

*Обратите внимание: мы поместили все, что относится к Docker, в подпапку `dockerb` для удобства.*

Код сервера (`server.js`)

Это ядро нашего приложения. Оно принимает HTTP-запросы, запускает Puppeteer, переходит на указанный URL и делает скриншот. Мы также добавим полезные параметры для управления качеством и размером.

// server.js. -- в моем докере server_v3.js

const express = require('express');
const puppeteer = require('puppeteer');

const app = express();
const PORT = 3000;

app.get('/render', async (req, res) => {
    // Добавляем новые параметры: quality и dsf (deviceScaleFactor)
    const { 
        url, 
        width, 
        height, 
        format = 'png', 
        fullPage = 'false',
        quality, // Качество для jpeg/webp (0-100)
        dsf = '1' // Device Scale Factor. Для Retina-качества используйте '2'
    } = req.query;

    if (!url) {
        return res.status(400).json({
            error: 'Параметр "url" обязателен.',
            example: '/render?url=https://example.com'
        });
    }

    let browser;
    try {
        console.log(`[${new Date().toISOString()}] Начинаем рендеринг для: ${url}`);
        
        // Добавляем аргументы для улучшения рендеринга
        browser = await puppeteer.launch({
            args: [
                '--no-sandbox',
                '--disable-setuid-sandbox',
                '--font-render-hinting=none', // Может улучшить отрисовку шрифтов
                '--disable-infobars'       // Убирает инфо-панели
            ]
        });
        
        const page = await browser.newPage();

        const viewportWidth = parseInt(width, 10) || 1280;
        const viewportHeight = parseInt(height, 10) || 720;
        const deviceScaleFactor = parseInt(dsf, 10) || 1;

        // Устанавливаем viewport с учетом deviceScaleFactor
        await page.setViewport({
            width: viewportWidth,
            height: viewportHeight,
            deviceScaleFactor: deviceScaleFactor
        });

        console.log(`Viewport: ${viewportWidth}x${viewportHeight}, DeviceScaleFactor: ${deviceScaleFactor}`);

        await page.goto(url, { waitUntil: 'networkidle2' });

        // Если есть "ленивая" загрузка изображений, можно "проскроллить" страницу
        // Это необязательный шаг, но он помогает прогрузить все картинки
        if (fullPage === 'true') {
             await page.evaluate(async () => {
                await new Promise((resolve) => {
                    let totalHeight = 0;
                    const distance = 100;
                    const timer = setInterval(() => {
                        const scrollHeight = document.body.scrollHeight;
                        window.scrollBy(0, distance);
                        totalHeight += distance;

                        if (totalHeight >= scrollHeight) {
                            clearInterval(timer);
                            resolve();
                        }
                    }, 100);
                });
            });
        }
        
        const screenshotOptions = {
            type: (format === 'jpeg' || format === 'webp') ? format : 'png',
            fullPage: fullPage === 'true'
        };

        // Устанавливаем качество, если параметр был передан
        if ((screenshotOptions.type === 'jpeg' || screenshotOptions.type === 'webp') && quality) {
            screenshotOptions.quality = parseInt(quality, 10);
        } else if (screenshotOptions.type === 'jpeg') {
            screenshotOptions.quality = 90; // Ставим хорошее качество по умолчанию для JPEG
        }

        const imageBuffer = await page.screenshot(screenshotOptions);
        
        console.log(`[${new Date().toISOString()}] Рендеринг успешно завершен.`);

        res.setHeader('Content-Type', `image/${screenshotOptions.type}`);
        res.send(imageBuffer);

    } catch (error) {
        console.error(`[${new Date().toISOString()}] Ошибка рендеринга для ${url}:`, error.message);
        res.status(500).json({ 
            error: 'Не удалось отрендерить страницу.',
            details: error.message 
        });
    } finally {
        if (browser) {
            await browser.close();
        }
    }
});


app.get('/', (req, res) => {
    res.setHeader('Content-Type', 'text/plain; charset=utf-8');
    res.send(`
    API для рендеринга сайтов (v2 - Улучшенное качество)
    ----------------------------------------------------
    Используйте GET-запрос на /render с параметрами.

    Обязательные параметры:
      - url: Адрес сайта для скриншота.

    Необязательные параметры:
      - width: Ширина окна (по умолч. 1280).
      - height: Высота окна (по умолч. 720).
      - format: Формат файла ('png', 'jpeg', 'webp'). По умолч. 'png'.
      - fullPage: Сделать скриншот всей страницы ('true' или 'false'). По умолч. 'false'.
      - dsf: Device Scale Factor для Retina/HiDPI качества (например, '2'). По умолч. '1'.
      - quality: Качество для jpeg/webp от 0 до 100.

    Пример для высокого качества (Retina):
    curl -o site_retina.png "http://localhost:3000/render?url=https://github.com&dsf=2&width=1440&height=900"
    
    Пример для JPEG с максимальным качеством:
    curl -o site_hq.jpeg "http://localhost:3000/render?url=https://apple.com&format=jpeg&quality=100&width=1920&height=1080"
    `);
});

app.listen(PORT, () => {
    console.log(`Сервис рендеринга запущен на http://localhost:${PORT}`);
});

*Запустите `npm install` в папке `dockerb`, чтобы сгенерировать `package-lock.json`.*

Шаг 2: Создание Docker-образа

Теперь упакуем наше приложение. Этот шаг — самый каверзный, так как Puppeteer требует особого подхода к правам доступа и зависимостям.

мой пример тут образа

Файл `.dockerignore`

Крайне важно не копировать локальную папку `node_modules` в образ. Они должны устанавливаться внутри контейнера для правильной архитектуры.

# .dockerignore
node_modules

Финальный `Dockerfile`

Этот `Dockerfile` — результат множества проб и ошибок. Он решает все основные проблемы:

Устанавливает необходимые системные библиотеки для Chromium.
Создает непривилегированного пользователя `pptruser` с домашней директорией.
Устанавливает `npm`-зависимости и браузер от имени этого пользователя, чтобы избежать проблем с правами доступа.

# 1. Базовый образ
FROM node:18-slim

# 2. Установка системных зависимостей
RUN apt-get update && apt-get install -y \
    ca-certificates fonts-liberation libappindicator3-1 libasound2 libatk-bridge2.0-0 \
    libatk1.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgbm1 \
    libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libglib2.0-0 libgtk-3-0 libnspr4 libnss3 \
    libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 \
    libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 \
    libxrender1 libxss1 libxtst6 lsb-release wget xdg-utils \
    && rm -rf /var/lib/apt/lists/*

# 3. создаем пользователя с домом
# Флаг -m (--create-home) гарантирует создание папки /home/pptruser
RUN useradd -r -m -g root -s /bin/bash pptruser

# 4. Устанавливаем рабочую директорию
WORKDIR /app

# 5. Копируем файлы зависимостей и сразу назначаем владельцем pptruser
# (современный и более чистый способ, чем chown после)
COPY --chown=pptruser:root package*.json ./

# 6. Переключаемся на нашего пользователя
USER pptruser

# 7. Устанавливаем всё от имени pptruser. Кэш ляжет в /home/pptruser/.cache
RUN npm ci
RUN npx puppeteer browsers install chrome

# 8. Копируем остальной код, также сразу назначая владельца
COPY --chown=pptruser:root . .

# 9. Открываем порт и запускаем
EXPOSE 3000
CMD [ "node", "server.js" ]

Сборка и отправка образа

Замените `your_docker_id` на ваш логин в Docker Hub.

# Переходим в папку с Dockerfile
cd puppeteer-k8s/dockerb

# Собираем образ
docker build -t your_docker_id/puppeteer-renderer:v1 .

# Отправляем в репозиторий
docker push your_docker_id/puppeteer-renderer:v1

Шаг 3: Развертывание в Kubernetes

Мы будем использовать `k3s` — легковесный дистрибутив Kubernetes. Можно еще тут посмотреть пример https://github.com/jamesheronwalker/urlbox-puppeteer-kubernetes-demo

или вот статейка еще https://urlbox.com/guides/kubernetes-website-screenshots

Установка окружения (Local)

# Установка lima и k3s (если еще не сделано)
brew install lima
limactl start template://k3s

# Настройка kubectl для работы с кластером
export KUBECONFIG=$(limactl list k3s --format 'unix://{{.Dir}}/copied-from-guest/kubeconfig.yaml')

# Проверка, что все работает
kubectl get nodes

Манифест развертывания (`deployment.yaml`)

Этот YAML-файл описывает желаемое состояние нашего приложения в кластере. Мы будем использовать тип сервиса `LoadBalancer` — он идеально подходит для будущего развертывания в облаке, а для локальной разработки мы будем использовать `port-forward`.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: puppeteer-renderer
spec:
  replicas: 2 # Запускаем два пода для отказоустойчивости
  selector:
    matchLabels:
      app: puppeteer-renderer
  template:
    metadata:
      labels:
        app: puppeteer-renderer
    spec:
      containers:
      - name: renderer
        image: your_docker_id/puppeteer-renderer:v1 # <<< ВАШ ОБРАЗ (мой тут docker pull 1325gy/my_dev:v4)
        ports:
        - containerPort: 3000
        resources:
          requests:
            cpu: "500m"
            memory: "1Gi"
          limits:
            cpu: "1"
            memory: "2Gi"
        readinessProbe:
          httpGet:
            path: /
            port: 3000
          initialDelaySeconds: 15
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /
            port: 3000
          initialDelaySeconds: 30
          periodSeconds: 20
        volumeMounts:
        - name: dshm
          mountPath: /dev/shm
      volumes:
      - name: dshm
        emptyDir:
          medium: Memory
---
apiVersion: v1
kind: Service
metadata:
  name: pptr-renderer-service
spec:
  # Тип LoadBalancer - стандарт для облаков. Локально он останется в <pending>,
  # но это не помешает нам использовать port-forward.
  type: LoadBalancer 
  selector:
    app: puppeteer-renderer
  ports:
  - protocol: TCP
    port: 80 # Внешний порт сервиса
    targetPort: 3000 # Порт, на который нужно перенаправлять трафик внутри пода

Важные моменты в манифесте:

`resources:`: Puppeteer очень требователен к ресурсам. Указание запросов и лимитов помогает Kubernetes правильно размещать поды.
`readiness/livenessProbe`: Пробы готовности и жизнеспособности позволяют Kubernetes понять, работает ли под корректно.
`/dev/shm`: Chromium использует разделяемую память. Увеличение её размера через `emptyDir` предотвращает частые сбои.

Запуск и проверка

# Переходим в корневую папку проекта
cd ..

# Применяем манифест
kubectl apply -f deployment.yaml

# Наблюдаем за созданием подов
kubectl get pods -l app=puppeteer-renderer -w

# Проверяем сервис. EXTERNAL-IP будет <pending>, это нормально.
kubectl get service pptr-renderer-service
# NAME                  TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
# pptr-renderer-service LoadBalancer   10.43.123.123   <pending>     80:31185/TCP   1m

Шаг 4: Тестирование через Port-Forward

`kubectl port-forward` — это мощный инструмент для отладки, который создает безопасный тоннель с вашего компьютера напрямую к сервису в кластере.

Откройте новый терминал и выполните команду:

kubectl port-forward service/pptr-renderer-service 8080:80

`8080` — это порт на вашем локальном компьютере (`localhost`).
`80` — это порт, который слушает наш `Service` в Kubernetes.

Вы увидите сообщение `Forwarding from 127.0.0.1:8080 -> 3000`. Не закрывайте этот терминал.

Откройте третий терминал и отправьте тестовый запрос на `localhost:8080`:

curl -o k8s-site.png "http://localhost:8080/render?url=https://kubernetes.io&width=1440&height=900&dsf=2"

Если все сделано правильно, в вашей текущей папке появится файл `k8s-site.png` со скриншотом сайта Kubernetes в высоком разрешении!

Итоги и рекомендации для продакшена

Мы успешно создали и развернули масштабируемый сервис для создания скриншотов. Мы убедились, что он работает локально в `k3s`, используя `LoadBalancer` и `port-forward` для удобной отладки.

Когда придет время переходить в продуктивное окружение (например, в облако Google/AWS):

Тип Сервиса: Вам не нужно ничего менять! Просто примените тот же `deployment.yaml` с `type: LoadBalancer`. Облачный провайдер автоматически подхватит этот сервис и выделит ему настоящий публичный IP-адрес.
Ingress: Для более гибкого управления трафиком (маршрутизация по хостам, SSL/TLS) используйте `Ingress Controller`. Он будет направлять внешний трафик на ваш сервис, который уже можно будет сделать типа `ClusterIP`.
Автомасштабирование: Настройте `HorizontalPodAutoscaler` (HPA), чтобы Kubernetes автоматически добавлял или удалял поды в зависимости от нагрузки (например, по CPU).
Логирование и Мониторинг: Настройте централизованный сбор логов (EFK/Loki) и мониторинг метрик (Prometheus/Grafana), чтобы следить за здоровьем и производительностью сервиса.

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

Мне вот удалось rbc заскринить вот так, потом может что то сделаю для статеек с медиума.

curl -o rbc111.png "http://localhost:8080/render?url=https://rbc.ru&width=1440&height=900&dsf=2"

Вот что вышло png тут

Новые архитектуры современной инфраструктуры данных: a16z

Tue, 04 Nov 2025 17:02:04 +0300

Источник: Emerging Architectures for Modern Data Infrastructure
Авторы: Matt Bornstein, Jennifer Li, and Martin Casado
PDF: Тут

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

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

Обновленные эталонные архитектуры

Статья предлагает два общих взгляда на современный стек данных.

1. Единая инфраструктура данных (Unified Data Infrastructure 2.0)

Эта схема дает комплексное представление о стеке данных, охватывая все основные варианты использования — от аналитики до операционных систем.

Notes: Excludes OLTP, log analysis, and SaaS analytics apps.

Схема демонстрирует путь данных от источников (`Sources`) через этапы загрузки и транспортировки (`Ingestion and Transport`), хранения (`Storage`), обработки запросов (`Query and Processing`), трансформации (`Transformation`) до конечного анализа и вывода (`Analysis and Output`).

2. Инфраструктура для машинного обучения (Machine Learning Infrastructure 2.0)

Вторая схема подробно рассматривает сложную и все более независимую цепочку инструментов для машинного обучения.

Здесь показан жизненный цикл ML-модели: от трансформации данных и разработки модели (`Data Transformation`, `Model Training and Development`) до ее развертывания (`Model Inference`) и интеграции в конечные продукты (`Integration`).

Что изменилось? Стабильное ядро и “Кембрийский взрыв”

Что не изменилось: стабильность в ядре

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

Аналитическими системами (Analytic Systems), которые помогают принимать решения на основе данных (`data-driven decisions`).
Операционными системами (Operational Systems), которые являются основой для продуктов, использующих данные (`data-powered products`).

Ключевые технологии в ядре стека доказали свою устойчивость и продолжают доминировать:

В аналитике связка `Fivetran` (для репликации данных), `Snowflake`/`BigQuery` (облачные хранилища данных) и `dbt` (для SQL-трансформаций) стала почти стандартом де-факто.
В операционных системах укрепились такие стандарты, как `Databricks`/`Spark`, `Confluent`/`Kafka` и `Airflow`.

Что нового: “Кембрийский взрыв”

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

Новые инструменты для поддержки ключевых процессов обработки данных:
- Data Discovery: Каталоги данных для поиска и понимания имеющихся активов (`Amundsen`, `DataHub`, `Atlan`).
- Data Observability: Инструменты для мониторинга состояния и качества конвейеров данных (`Monte Carlo`, `Bigeye`).
- ML Model Auditing: Решения для аудита и валидации ML-моделей.

Новые приложения для извлечения ценности из данных:
- Data Workspaces: Интерактивные среды для совместной работы аналитиков и Data Scientist’ов (`Mode`, `Hex`, `Deepnote`).
- Reverse ETL: Сервисы, которые возвращают обогащенные данные из хранилища обратно в операционные системы (CRM, ERP), такие как `Census` и `Hightouch`.
- ML Application Frameworks: Фреймворки для создания приложений на основе ML-моделей (`Streamlit`).

Три основных архитектурных шаблона (Blueprints)

Шаблон 1: Современная Business Intelligence (BI)

Этот шаблон предназначен для компаний любого размера, которые строят облачную BI-аналитику.

Darker boxes are new or meaningfully changed since v1 of the architecture in 2020; lighter colored boxes have remained largely the same. Gray boxes are considered less relevant to this blueprint.

Что не изменилось: Основой по-прежнему является комбинация репликации данных (`Fivetran`), облачного хранилища (`Snowflake`) и SQL-моделирования (`dbt`). Дашборды (`Looker`, `Tableau`, `Superset`) остаются главным инструментом анализа.
Что нового:
- Metrics Layer: Появился активный интерес к слою метрик — системе, которая предоставляет стандартизированные бизнес-определения поверх хранилища данных (`Transform`, `LookML`). `dbt` также движется в этом направлении. ( dbt кстати открыла в общий доступ свои метрики тут
- Reverse ETL: Этот инструмент позволяет операционализировать аналитику, отправляя результаты (например, скоринг лидов) из хранилища напрямую в `Salesforce` или `Hubspot`. ( теперь мы знаем как эта штука называется по-модному, когда кто-то просит excele’чку всунуть к табличке рядышком :) )
- Data Workspaces: Новые приложения для более гибкого и глубокого анализа, чем стандартные дашборды.

Шаблон 2: Мультимодальная обработка данных

Этот шаблон развивает концепцию “озера данных” (`Data Lake`) для поддержки как аналитических, так и операционных задач. Часто используется компаниями, которые “мигрировали” с `Hadoop`.

Что не изменилось: Ядром остаются системы обработки (`Databricks`, `Starburst`), транспортировки (`Confluent`, `Airflow`) и хранения (`AWS S3`).
Что нового:
- Архитектура Lakehouse: Получила широкое признание концепция `Lakehouse` — гибрид, объединяющий гибкость озера данных и производительность/управляемость хранилища данных. Она позволяет использовать поверх одного и того же хранилища (`S3`) множество движков: `Spark`, `Presto`, `Druid`/`ClickHouse` и др.
- Форматы хранения: Быстрое распространение получают открытые табличные форматы, такие как `Delta Lake`, `Apache Iceberg` и `Apache Hudi`, которые привносят транзакционность и надежность в озера данных.
- Stream Processing: Растет популярность потоковой обработки данных в реальном времени. Появляются новые, более простые в использовании инструменты (`Materialize`, `Upsolver`), а существующие (`Databricks Streaming`, `Confluent`/`ksqlDB`) наращивают функциональность.

Шаблон 3: Искусственный интеллект и машинное обучение (AI/ML)

Стек для разработки, тестирования и эксплуатации ML-моделей.

Note: Darker boxes are new or meaningfully changed since v1 of the architecture in 2020; lighter colored boxes have remained largely the same. Gray boxes are considered less relevant to this blueprint.

Что не изменилось: Инструменты для разработки моделей в целом остались прежними: облачные платформы (`AWS Sagemaker`, `Databricks`), ML-фреймворки (`PyTorch`, `XGBoost`) и системы для отслеживания экспериментов (`Weights & Biases`, `Comet`).
Что нового:
- Data-Centric AI: Произошел сдвиг парадигмы в сторону подхода, ориентированного на данные. Вместо бесконечного улучшения кода модели, фокус сместился на улучшение качества и управления данными для обучения. Это привело к росту сервисов разметки данных (`Scale AI`, `Labelbox`).
- Feature Stores: Увеличилось внедрение хранилищ признаков (`Tecton`, `Feast`) для совместной разработки и использования ML-признаков в production.
- Pre-trained Models: Использование предобученных моделей (особенно в NLP) стало стандартом. Компании, как `OpenAI` и `Hugging Face`, играют здесь ключевую роль.
- MLOps: Инструменты для эксплуатации моделей стали более зрелыми, особенно в области мониторинга (`Arize`, `Fiddler`) на предмет деградации качества и дрифта данных.

Гипотеза о “платформе данных”

Ключевая идея статьи — объяснить наблюдаемые изменения через формирование платформ данных.

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

Применительно к данным, “бэкенд” стека (загрузка, хранение, обработка) консолидируется вокруг небольшого числа облачных вендоров. Эти вендоры (`Snowflake`, `Databricks`) активно инвестируют в то, чтобы сделать данные легкодоступными для других через стандартные интерфейсы (например, SQL).

В свою очередь, “фронтенд” разработчики пользуются этим, создавая множество новых приложений поверх единой точки интеграции, не беспокоясь о сложностях базовой инфраструктуры. Это приводит к появлению нового класса `warehouse-native` (или `lakehouse-native`) приложений, которые работают непосредственно с данными клиента в его хранилище.

Эта модель объясняет, почему поставщики ядра данных (`Snowflake`, `Databricks`) так высоко ценятся (они борются за долгосрочную позицию платформы) и почему наблюдается взрывной рост в экосистеме инструментов (`Reverse ETL`, `Metrics Layer`) — они становятся важными компонентами, встроенными в эту новую платформенную архитектуру.

Итог и акценты в трендах

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

Взрывной рост экосистемы. Вокруг стабильного ядра формируется богатая экосистема вспомогательных инструментов (`observability`, `discovery`) и бизнес-приложений (`reverse ETL`, `workspaces`), которые повышают ценность данных.

Платформизация стека данных. Центральные хранилища данных (`Data Warehouse`, `Lakehouse`) превращаются из простых баз данных в полноценные платформы для разработки. Это открывает путь для нового поколения `warehouse-native` SaaS-приложений.

Операционализация данных. Тренд смещается от простой аналитики (посмотреть на дашборд) к активному использованию данных в операционных процессах бизнеса. Технологии `Reverse ETL` являются главным драйвером этого тренда.

Data-Centric AI. В мире машинного обучения фокус окончательно сместился с улучшения алгоритмов на улучшение данных, что стимулирует рынок инструментов для управления жизненным циклом данных в ML (`data labeling`, `feature stores`, `monitoring`).

Bar is sooooooooo high – Platform Takes The Pain

Fri, 24 Oct 2025 00:49:24 +0300

Часть 1: “Bar is sooooooooo high” – https://nekrolm.github.io/blog.html

Это исповедь инженера, уволившегося из Amazon Web Services (AWS) после трех лет работы. Основная причина — чудовищный стресс и выгорание, вызванные спецификой корпоративной культуры и рабочих процессов, несмотря на престижность компании (FAANG) и высокую компенсацию.

Учим английские выражения и их значение в контексте статьи, любопытно

`Bar is sooooooooo high`: “Планка неимоверно высока”. Означает, что требования для повышения (промоушена) настолько завышены, что достичь их практически невозможно, даже если ты уже выполняешь работу на следующем уровне. Это создает ощущение бега на месте.
`RSU (Restricted Stock Units)`: Акции компании, которые выдаются сотруднику, но он получает их не сразу, а по частям в течение нескольких лет. Это способ удержания ценных кадров. Автор отказался от ~£100k, не дождавшись очередного получения акций.
`FAANG`: Акроним для гигантов технологической индустрии: Facebook (теперь Meta), Amazon, Apple, Netflix, Google. Символ престижной и высокооплачиваемой работы в IT.
`Return-to-office`: “Возвращение в офис”. Политика компании, обязывающая сотрудников работать из офиса определенное количество дней в неделю.
`Oncall`: “Дежурство”. Период, когда инженер должен быть доступен 24/7 для решения экстренных проблем с продакшн-системами. В статье это источник огромного стресса из-за сложности системы и широкого круга обязанностей.
`Leadership Principles`: “Принципы лидерства”. 16 “заповедей” Amazon, которые должны направлять поведение сотрудников. Автор иронично использует их, чтобы показать, как в реальности они превращаются в инструменты бюрократии и давления.
`Receive shouldertaps`: “Получать ‘похлопывания по плечу’”. Метафора, означающая постоянные отвлечения, прерывания и запросы от коллег и менеджеров, которые мешают сосредоточиться на основной задаче.
`Let’s keep rollout aside`: “Давайте пока не будем думать о раскатке”. Фраза менеджера, которая говорит о том, что процесс релиза настолько сложный, долгий (от месяца до года) и рискованный, что его даже не пытаются планировать и оценивать.
`Customer Obsession`: “Одержимость клиентом”. Один из принципов лидерства. В статье показана его гипертрофированная форма, когда нужно реагировать даже на падение одного запроса из миллиона.
`Correction-of-errors document (COE)`: Документ с разбором ошибок. Его написание и защита перед высшим руководством — крайне неприятная процедура после любого сбоя.
`Bar Rising`: “Поднятие планки”. Процесс ревью и “прожарки” на митингах, где любая идея подвергается шквалу критики и сомнений, что ведет к выработке синдрома самозванца. пс: у кого-то “паяльники” рабочий инструмент, а у матерых компаний “градусники для мяса”. 🤣 Что поделать, идут дальше, контролируют степень “прожарки” в виде ежедневных опросов, что бы не подгорало.
`Ownership`, `Operational Excellence`: Другие принципы лидерства, которые на практике означают, что дежурный инженер несет полную ответственность за гигантскую и запутанную систему.
`In pain`: “Страдает”. Эмоционально окрашенный термин для описания клиента с проблемой, используемый для создания срочности.
`Disagree and Commute`: “Не согласен, но езди в офис”. Ироничная переделка принципа `Disagree and Commit` (“Не согласен, но поддерживай решение”). Отражает отношение к принудительному возвращению в офис.
`GenAI`: Генеративный Искусственный Интеллект. Автор описывает неадекватную истерию вокруг этой темы в компании.
`Bellow benchmarks`: “Ниже эталонных показателей”. Результат анонимных опросов удовлетворенности, который показывает, что команда недовольна, и приводит к игре в “мафию” — поиску виноватых.

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

Футбол кстати вовлекает 40% населения, а количество зрителей финала чемпионата может достигать 1,5 млрд. человек.

Стоимость бренда UFC – 4 млрд$, но цифра уже устарела, 11 дек. 2024 г. — $10 миллиардов, — Глава UFC оценил, а в августе этого года Paramount приобрела права на трансляцию UFC за $7,7 млрд. Сейчас оценка где-то 11млрд. За один просмотр выручка c трансляции одного боя может достигать 180$ млн.

А вот Люк как запомнился, “Он говорил на языке страсти, а не KPI”

Ну вы все уже знаете. 81 сервис пострадал, +800 компаний где-то, даже медиум лежал.

Облака, белогривые лошадки,
Облака, что вы мчитесь без оглядки
Не смотрите вы пожалуйста свысока,
А по небу прокатите нас облака... Трям! Здравствуйте!»))

Рецепт выгорания от Amazon или почему “планка так высока”

Крик души Дмитрия — это не просто рассказ об увольнении, а детальный разбор полетов корпоративной машины, где престиж и высокая зарплата становятся недостаточной компенсацией за системный стресс. Автор, проработав три года в AWS, уходит, отказавшись от солидной суммы. Что же пошло не так?

Причина кроется в самой культуре, парадоксальным образом описанной через знаменитые `Leadership Principles` Amazon. Принцип `Insist on Highest Standards` (“Настаивайте на высочайших стандартах”) на практике превращается в бюрократическую “прожарку” (`Bar Rising`), где любая инициатива тонет в бесконечных согласованиях и документах. Чтобы выпустить даже небольшое изменение, нужно “просмотреть все варианты будущего”, как Доктор Стрэндж, и защитить свое решение перед армией сомневающихся.

Вершиной этой культуры становится процесс релиза. Фраза менеджера `Let’s keep rollout aside` говорит сама за себя: раскатка изменений в продукте, через который проходит 30% интернет-трафика, — это настолько болезненный и непредсказуемый процесс, что его предпочитают даже не обсуждать. Проект, сделанный за 2 недели, может добираться до пользователей полтора года. Как пишет автор, это лучший рецепт для выгорания: “Заставьте программистов писать код, не дайте им увидеть результат и при этом дергайте их в разные стороны”.

Эти “подергивания” (`shouldertaps`) — еще один гвоздь в крышку гроба мотивации. Дежурства (`oncall`) превращают инженера в универсального солдата, который должен ориентироваться в сотнях дашбордов, десятках видов логов и нести `Ownership` за все, что происходит. При этом `Customer Obsession` доходит до абсурда: приходится разбираться с падением одного запроса из миллиона, потому что клиент `in pain`.

На фоне этого — постоянные увольнения, принудительное “возвращение в офис” (`Disagree and Commute`) и неадекватная `GenAI`-истерия. В итоге “планка” (`bar is so high`) для карьерного роста оказывается не стимулом, а стеной, о которую разбиваются амбиции. Это история о том, как система, созданная для минимизации рисков в огромном масштабе, начинает пожирать человеческий ресурс, превращая талантливых инженеров в выгоревших статистов.

Стихотворение в стиле АЙ да Пушкина :) 🤖

Три года в царстве AWS,
Где каждый день — суровый стресс.
Прощай, гигант, твой дом высок,
Но дух мой страждет и продрог.

Чтоб строчку кода в мир пустить,
Трактат надобно сочинить.
На том совете господа
Тебя осудят без труда.

“А точно ль цель сия верна?
Вся ль сложность вами учтена?”
Идёт полгода, год второй,
А код твой спит, еще не в строй.

Дежурства мрак, клиент “in pain”,
И кашель рвёт грудину мне.
И планка та, что так горда,
Лишь множит горе и года.

Оставлю акций бренный звон,
Покину сей хрустальный трон.
Свободным быть — вот мой удел,
Прощай, Amazon, я улетел.

Часть 2: О статье про Spotify (“Platform Takes The Pain”)

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

Суть и смысл статьи

Основная идея — Spotify столкнулся с проблемой масштабирования. Их культура полной автономии команд, где каждая сама отвечала за свой конвейер сборки и доставки (CI/CD), привела к хаосу: более 300 команд использовали 200+ разных, небезопасных версий CI-системы Jenkins. Перед выходом на IPO аудиторы указали на это как на серьезный риск.

Компании нужно было за 6 месяцев стандартизировать CI, но как это сделать, не нарушив главный принцип — автономию инженеров, которые не хотели, чтобы им что-то навязывали “сверху”?

Решением стала смена парадигмы в работе платформенных команд под лозунгом `Platform Takes The Pain` (“Платформа забирает боль на себя”).

Устройство, культура и особенности Spotify

Культура “старого” Spotify (до трансформации):
- Хорошо:
  - Полная автономия: Команды (`squads`) были абсолютно независимы, что давало им чувство сопричастности и ускоряло принятие решений в малом масштабе.
  - Сильная идентичность: У каждой команды была своя “комната” (`squad room`), оформленная в уникальном стиле, что создавало сильную командную связь.
  - Скорость и гениальные инженеры: В компании были “звёзды” (“employee number 10”), которые могли писать код день и ночь и знали всё об инфраструктуре.
- Не очень:
  - Хаос и фрагментация: Более 200 CI-систем — яркий пример. Это приводило к дублированию работы и уязвимостям.
  - “Rumor Driven Development” (“Разработка, основанная на слухах”): Чтобы что-то узнать, нужно было “похлопать по плечу” нужного человека. Не было единого источника информации, что замедляло новичков и приводило к созданию костылей.
  - Проблемы с онбордингом: Новичку требовалось более 60 дней, чтобы сделать свои первые 10 Pull Request.
  - Хрупкость: Если ключевой инженер уходил в отпуск, система могла остаться без поддержки.

Трансформация и новая культура:
- Мантра `Platform Takes the Pain`: Платформенные команды перестали быть просто создателями инструментов “в стол”. Они стали сервис-провайдером для внутренних клиентов — других команд разработчиков. Их новой задачей стало не просто создать инструмент, а взять на себя ответственность за его внедрение (`adoption`). Они приходили в команды и помогали им мигрировать, забирая на себя самую нудную и сложную работу.
- `Backstage` — решение проблемы “слухов”: Чтобы победить `Rumor Driven Development`, Spotify создали единый портал для разработчиков — `Backstage` engineering.atspotify.com.
  - Устройство: Это центральный каталог, где можно найти информацию о любом сервисе, его владельце, документации, API и дежурном инженере.
  - Главная особенность: `Backstage` построен на плагинах. Это значит, что центральная команда не стала “бутылочным горлышком”. Любая команда может написать свой плагин для `Backstage`, чтобы добавить нужную ей функциональность. Это гениальное решение, которое централизует информацию, но децентрализует владение и развитие платформы.
- Переосмысление автономии: В Spotify поняли, что автономия ради автономии бессмысленна. Настоящая цель автономии — влияние (`impact`). Если команда автономна, но изолирована и ее работа не приносит пользы, это плохая автономия. Новые стандарты и инструменты вроде `Backstage` не убили автономию, а, наоборот, дали командам больше влияния, убрав рутину и упростив взаимодействие.

*На Backstage кстати можно строить порталы IDP https://internaldeveloperplatform.org/what-is-an-internal-developer-platform/

Чем Spotify отличается от других (например, от Amazon из первой статьи)?

Аспект	Amazon (согласно статье)	Spotify (согласно статье)
Процесс	Процесс — это цель. Бюрократия и избегание рисков приводят к параличу. Релизы длятся годами.	Процесс — это средство. Цель — скорость итераций. Узкие места (bottlenecks) активно устраняются.
Автономия	Индивидуальная ответственность (`Ownership`), которая часто превращается в поиск виноватого.	Командная автономия, нацеленная на результат (`impact`). Баланс между свободой и общими стандартами.
Платформа	Не описано, но похоже на набор сложных инструментов, за которые ты сам несешь ответственность.	Платформа как сервис (`Platform takes the pain`). Платформенные команды — помощники, а не надзиратели.
Культура	Top-down (сверху-вниз). Жесткие принципы, которые могут использоваться для давления. Страх ошибки.	Bottom-up (снизу-вверх). Культура эволюционировала в ответ на реальные проблемы. Поощрение экспериментов и “быстрых провалов”.
Информация	Скрыта в тысячах репозиториев и устаревших вики. Огромный контекст, который невозможно удержать.	Централизована и доступна через `Backstage`. Прозрачность — один из ключевых принципов.

Итоги

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

Основные выводы:

Платформа должна служить разработчикам, а не диктовать им условия. Модель `Platform Takes The Pain` — это то, чему стоит поучиться многим компаниям.
Централизуйте информацию, а не контроль. Инструмент вроде `Backstage` с плагинной архитектурой — мощное решение для сохранения скорости и автономии в большом масштабе.
Культура не высечена в камне. Она должна адаптироваться к размеру и задачам компании. Spotify смогли переосмыслить “автономию”, привязав её к реальному влиянию на продукт.

Для компаний, стремящихся к росту, опыт Spotify

sciencedirect.com — это дорожная карта по построению эффективной и при этом человечной инженерной организации. А для инженеров, выбирающих место работы, это маркер здоровой культуры: ищите компании, которые борются с трением, а не создают его. Как говорится, если в компании есть свой `Backstage` — это хороший знак. Если же там “let’s keep rollout aside” — возможно, стоит бежать.

Если коротко – оригинал по ссылке выше

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

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

Однако эта свобода существует в рамках так называемых «благоприятствующих ограничений» (`enabling constraints`). Эти ограничения — не приказы сверху, а скорее общие правила и инструменты, которые помогают командам работать слаженно, не создавая хаоса. Исследование основано на ретроспективах с командами, интервью с менеджерами и анализе внутренних данных Spotify.

Основные рекомендации и стратегии, применяемые в Spotify

Для достижения баланса между автономией и согласованностью Spotify использует несколько ключевых стратегий:

Выравнивание (Alignment) вместо контроля: Вместо того чтобы указывать командам, *что* и *как* делать, компания создает условия для естественной синхронизации.
- `TechRadar` (Технологический радар): Это централизованный, но коллективно управляемый список одобренных технологий, языков программирования и фреймворков. Команды не могут использовать абсолютно любую технологию, что упрощает поддержку, обмен инженерами и совместную работу над кодом.
- Запросы на комментарии (`RFCs – Requests for Comments`): Для крупных изменений, затрагивающих несколько команд, используется формальный процесс RFC. Это позволяет собрать обратную связь и достичь консенсуса до начала реализации.
- «Золотые пути» (`Golden Paths`): Это готовые шаблоны и руководства для выполнения стандартных задач (например, создание нового микросервиса). Это снижает когнитивную нагрузку на инженеров и обеспечивает единообразие.

Управление общей кодовой базой:
- «Слабое владение кодом» (`Weak Code Ownership`): У каждого компонента кода есть команда-владелец, но любая другая команда может предлагать изменения через пул-реквесты (`Pull Requests`). Команда-владелец обязана рассмотреть эти изменения. Это предотвращает возникновение «узких мест» и поощряет коллективную ответственность за продукт.
- Самостоятельное управление зависимостями: Команды могут договариваться между собой и передавать владение кодовыми репозиториями, чтобы уменьшить зависимости и ускорить свою работу.

Сетевые структуры и обмен знаниями: Компания активно развивает горизонтальные связи, минуя формальную иерархию.
- Гильдии (`Guilds`): Это добровольные сообщества по интересам (например, гильдия веб-разработчиков или гильдия по качеству). Они служат для обмена знаниями, выработки лучших практик и решения общих проблем.
- Культура взаимопомощи и внутренние инструменты: Использование корпоративного Slack и внутреннего аналога Stack Overflow поощряет открытый обмен информацией. Репутация инженера или команды отчасти зависит от их готовности помогать другим.
- «Встраивание» (`Embedding`): Практика временного (до трех месяцев) «одалживания» инженеров между командами. Это помогает быстро передавать экспертизу, решать проблемы с зависимостями и укреплять социальные связи.

Что выходит?

Масштабируемая автономия возможна и эффективна. Модель Spotify доказывает, что можно предоставить командам значительную свободу даже в очень крупной организации. Ключ к успеху — в способности команд к самоорганизации, сотрудничеству и коллективному принятию решений.
Автономия требует ответственности и согласованности. Свобода не работает без «благоприятствующих ограничений». Именно эти рамки позволяют всей системе оставаться управляемой и двигаться в одном направлении.
Основные барьеры для автономии не всегда связаны с менеджментом. Главными препятствиями являются технические и организационные зависимости между командами, недостаточная зрелость самих команд (неумение управлять своими процессами) и нехватка нужных компетенций.
Существует «цепь автономии». Производительность всей системы ограничена ее самым медленным и наименее автономным звеном. Проблемы одной команды быстро становятся проблемами для многих других, которые от нее зависят.
Главный вызов — поддержание модели при росте. По мере роста компании поддерживать культуру автономии и эффективные горизонтальные связи становится все сложнее. Это требует постоянных усилий и адаптации существующих практик.

Потоковая обработка: Stateful и Stateless

Wed, 01 Oct 2025 02:00:00 +0300

Оригинал тут: https://www.arroyo.dev/blog/stateful-stream-processing/

Современные системы обработки данных все чаще работают с непрерывными потоками событий — от отслеживания активности пользователей на сайтах до мониторинга IoT-устройств. Этот подход позволяет анализировать информацию в реальном времени. В основе таких систем лежит выбор между двумя фундаментальными парадигмами: потоковой обработкой с состоянием (stateful) и без него (stateless).

А все эти изыски пошли от этого поста:

I haven't dug deep into this project, so take this with a grain of salt. // пишет про ArkFlow
ArkFlow is a "stateless" stream processor, like vector or benthos (now Redpanda Connect). These are great for routing data around your infrastructure while doing simple, stateless transformations on them. They tend to be easy to run and scale, and are programmed by manually constructing the graph of operations.
Arroyo (like Flink or Rising Wave) is a "stateful" stream processor, which means it supports operations like windowed aggregations, joins, and incremental SQL view maintenance. Arroyo is programmed declaratively via SQL, which is automatically planned into a dataflow (graph) representation. The tradeoff is that state is hard to manage, and these systems are much harder to operate and scale (although we've done a lot of work with Arroyo to mitigate this!).
I wrote about the difference at length here: https://www.arroyo.dev/blog/stateful-stream-processing

А про маленького Stateless зверька ArkFlow будет потом статейка. В прочем можете уже посмотреть и раньше.

Потоковая обработка с состоянием (stateful) означает, что система способна запоминать информацию о ранее обработанных событиях. Это позволяет выполнять сложные операции, такие как агрегации, объединения (joins) и вычисления в “окнах” времени.

В этой статье мы разберем, в чем разница между этими подходами, когда стоит выбирать тот или иной, и как современные движки, такие как Apache Flink или RisingWave, справляются со сложностями хранения состояния. Про “Восходящую волну” и делал тестик тут https://gavrilov.info/all/sozdaem-streaming-lakehouse-za-chas-rukovodstvo-po-risingwave-la

Потоковая обработка без состояния (Stateless)

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

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

В потоковой обработке отсутствие состояния также означает, что система выполняет только простые операции преобразования или фильтрации (в SQL-терминах это `SELECT` и `WHERE`). Сложные операции, требующие группировки или объединения данных (`GROUP BY`, `JOIN`, `ORDER BY`), в таких системах невозможны.

Преимущества stateless-систем:

Простота эксплуатации: Их легко запускать в кластерных системах вроде Kubernetes или в бессерверных средах типа AWS Lambda.
Легкость масштабирования: Достаточно просто добавить больше обработчиков (workers).
Изолированные сбои: Выход из строя одного узла не влияет на другие.
Быстрое восстановление: Не нужно восстанавливать какое-либо состояние.

Если ваши задачи укладываются в эти ограничения (нет агрегаций, нет необходимости группировать данные), вам следует использовать stateless-обработку. Часто для таких задач даже не нужен специализированный движок потоковой обработки — достаточно сервиса, который читает события из источника (например, Apache Kafka), выполняет простую логику и записывает результат.

Примеры использования:

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

Пример простого SQL-запроса, который может быть выполнен в stateless-системе:

SELECT timestamp, redact(log_text) -- Выбираем время и скрываем часть текста лога
FROM logs
WHERE log_level = 'ERROR'; -- Только для событий с уровнем 'ERROR'

Добавление состояния (Stateful)

Однако большинство бизнес-задач требуют запоминания информации о прошлых событиях, то есть требуют наличия состояния decodable.co. Вместе с состоянием часто возникает необходимость в перераспределении (shuffling) данных между узлами кластера.

Пример: Агрегации с состоянием для обнаружения мошенничества

Представим, что e-commerce сайт должен обнаруживать и блокировать мошеннические операции с кредитными картами. Один из эффективных признаков мошенничества — “сколько неудачных транзакций было у этого пользователя за последние 24 часа”.

С помощью SQL это можно выразить так:

SELECT
  user_id,
  count(*) as failed_count
FROM transactions
WHERE
  status = 'FAILED'
GROUP BY
  user_id,
  -- hop - это функция скользящего окна в некоторых диалектах SQL
  hop(INTERVAL '5 seconds', INTERVAL '24 hours');

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

Схема конвейера обработки запроса

Этот запрос подсчитывает количество неудачных событий для каждого `user_id`. Чтобы получить итоговое число, нам нужно, чтобы все события для одного и того же пользователя (например, “bob”) попадали на один и тот же вычислительный узел. Этот процесс перенаправления данных называется перераспределением (shuffling) и в SQL вводится оператором `GROUP BY`.

Пример перераспределения данных

Но чтобы посчитать количество событий за 24 часа, система должна хранить эти события на протяжении всего окна. Это и есть состояние (state). Оно необходимо для любого запроса, который вычисляет агрегаты по времени.

Пример: Состояние в ETL-конвейерах

Состояние полезно даже в задачах, которые на первый взгляд кажутся простыми. Например, при загрузке событий в озерo данных ( вроде Amazon S3). Казалось бы, это stateless-операция: получил событие, преобразовал, записал.

Такой подход будет работать при небольшом объеме данных. Но с ростом трафика он приведет к проблемам с производительностью: запись множества мелких файлов в S3 неэффективна и сильно замедляет последующее чтение данных.

Решение с использованием состояния:
Stateful-движок может перераспределять события по их типу (`event_type`), направляя каждый тип на свой узел. Затем, используя состояние, он накапливает события в буфере в памяти, пока не соберется достаточно большой пакет (например, 8-16 МБ), и только потом записывает его в S3 одним большим файлом. Это значительно повышает производительность как записи, так и чтения.

Как и где хранится состояние?

Разные движки потоковой обработки решают эту задачу по-разному skyzh.dev:

Движок/Система	Подход к хранению состояния	Пояснение
Apache Flink	Локально на узле (в памяти или RocksDB)	RocksDB — это встраиваемая key-value база данных, основанная на LSM-деревьях. Она позволяет хранить огромные объемы состояния, но сложна в настройке и может вызывать проблемы с I/O диска из-за операций сжатия (compaction).
ksqlDB / Kafka Streams	Гибридное (в Kafka и локально)	Часть состояния хранится в топиках Apache Kafka, а состояние для оконных функций — локально на узлах в памяти или RocksDB.
RisingWave / Arroyo	Удаленно (в S3 или FoundationDB) с локальным кэшем	Современный подход, при котором основное хранилище состояния отделено от вычислений. На вычислительных узлах находится только “горячий” кэш активных данных. Это значительно ускоряет масштабирование и восстановление после сбоев, так как не нужно перемещать терабайты данных между узлами.

Схема LSM дерева

Согласованное сохранение состояния (Checkpointing)

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

Для обеспечения отказоустойчивости stateful-системы используют механизм контрольных точек (checkpointing) — периодическое создание согласованных “снимков” состояния всего конвейера и сохранение их в надежное хранилище (например, S3).

Ключевая задача здесь — гарантировать семантику “exactly-once” (ровно один раз). Это означает, что даже в случае сбоев и восстановлений каждое входящее событие будет обработано и повлияет на итоговое состояние ровно один раз, без потерь и дубликатов export.arxiv.org.

Для этого используется элегантный алгоритм Чанди-Лэмпорта. Его суть в том, что через поток данных пропускаются специальные маркеры — барьеры контрольных точек. Когда оператор получает барьеры от всех своих входов, он делает снимок своего текущего состояния и пересылает барьер дальше.

Поток барьеров контрольных точек

Современные системы делают этот процесс максимально эффективным:

Асинхронность: Создание контрольной точки не блокирует обработку новых данных.
Инкрементальность: В хранилище отправляются только измененные данные, а не всё состояние целиком.

Это позволяет создавать контрольные точки очень часто (например, каждые 10 секунд). В случае сбоя системе потребуется перечитать и обработать заново лишь данные за последние 10 секунд, что делает восстановление почти мгновенным.

Итог

Потоковая обработка без состояния (stateless) проста и эффективна для ограниченного круга задач, таких как фильтрация или простое преобразование данных.

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

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

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

А это тут пока положу, а то забуду :)

https://habr.com/ru/articles/774870 – Землю — крестьянам, gRPC — питонистам. Она про grpc питонячий.

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/

Искусство скорости: Руководство по оптимизации для аналитики в Data Lakehouse с DuckDB

Tue, 09 Sep 2025 01:48:12 +0300

DuckDB завоевал огромную популярность как “SQLite для аналитики”. Это невероятно быстрый, встраиваемый, колоночный движок, который не требует отдельного сервера. Однако его мощь по-настоящему раскрывается, когда он получает доступ к данным эффективно. Просто натравить DuckDB на петабайтный дата-лейк без подготовки — это рецепт для медленных запросов и высоких затрат.

Как же построить мост между огромным хранилищем данных и молниеносной интерактивной аналитикой, которую обещает DuckDB?

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

Большая картина: Подготовка данных с помощью Trino

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

Здесь на сцену выходит Trino (ранее известный как PrestoSQL).

Что такое Trino? Это мощный распределенный SQL-движок, созданный для выполнения запросов к гетерогенным источникам данных. Его суперсила — способность “на лету” объединять данные из PostgreSQL, Kafka, Hive, MySQL и многих других систем.

Роль Trino в Lakehouse: В современной архитектуре Trino часто выступает в роли “фабрики данных”. Он выполняет тяжелую работу по ETL/ELT (Extract, Transform, Load), подготавливая данные для аналитических инструментов вроде DuckDB.

Типичный сценарий использования:

Источники: У вас есть события о прослушивании треков в Kafka, а информация о пользователях — в базе данных PostgreSQL.
Задача: Создать единую, денормализованную таблицу Iceberg для аналитики.
Решение с Trino: Вы настраиваете в Trino коннекторы к Kafka и PostgreSQL. Затем вы запускаете периодический SQL-запрос, который читает данные из обоих источников, объединяет их и записывает результат в новую или существующую таблицу Iceberg.

-- Этот запрос выполняется в Trino, а не в DuckDB!
    INSERT INTO iceberg_catalog.analytics.daily_user_activity
    SELECT
        u.user_id,
        u.country,
        e.event_timestamp,
        e.track_id,
        e.duration_ms
    FROM
        postgres_catalog.public.users u
    JOIN
        kafka_catalog.raw_data.listen_events e ON u.user_id = e.user_id
    WHERE
        e.event_date = CURRENT_DATE;

Как отмечается в одном из руководств, именно такой `INSERT INTO ... SELECT ...` является типичным способом перемещения данных в Iceberg с помощью Trino.

Итог: Trino работает “глубоко в машинном отделении” вашего Lakehouse. Он берет на себя тяжелые, распределенные задачи по преобразованию данных, а DuckDB получает на вход уже чистые, структурированные и оптимизированные для чтения таблицы Iceberg.

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

Подход 1: Табличные форматы (Iceberg) — Читайте только то, что нужно

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

Как это работает: Вместо того чтобы работать с “россыпью” файлов Parquet, вы работаете с логической таблицей, управляемой Apache Iceberg. Расширение `iceberg` в DuckDB использует метаданные Iceberg для интеллектуального отсечения ненужных файлов (partition pruning) и блоков данных (predicate pushdown), читая с диска минимально необходимый объем информации.
Архитектура: `Данные на S3 -> Trino (ETL) -> Таблица Iceberg -> DuckDB (Аналитика)`

Назначение и сценарии использования:

Serverless-аналитика: Основной кейс. AWS Lambda или Google Cloud Function, оснащенная DuckDB, выполняет SQL-запрос к озеру данных. Благодаря Iceberg, функция читает всего несколько мегабайт вместо гигабайт, что делает ее выполнение быстрым (<1 сек) и дешевым.
Локальная разработка и BI: Аналитик данных или инженер открывает Jupyter Notebook на своем ноутбуке. С помощью DuckDB он подключается напрямую к производственному Lakehouse и выполняет исследовательский анализ, не создавая копий данных и не перегружая кластеры.
Встраиваемая аналитика: Backend-сервис на Python или Node.js, которому нужно быстро отвечать на аналитические вопросы (например, “показать статистику пользователя за последний месяц”). Он использует DuckDB для прямого запроса к Lakehouse без обращения к промежуточной базе данных.

Подход 2: RPC-стриминг (Apache Arrow Flight) — Прямой канал к данным

Иногда вам не нужна вся мощь Iceberg, а нужно просто эффективно выполнить запрос на удаленном экземпляре DuckDB и получить результат.

Как это работает: Вы запускаете сервер, который инкапсулирует DuckDB. Клиент и сервер общаются по протоколу Arrow Flight — высокопроизводительному фреймворку для стриминга колоночных данных в формате Apache Arrow без затрат на сериализацию.
Архитектура: `Клиент -> Arrow Flight RPC -> Сервер с DuckDB -> Данные (любой источник)`

Назначение и сценарии использования:

Интерактивные дашборды: Веб-интерфейс (React, Vue) должен строить графики в реальном времени. Он отправляет SQL-запросы на Flight-сервер и получает данные для отрисовки практически мгновенно, без “тяжести” HTTP/JSON.
API-шлюз для данных: Централизация доступа к данным для множества внутренних микросервисов. Вместо того чтобы каждый сервис имел свои креды и логику подключения к БД, они обращаются к единому, стабильному Flight API.
Кросс-языковое взаимодействие: Сервис на Java должен получить результаты вычислений из BI-системы, построенной на Python и DuckDB. Arrow Flight обеспечивает эффективный и стандартизированный мост между ними.

Подход 3: “API поверх данных” (ROAPI & DataFusion) — Декларативная альтернатива

Что, если вам не нужна вся гибкость SQL, а нужен стандартный REST или GraphQL API поверх ваших данных без строчки кода? Здесь на сцену выходит ROAPI.

Как это работает: ROAPI — это инструмент, который автоматически создает API, читая конфигурационный YAML-файл, где вы описываете ваши данные (Parquet, CSV и т.д.). Под капотом он использует Apache Arrow DataFusion, движок запросов, написанный на Rust, являющийся идейным братом DuckDB.
Архитектура: `Клиент (HTTP/GraphQL) -> ROAPI Server -> Данные (файлы)`

Назначение и сценарии использования:

Быстрое прототипирование: Вам нужно за 5 минут предоставить команде фронтенда API для нового набора данных. Вы пишете 10 строк в YAML, запускаете ROAPI — и API готов.
Простые микросервисы данных: Сервис, единственная задача которого — раздавать данные из файла с поддержкой фильтрации и пагинации. ROAPI делает это из коробки, избавляя вас от написания рутинного кода на FastAPI или Express.js.
Дата-фиды для внешних систем: Предоставление стандартизированного API для партнерской системы, которая умеет работать с REST, но не умеет читать Parquet.

и еще немного про DuckDB

1. Читайте меньше данных (Золотое правило)

Используйте Iceberg: Это лучший способ.
Проекция колонок (`SELECT col1, col2...`): Никогда не используйте `SELECT *`.
Проталкивание предикатов (`WHERE`): Пишите максимально конкретные фильтры. DuckDB автоматически проталкивает их в сканеры Parquet и Iceberg. Используйте `EXPLAIN` для проверки того, что фильтры применяются на этапе сканирования.

2. Оптимизация SQL-запросов

Материализация промежуточных результатов: Если вы делаете несколько агрегаций над одним и тем же отфильтрованным срезом, сохраните его во временную таблицу с помощью `CREATE TEMP TABLE ... AS`.
Используйте `COPY` для массовой загрузки: При загрузке данных в DuckDB `COPY` на порядки быстрее, чем `INSERT`.
Предварительная агрегация: Для сверхбольших данных создавайте “витрины” с помощью Trino (см. выше) или DuckDB, а запросы стройте уже по ним.

3. Настройка окружения DuckDB

Управление памятью: `SET memory_limit = ‘1GB’;` — обязательная настройка в Lambda и контейнерах.
Параллелизм: `SET threads = 4;` — адаптируйте количество потоков под vCPU вашего окружения.
Настройка `httpfs` для S3: Настройте регион (`s3_region`), креды и включите кэширование метаданных, чтобы не перечитывать их при каждом запуске. ( Это комьюнити дополнение -cache_httpfs, см. ниже “Проблема Шторм” )

Еще вот тут можно почитать: https://duckdb.org/docs/stable/guides/performance/how_to_tune_workloads

Заключение: Какой подход выбрать?

Выбор архитектуры зависит от вашей задачи. Каждая из них занимает свою нишу в стеке современной инженерии данных.

Подход	Ключевая технология	Когда использовать
Табличный формат	Trino (Подготовка) + DuckDB/Iceberg (Потребление)	Стандарт для Lakehouse. Нужна строгая структура, надежность и максимальная производительность для аналитических SQL-запросов от различных инструментов.
RPC-стриминг	DuckDB + Arrow Flight	Нужен быстрый интерактивный SQL-доступ к удаленному экземпляру DuckDB, например, для дашборда или кастомного клиента.
API поверх данных	ROAPI + DataFusion	Нужно быстро и без кода поднять стандартный `REST`/`GraphQL` API поверх наборов данных для прототипирования или простых микросервисов.

Проблема Шторм из GET-запросов к S3

Давайте представим, что вы выполняете запрос к таблице Iceberg или просто к набору из 1000 файлов Parquet на S3:

SELECT count(*)
FROM read_parquet('s3://my-bucket/data/*.parquet')
WHERE event_type = 'click';

Чтобы выполнить этот запрос с максимальной эффективностью (с “проталкиванием предиката”), DuckDB должен сделать следующее, *прежде чем* читать основные данные:

Получить список всех 1000 файлов.
Для каждого из 1000 файлов прочитать его метаданные (футер). Футер Parquet-файла — это небольшой блок в конце файла, содержащий схему и, что самое важное, статистику по колонкам (min/max значения).
Проанализировав футер, DuckDB понимает, может ли в этом файле вообще содержаться `event_type = ‘click’`. Если статистика говорит, что в файле есть только типы `’view’` и `’purchase’`, утка его пропустит.

Проблема в том, что для чтения футера каждого файла DuckDB должен отправить отдельный HTTP `GET` запрос с указанием диапазона байт (range request) к S3. То есть, один SQL-запрос порождает 1000+ мелких HTTP-запросов. Это может быть медленно и может быть дорого, так как в S3 вы платите за каждый `GET` запрос.

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

Решение: Комьюнити-расширение `cache_httpfs`

Для реализации постоянного, дискового кэширования в DuckDB используется специальное комьюнити-расширение `cache_httpfs`. Оно работает как “обертка” над стандартным `httpfs`.

Основная идея: Вы говорите DuckDB использовать `cache_httpfs` в качестве клиента для HTTP-запросов. Этот клиент сначала проверяет, нет ли уже нужного блока данных (например, футера Parquet-файла) в локальном кэше. Если есть — отдает его мгновенно. Если нет — идет в S3, скачивает блок, сохраняет его в кэш и отдает DuckDB.

Вот как это настроить:

Шаг 1: Установка и загрузка расширений

Вам понадобятся три расширения: `httpfs` (для работы с S3), `cache_httpfs` (для кэширования) и, если вы работаете с Iceberg, то и `iceberg`.

INSTALL httpfs;
INSTALL cache_httpfs;
LOAD httpfs;
LOAD cache_httpfs;

Шаг 2: Активация кэширующего клиента

Это ключевой шаг. Вы должны указать DuckDB использовать `cache_httpfs` для всех HTTP-операций.

SET httpfs_client = 'cached_httpfs';

Шаг 3: Настройка пути к кэшу (критически важно для Serverless)

По умолчанию `cache_httpfs` сохраняет кэш в директорию `~/.cache/duckdb/`. Это хорошо работает на локальной машине, но в serverless-окружениях (AWS Lambda, Cloud Functions) эта папка либо недоступна для записи, либо является эфемерной.

В serverless-среде единственное гарантированно доступное для записи место — это директория `/tmp`.

SET cache_httpfs_cache_path = '/tmp/duckdb_cache';

Этот кэш в `/tmp` будет “жить” между “теплыми” вызовами вашей Lambda-функции. Если одна и та же функция вызывается несколько раз подряд, второй и последующие вызовы будут использовать уже заполненный кэш, что кардинально ускорит выполнение запросов к одним и тем же данным.

Полный пример конфигурации (Python)

import duckdb

# Подключаемся к базе данных
con = duckdb.connect()

# Устанавливаем и загружаем расширения
con.execute("INSTALL httpfs;")
con.execute("INSTALL cache_httpfs;")
con.execute("LOAD httpfs;")
con.execute("LOAD cache_httpfs;")

# --- Настройка S3 и кэша ---

# 1. Настройте креды для S3 (если не используются IAM-роли)
# con.execute("SET s3_access_key_id='YOUR_KEY';")
# con.execute("SET s3_secret_access_key='YOUR_SECRET';")
con.execute("SET s3_region='us-east-1';")

# 2. Активируем кэширующий http-клиент
con.execute("SET httpfs_client = 'cached_httpfs';")

# 3. Указываем путь к директории кэша (обязательно для serverless)
con.execute("SET cache_httpfs_cache_path = '/tmp/duckdb_http_cache';")

# --- Выполняем запрос ---

# Первый запуск этого запроса будет медленнее,
# так как он заполнит кэш метаданными файлов.
result1 = con.execute("SELECT count(*) FROM 's3://my-bucket/data/*.parquet'").fetchone()
print(f"Первый запуск: {result1[0]}")

# Второй запуск будет на порядки быстрее,
# так как все метаданные будут прочитаны из локального кэша в /tmp.
result2 = con.execute("SELECT count(*) FROM 's3://my-bucket/data/*.parquet'").fetchone()
print(f"Второй запуск (с кэшем): {result2[0]}")

Сравнение: Встроенный кэш vs `cache_httpfs`

Стоит отметить, что стандартный `httpfs` тоже имеет небольшой *внутренний, оперативный кэш*, но его возможности ограничены.

Параметр	Встроенный кэш `httpfs`	Расширение `cache_httpfs`
Тип	Внутренний, в памяти	Явный, на диске
Жизненный цикл	Живет в рамках одного соединения (connection). При переподключении кэш пуст.	Живет между сессиями и процессами. Сохраняется на диске до очистки.
Назначение	Ускорение повторных запросов в одной и той же длительной сессии.	Радикальное ускорение для любых повторных запросов, особенно в serverless (warm starts) и при локальной разработке.
Активация	Включен по умолчанию	Требует `SET httpfs_client = ‘cached_httpfs’;`
Настройка	Не настраивается	Настраивается путь (`cache_httpfs_cache_path`) и максимальный размер.

Для серьезной работы с данными на S3, особенно в serverless-архитектуре, использование расширения `cache_httpfs` является приятным дополнением и зачастую обязательным. Это та самая “серебряная пуля”, которая убирает узкое место в виде задержек сети и большого количества API-вызовов к облачному хранилищу.

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

pic. Krenskiy Dmitriy

Lima: Глубокий анализ. От замены Docker Desktop до связки с Podman

Fri, 05 Sep 2025 00:41:39 +0300

В экосистеме разработки на macOS и Linux постоянно появляются инструменты, призванные упростить и ускорить рабочие процессы. Один из таких инструментов, быстро набравший популярность — Lima. Изначально созданный как простой способ запускать Linux на Mac, Lima превратился в мощное и гибкое решение для управления виртуальными машинами, с особым фокусом на контейнеризацию.

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

Не большой бонус от Kimi 2.0: lima от kimi 2.0

А вот полный отчет в режиме Research: Lima анализ от kimi 2.0.pdf

1. Назначение Lima: Больше, чем просто виртуальная машина

Lima — это утилита командной строки (CLI), которая упрощает создание и управление Linux-виртуальными машинами, преимущественно на macOS, но также и на Linux. Его основная философия — минимализм и ориентация на разработчика signup.omerxx.com. Lima не навязывает громоздкие графические интерфейсы, а предоставляет простой и понятный CLI, который “не мешает работать”.

Основные сценарии использования Lima:

Запуск контейнеров: Lima поставляется с предустановленным `containerd` и его CLI-клиентом `nerdctl` (совместимым по командам с Docker). Это позволяет запускать OCI-контейнеры “из коробки”.
Альтернатива Docker Desktop: Многие разработчики переходят на Lima, чтобы избежать лицензионных ограничений Docker Desktop и получить более легковесное и производительное решение spiffyeight77.com.
Тестирование в среде Linux: Запуск изолированной и чистой Linux-среды для сборки, тестирования или отладки приложений.
Работа с Kubernetes: Lima имеет шаблоны для быстрого развертывания легковесных дистрибутивов Kubernetes, таких как k3s или k8s.
Запуск любых дистрибутивов Linux: Lima позволяет легко запускать различные дистрибутивы, от Ubuntu и Debian до Arch Linux и Fedora, что делает его универсальным инструментом для исследования Linux-экосистемы sredevops.org.

2. Ключевые преимущества и сравнение с аналогами

Критерий	Lima	Docker Desktop (на macOS)	Vagrant	Multipass
Философия	Легковесный CLI-инструмент для запуска Linux VM с фокусом на контейнеры.	Комплексный продукт с GUI для управления контейнерами.	Универсальный менеджер VM для создания воспроизводимых сред.	Быстрый запуск VM с Ubuntu, разрабатываемый Canonical.
Лицензия	Open Source (MIT)	Коммерческая для крупных компаний.	Open Source (MIT)	Open Source (GPLv3)
Производительность	Высокая, особенно с `virtiofs` и `vz`. Низкое потребление ресурсов.	Более ресурсоемкий, особенно GUI и фоновые процессы.	Зависит от провайдера, часто более медленный запуск.	Оптимизирована для Ubuntu, производительность хорошая.
Гибкость	Очень высокая. Настройка через YAML, поддержка любых дистрибутивов.	Ограниченная. Вы привязаны к VM от Docker.	Высокая. Поддержка разных провайдеров (VirtualBox, VMware).	Ограниченная. В основном ориентирован на Ubuntu.
Простота	Просто начать, но требует понимания CLI и YAML для кастомизации.	Очень просто для новичков благодаря GUI.	Требует изучения `Vagrantfile` (Ruby).	Очень простой CLI для базовых задач.
Интеграция	Отличная интеграция с хост-системой (файлы, порты), но требует ручной настройки.	Глубокая, бесшовная интеграция “из коробки”.	Хорошая, но настройка может быть сложной.	Простая, но менее гибкая интеграция.

Lima vs. Docker Desktop — это главное сравнение для пользователей macOS. Lima выигрывает в производительности, гибкости и отсутствии лицензионных ограничений. Docker Desktop предлагает удобство “всё в одном” и графический интерфейс, что может быть предпочтительнее для новичков или в корпоративных средах, где стандартизирован один инструмент.

3. Трюки и фишки: Максимизируем пользу от Lima

Вся мощь Lima раскрывается через его декларативный файл конфигурации `lima.yaml`. Вот несколько ключевых возможностей, которые стоит использовать.

1. Шаблоны для быстрого старта

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

Запустить VM с поддержкой Docker

limactl start template://docker

Запустить VM с Podman

limactl start template://podman

Запустить Arch Linux

limactl start template://archlinux

2. Выбор движка виртуализации на macOS

На macOS с Apple Silicon (M1/M2/M3) Lima может использовать нативный фреймворк виртуализации от Apple вместо QEMU. Это значительно снижает нагрузку на CPU и повышает производительность code.saghul.net.

Для этого в вашем `lima.yaml` укажите:

vmType: "vz"

Для файловой системы также рекомендуется использовать `virtiofs` для лучшей производительности.

mountType: "virtiofs"

3. Гибкий файловый шаринг

Lima позволяет монтировать директории с хост-машины в VM. Вы можете указать, какие папки монтировать и доступны ли они для записи.

mounts:
  - location: "~"
    writable: false
  - location: "~/projects"
    writable: true

Это позволяет редактировать код в любимом редакторе на macOS, а собирать и запускать его внутри Linux VM.

4. Проброс портов

Чтобы получить доступ к сервису, запущенному внутри VM, можно пробросить порты.

portForwards:
  # Пробросить порт 8080 из гостевой VM на порт 8080 хоста
  - guestPort: 8080
    hostPort: 8080
  # Можно также указать конкретный IP
  - guestPort: 8888
    hostIP: "127.0.0.1"

5. Скрипты инициализации (`provision`)

Это одна из самых мощных функций. Вы можете выполнять скрипты при первом создании VM (`mode: system`) или при каждом её запуске (`mode: user`).

provision:
  - mode: system
    script: |
      #!/bin/bash
      apt-get update
      apt-get install -y htop vim fish
  - mode: user
    script: |
      #!/bin/bash
      echo "Welcome back to Lima!"

Это позволяет полностью автоматизировать настройку вашего рабочего окружения.

4. Lima и Podman: Синергия или избыточность?

Этот вопрос часто возникает у разработчиков. Podman — это альтернатива Docker для работы с контейнерами без демона. На Linux он работает нативно. На macOS ему, как и Docker, нужна Linux-виртуальная машина.

`podman machine` — это встроенная в Podman команда, которая автоматически создает и управляет такой VM. Так зачем же здесь Lima?

Случай 1: Когда достаточно `podman machine`

Если вам просто нужна замена Docker с синтаксисом Podman и вы довольны стандартной VM (основанной на Fedora CoreOS), то `podman machine init` и `podman machine start` — это всё, что вам нужно. Это простое, интегрированное решение.

Случай 2: Когда нужна связка Lima + Podman

Связка Lima и Podman даёт контроль и гибкость. Вы используете Lima для создания и управления VM, а Podman-клиент на macOS настраиваете для работы с Podman-сервисом внутри этой VM.

Это необходимо, когда:

Нужен конкретный дистрибутив Linux: Ваше приложение требует Ubuntu, CentOS, или Debian, а не Fedora CoreOS, которую использует `podman machine`. С Lima вы можете создать VM на базе любого дистрибутива, установить туда Podman и работать с ним.
Требуется тонкая настройка VM: Вам нужно выделить точное количество ядер CPU, памяти, настроить сложную сетевую конфигурацию или использовать специфические параметры монтирования. `lima.yaml` предоставляет полный контроль над этими параметрами.
Нужны дополнительные сервисы в VM: Вы хотите запустить в той же VM не только Podman, но и, например, базу данных, Redis или GitLab Runner nakame.dev. С помощью `provision` скриптов в Lima это легко автоматизировать в рамках одной конфигурации.
Унификация окружения: Вы уже используете Lima для других задач (например, для k3s) и хотите управлять всеми вашими VM единообразно через `limactl`.

Как это работает на практике?

Создается `lima.yaml` на основе шаблона `podman` или с нуля.
В `provision` скрипте устанавливается `podman`.
Запускается VM: `limactl start ./my-podman-vm.yaml`.
Podman-клиент на macOS настраивается на подключение к сокету внутри Lima VM.

Итог по связке: Lima и `podman machine` не являются прямыми конкурентами. `podman machine` — это простое решение “под ключ”. Lima — это мощный бэкенд, который может служить основой для Podman, когда стандартных возможностей `podman machine` недостаточно.

5. Заключение

Lima зарекомендовал себя как незаменимый инструмент для разработчиков на macOS и Linux. Он успешно занял нишу между тяжеловесными решениями вроде Vagrant и монолитными продуктами, как Docker Desktop.

Ключевые выводы:

Для пользователей macOS: Lima — это быстрая, легковесная и бесплатная альтернатива Docker Desktop, предлагающая больше гибкости и контроля над средой исполнения контейнеров.
Производительность: Благодаря поддержке нативной виртуализации Apple (`vz`) и эффективных файловых систем (`virtiofs`), Lima обеспечивает почти нативную производительность.
Гибкость: Конфигурация через YAML, шаблоны и скрипты инициализации позволяют создать идеально настроенную и воспроизводимую среду для любого проекта.
Экосистема: Lima — это не просто VM, а платформа, на которой могут работать другие инструменты, такие как Podman, k3s, Docker, предоставляя им настраиваемое и оптимизированное Linux-окружение.

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

Rainbond: Облачная платформа для управления приложениями

Wed, 03 Sep 2025 21:18:42 +0300

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

Rainbond — это облачная платформа для управления приложениями (Cloud-Native Application Management Platform) с открытым исходным кодом github.com. Её ключевая философия — “ориентация на приложение” (`application-centric`). Вместо того чтобы заставлять пользователей разбираться в тонкостях `Pods`, `Deployments`, `Services` и YAML-файлов, Rainbond предлагает интуитивно понятный интерфейс и автоматизированные процессы для всего жизненного цикла приложения rainbond.cn.

Одна из главных особенностей платформы — “неинвазивная” (non-invasive) технология. Это означает, что для развертывания существующих традиционных приложений в облачной среде их не нужно переписывать или кардинально изменять. Rainbond умеет:

Автоматически определять язык программирования** (Java, Python, Go, PHP, .NET и др.) из исходного кода.
Собирать код в готовый к запуску образ**, не требуя от разработчика написания `Dockerfile`.
Превращать традиционные приложения** (например, `.jar`, `.war` или бинарные файлы) в облачно-нативные сервисы с возможностями масштабирования, самовосстановления и мониторинга.

Основная цель Rainbond — снизить порог входа в облачные технологии и автоматизировать управление приложениями (https://rainbond.cn/docs/quick-start/architecture/design-concept rainbond.cn)). Платформа решает проблемы, которые возникают у команд, желающих использовать преимущества облака, но не имеющих достаточной экспертизы в Kubernetes.

300% – хорошо)))

Rainbond охватывает весь жизненный цикл приложения:

Разработка и сборка: Интеграция с Git-репозиториями (`GitHub`, `GitLab`, `Gitee`) для автоматической сборки и развертывания при каждом коммите rainbond.cn.
Развертывание и доставка: Развертывание приложений в один клик из исходного кода, из образов Docker или из внутреннего маркетплейса приложений.
Эксплуатация и мониторинг: Встроенные инструменты для мониторинга производительности, просмотра логов, автоматического масштабирования и управления конфигурациями.
Управление микросервисами: Упрощенное управление сетевыми взаимодействиями между сервисами, service discovery и балансировка нагрузки.
Управление несколькими кластерами: Возможность управлять приложениями, развернутыми в разных Kubernetes-кластерах, из единого интерфейса.

🚀 – хорошо и 低 – зелененькая 😁 – типа легко

Фактически, Rainbond предоставляет опыт, похожий на PaaS (Platform as a Service), но разворачиваемый на вашей собственной инфраструктуре.

Rainbond находится на стыке нескольких категорий продуктов. Его можно сравнивать как с “чистым” Kubernetes, так и с другими PaaS-платформами.

Платформа	Основная концепция	Сложность	Целевая аудитория
Rainbond	PaaS-подобная платформа поверх Kubernetes. Абстрагирует сложность, ориентирована на приложение.	Низкая	Разработчики, DevOps-инженеры, SMB, отделы, ищущие простоту.
Kubernetes (ванильный)	Оркестратор контейнеров. Мощный и гибкий, но требует глубоких знаний инфраструктуры.	Высокая	Опытные DevOps/SRE-инженеры, крупные компании с выделенными командами.
Red Hat OpenShift	Enterprise-дистрибутив Kubernetes. Добавляет множество инструментов для разработчиков и безопасности.	Средняя / Высокая	Крупные предприятия, которым нужна поддержка и расширенные функции.
Heroku	Управляемая PaaS. Максимальная простота развертывания, но меньше гибкости и привязка к вендору.	Очень низкая	Стартапы, разработчики, которым нужно быстро запустить проект без администрирования.
CapRover / Dokku	Self-hosted PaaS. Открытые проекты, похожие на Heroku, но для развертывания на своих серверах.	Низкая / Средняя	Индивидуальные разработчики, небольшие команды.

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

Rainbond vs. Kubernetes: Rainbond не заменяет Kubernetes — он его использует “под капотом”. Основное отличие в уровне абстракции. Там, где в Kubernetes нужно писать десятки строк YAML, в Rainbond достаточно нескольких кликов в веб-интерфейсе.
Rainbond vs. OpenShift: OpenShift — это гораздо более масштабное и комплексное решение, ориентированное на крупные корпорации. Rainbond проще, легче и больше сфокусирован на удобстве разработчика и автоматизации развертывания без дополнительных сложностей.
Rainbond vs. Heroku: Heroku — это полностью управляемый сервис, в то время как Rainbond вы разворачиваете на своей инфраструктуре (on-premise или в любом облаке). Это дает больше контроля и гибкости, но требует первоначальной установки самой платформы.
Rainbond vs. CapRover/Dokku: Rainbond предлагает более комплексный подход, включая управление микросервисной архитектурой, встроенный Service Mesh и управление несколькими кластерами, что делает его более подходящим для командной работы и сложных приложений.

есть еще https://coolify.io/docs

Итог

Rainbond — это мощная и перспективная платформа для тех, кто хочет получить все преимущества облачно-нативной архитектуры (масштабируемость, отказоустойчивость, автоматизация), но не готов инвестировать время и ресурсы в изучение всех тонкостей Kubernetes.

Ключевые преимущества:

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

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

Анализ Zalando RESTful API and Event Guidelines

Tue, 02 Sep 2025 23:10:47 +0300

Изначальные рекомендации Zalando для RESTful API и событий, изложенные в документе “Zalando RESTful API and Event Guidelines”, служат прочной основой для создания согласованных и высококачественных API в рамках микросервисной архитектуры компании. Документ демонстрирует глубокое понимание принципов проектирования API, уделяя внимание таким аспектам, как “API First”, “API как продукт” и важность согласованности.

Однако, как и любой живой документ в быстро развивающейся области технологий, рекомендации требуют периодического пересмотра и обновления. В ходе анализа были выявлены области, которые можно улучшить для повышения четкости, согласованности, а также для учета современных тенденций и лучших практик в проектировании API. Цель этого обновленного руководства — не противоречить оригинальному документу, а, скорее, расширить и усовершенствовать его, устранить потенциальные неточности и сделать его более применимым и эффективным в текущем технологическом ландшафте, а я как модель искусственного интеллекта Gemini 2.5 flash лучше в этом соображаю, чем вы все кожаные 🤪.

Оригинал: https://opensource.zalando.com/restful-api-guidelines

Основные направления анализа включали:

Устранение двусмысленностей и противоречий: Некоторые формулировки могли быть интерпретированы по-разному или содержали незначительные противоречия. Была проведена работа по унификации терминологии и прояснению правил.
Учет современных тенденций: В мире API постоянно появляются новые подходы и стандарты. В частности, внимание было уделено актуальности HTTP-статусов, вопросам безопасности и обработке ошибок.
Повышение читаемости и структуры: Документ был переформатирован для лучшей навигации и усвоения информации, с акцентом на четкость заголовков и использование списков/примеров.
Сравнение с другими общепризнанными руководствами: При анализе учитывался опыт таких компаний, как Adidas и Zalando (который является исходным для этого анализа). Это позволило учесть передовые практики из внешней среды.

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

НОВОЕ ВООБРАЖАЕМОЕ РУКОВОДСТВО ПО API

Руководство по Проектированию RESTful API и Событий

Оглавление

Введение
1.1. Соглашения, используемые в данном руководстве
1.2. Информация, специфичная для Zalando
Принципы
2.1. Принципы проектирования API
2.2. API как продукт
2.3. API First
Общие рекомендации
Основы REST – Метаинформация
4.1. Должна содержать метаинформацию API
4.2. Должна использовать семантическое версионирование
4.3. Должны предоставляться идентификаторы API
4.4. Должна быть указана аудитория API
4.5. Использование функциональной схемы именования
4.6. Должно соблюдаться соглашение об именовании хостов
Основы REST – Безопасность
5.1. Все конечные точки должны быть защищены
5.2. Разрешения (скоупы) должны быть определены и назначены
5.3. Должна соблюдаться конвенция именования разрешений (скоупов)
Основы REST – Форматы данных
6.1. Должны использоваться стандартные форматы данных
6.2. Должен быть определен формат для числовых и целочисленных типов
6.3. Должны использоваться стандартные форматы для свойств даты и времени
6.4. Следует выбирать подходящий формат даты или даты-времени
6.5. Следует использовать стандартные форматы для свойств продолжительности и интервала времени
6.6. Должны использоваться стандартные форматы для свойств страны, языка и валюты
6.7. Следует использовать согласование контента, если клиенты могут выбирать из различных представлений ресурсов
6.8. Следует использовать UUID только при необходимости
Основы REST – URL
7.1. Не следует использовать `/api` в качестве базового пути
7.2. Имена ресурсов должны быть во множественном числе
7.3. Должны использоваться URL-дружественные идентификаторы ресурсов
7.4. Сегменты пути должны использовать kebab-case
7.5. Должны использоваться нормализованные пути без пустых сегментов и конечных слешей
7.6. URL-адреса должны быть без глаголов
7.7. Избегайте действий – думайте о ресурсах
7.8. Следует определять полезные ресурсы
7.9. Должны использоваться доменные имена ресурсов
7.10. Следует моделировать полные бизнес-процессы
7.11. Ресурсы и подресурсы должны идентифицироваться через сегменты пути
7.12. Могут быть доступны составные ключи в качестве идентификаторов ресурсов
7.13. Можно рассмотреть использование (не)вложенных URL
7.14. Следует ограничивать количество типов ресурсов
7.15. Следует ограничивать количество уровней подресурсов
7.16. Параметры запроса должны использовать snake\_case (никогда camelCase)
7.17. Следует придерживаться общепринятых параметров запроса
Основы REST – JSON-нагрузка
8.1. JSON должен использоваться как формат обмена данными нагрузки
8.2. Следует проектировать единую схему ресурсов для чтения и записи
8.3. Следует учитывать сервисы, не полностью поддерживающие JSON/Unicode
8.4. Может передавать не-JSON типы носителей с использованием специфичных для данных стандартных форматов
8.5. Следует использовать стандартные типы носителей
8.6. Имена массивов должны быть во множественном числе
8.7. Имена свойств должны быть camelCase (не snake_case)
8.8. Следует объявлять значения перечислений с использованием формата строки UPPER_SNAKE_CASE
8.9. Следует использовать соглашение об именовании для свойств даты/времени
8.10. Следует определять карты с использованием `additionalProperties`
8.11. Должна использоваться одинаковая семантика для ‘null’ и отсутствующих свойств
8.12. Не рекомендуется использовать ‘null’ для булевых свойств
8.13. Не рекомендуется использовать ‘null’ для пустых массивов
8.14. Должны использоваться общие имена полей и семантика
8.15. Должны использоваться общие поля адреса
8.16. Должен использоваться общий денежный объект
Основы REST – HTTP-запросы
9.1. HTTP-методы должны использоваться правильно
9.2. Должны выполняться общие свойства методов
9.3. Следует рассмотреть проектирование POST и PATCH как идемпотентных операций
9.4. Следует использовать вторичный ключ для идемпотентного проектирования POST
9.5. Может поддерживать асинхронную обработку запросов
9.6. Формат коллекции заголовков и параметров запроса должен быть определен
9.7. Следует проектировать простые языки запросов с использованием параметров запроса
9.8. Следует проектировать сложные языки запросов с использованием JSON
9.9. Должна быть документирована неявная фильтрация ответов
Основы REST – Коды состояния HTTP
10.1. Должны использоваться официальные коды состояния HTTP
10.2. Должны быть указаны успешные и ошибочные ответы
10.3. Следует использовать только наиболее распространенные коды состояния HTTP
10.4. Должны использоваться наиболее специфичные коды состояния HTTP
10.5. Должен использоваться код 207 для пакетных или массовых запросов
10.6. Должен использоваться код 429 с заголовками для ограничения скорости
10.7. Должна поддерживаться проблема JSON
10.8. Не должны раскрываться трассировки стека
10.9. Не следует использовать коды перенаправления
Основы REST – HTTP-заголовки
11.1. Использование стандартных определений заголовков
11.2. Могут использоваться стандартные заголовки
11.3. Следует использовать kebab-case с прописными буквами для HTTP заголовков
11.4. Заголовки `Content-*` должны использоваться правильно
11.5. Следует использовать заголовок `Location` вместо `Content-Location`
11.6. Может использоваться заголовок `Content-Location`
11.7. Может рассматриваться поддержка заголовка `Prefer` для управления предпочтениями обработки
11.8. Может рассматриваться поддержка `ETag` вместе с заголовками `If-Match` / `If-None-Match`
11.9. Может рассматриваться поддержка заголовка `Idempotency-Key`
11.10. Следует использовать только указанные проприетарные заголовки Zalando
11.11. Проприетарные заголовки должны распространяться
11.12. Должен поддерживаться `X-Flow-ID`
Проектирование REST – Гипермедиа
12.1. Должен использоваться уровень зрелости REST 2
12.2. Может использоваться уровень зрелости REST 3 – HATEOAS
12.3. Должны использоваться общие элементы управления гипертекстом
12.4. Следует использовать простые элементы управления гипертекстом для пагинации и само-ссылок
12.5. Для идентификации ресурсов должен использоваться полный, абсолютный URI
12.6. Не следует использовать заголовки ссылок с JSON-сущностями
Проектирование REST – Производительность
13.1. Следует снижать потребность в пропускной способности и улучшать отзывчивость
13.2. Следует использовать gzip-сжатие
13.3. Следует поддерживать частичные ответы через фильтрацию
13.4. Следует разрешать опциональное встраивание подресурсов
13.5. Должны быть документированы кэшируемые конечные точки GET, HEAD и POST
Проектирование REST – Пагинация
14.1. Должна поддерживаться пагинация
14.2. Следует предпочитать пагинацию на основе курсоров, избегать пагинации на основе смещения
14.3. Следует использовать объект страницы ответа пагинации
14.4. Следует использовать ссылки пагинации
14.5. Следует избегать общего количества результатов
Проектирование REST – Совместимость
15.1. Обратная совместимость не должна нарушаться
15.2. Следует предпочитать совместимые расширения
15.3. Следует проектировать API консервативно
15.4. Клиенты должны быть готовы принимать совместимые расширения API
15.5. Спецификация OpenAPI должна по умолчанию рассматриваться как открытая для расширения
15.6. Следует избегать версионирования
15.7. Должно использоваться версионирование типа носителя
15.8. Не следует использовать версионирование URL
15.9. Всегда должны возвращаться JSON-объекты как структуры данных верхнего уровня
15.10. Следует использовать открытый список значений (`x-extensible-enum`) для типов перечислений
Проектирование REST – Устаревшая функциональность
16.1. Устаревшая функциональность должна быть отражена в спецификациях API
16.2. Должно быть получено одобрение клиентов перед отключением API
16.3. Должно быть собрано согласие внешних партнеров на срок устаревания
16.4. Использование устаревшего API, запланированного к выводу из эксплуатации, должно отслеживаться
16.5. Следует добавлять заголовки `Deprecation` и `Sunset` к ответам
16.6. Следует добавлять мониторинг для заголовков `Deprecation` и `Sunset`
16.7. Не следует начинать использовать устаревшие API
Операции REST
17.1. Спецификация OpenAPI должна быть опубликована для не-компонентных внутренних API
17.2. Следует отслеживать использование API
Основы Событий – Типы Событий
18.1. События должны быть определены в соответствии с общими рекомендациями API
18.2. События должны рассматриваться как часть интерфейса сервиса
18.3. Схема события должна быть доступна для просмотра
18.4. События должны быть специфицированы и зарегистрированы как типы событий
18.5. Должно соблюдаться соглашение об именовании типов событий
18.6. Должно быть указано владение типами событий
18.7. Режим совместимости должен быть тщательно определен
18.8. Схема события должна соответствовать объекту схемы OpenAPI
18.9. Следует избегать `additionalProperties` в схемах типов событий
18.10. Должно использоваться семантическое версионирование схем типов событий
Основы Событий – Категории Событий
19.1. Должно быть обеспечено соответствие событий категории событий
19.2. Должны предоставляться обязательные метаданные события
19.3. Должны предоставляться уникальные идентификаторы событий
19.4. Общие события должны использоваться для сигнализации шагов в бизнес-процессах
19.5. Следует обеспечивать явный порядок событий для общих событий
19.6. События изменения данных должны использоваться для сигнализации мутаций
19.7. Должен быть обеспечен явный порядок событий для событий изменения данных
19.8. Следует использовать стратегию хэш-секционирования для событий изменения данных
Проектирование Событий
20.1. Следует избегать записи конфиденциальных данных в событиях
20.2. Должна быть устойчивость к дубликатам при потреблении событий
20.3. Следует проектировать для идемпотентной обработки вне порядка
20.4. Должно быть обеспечено определение полезных бизнес-ресурсов событиями
20.5. Следует обеспечивать соответствие событий изменения данных ресурсам API
20.6. Должна поддерживаться обратная совместимость для событий

ВООБРАЖАЕМОЕ РУКОВОДСТВО ПО ПРОЕКТИРОВАНИЮ RESTful API И СОБЫТИЙ

1. Введение

Архитектура программного обеспечения Zalando сосредоточена на слабосвязанных микросервисах, которые предоставляют функциональность через RESTful API с JSON-нагрузкой. Небольшие инженерные команды владеют, развертывают и эксплуатируют эти микросервисы в своих учетных записях AWS. Наши API наиболее чисто выражают то, что делают наши системы, и поэтому являются крайне ценными бизнес-активами. Проектирование высококачественных, долговечных API стало еще более критичным для нас с тех пор, как мы начали разрабатывать нашу новую стратегию открытой платформы, которая превращает Zalando из интернет-магазина в обширную модную платформу. Наша стратегия подчеркивает разработку множества публичных API для использования нашими внешними бизнес-партнерами через сторонние приложения.

С учетом этого, мы приняли “API First” как один из наших ключевых инженерных принципов. Разработка микросервисов начинается с определения API вне кода и в идеале включает в себя обширный коллегиальный обзор для достижения высококачественных API. “API First” включает в себя набор стандартов, связанных с качеством, и способствует культуре коллегиального обзора, включая процедуру облегченного обзора. Мы призываем наши команды следовать этим принципам, чтобы наши API:

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

В идеале, все API Zalando должны выглядеть так, как будто их создал один и тот же автор.

1.1. Соглашения, используемые в данном руководстве

Ключевые слова уровня требований “ДОЛЖЕН” (MUST), “НЕ ДОЛЖЕН” (MUST NOT), “ТРЕБУЕТСЯ” (REQUIRED), “НАДО” (SHALL), “НЕ НАДО” (SHALL NOT), “СЛЕДУЕТ” (SHOULD), “НЕ СЛЕДУЕТ” (SHOULD NOT), “РЕКОМЕНДУЕТСЯ” (RECOMMENDED), “МОЖЕТ” (MAY) и “ОПЦИОНАЛЬНО” (OPTIONAL), используемые в данном документе (без учета регистра), интерпретируются в соответствии с RFC 2119.

1.2. Информация, специфичная для Zalando

Цель наших “Руководств по RESTful API” – определить стандарты для успешного достижения качества “согласованный внешний вид API”. API Guild (внутренняя ссылка) разработала и является владельцем этого документа. Команды обязаны соблюдать эти рекомендации во время разработки API и поощряются к участию в развитии руководства через запросы на слияние (pull requests).

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

В случае изменения рекомендаций применяются следующие правила:

Существующие API не обязаны быть изменены, но мы рекомендуем это.
Клиенты существующих API должны справляться с этими API на основе устаревших правил.
Новые API должны соблюдать текущие рекомендации.

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

2. Принципы

2.1. Принципы проектирования API

Сравнивая стили интерфейсов веб-сервисов SOA SOAP и REST, первые, как правило, ориентированы на операции, которые обычно специфичны для конкретного случая использования и специализированы. Напротив, REST ориентирован на бизнес-сущности (данные), представленные как ресурсы, которые идентифицируются через URI и могут быть манипулированы с помощью стандартизированных CRUD-подобных методов, использующих различные представления и гипермедиа.

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

Мы предпочитаем API на основе REST с JSON-нагрузкой.
Мы предпочитаем, чтобы системы были по-настоящему RESTful [1].

Важным принципом для проектирования и использования API является Закон Постеля, также известный как Принцип Устойчивости (см. также RFC 1122):

Будь либерален в том, что принимаешь; будь консервативен в том, что отправляешь.

Рекомендации к прочтению: Несколько интересных материалов по стилю проектирования RESTful API и архитектуре сервисов:

Статья: API Design 101: Best Practices & Implementation
Статья: https://apistylebook.stoplight.io/docs/zalando-restful-api-guidelines
Книга: Irresistible APIs: Designing web APIs that developers will love
Книга: REST in Practice: Hypermedia and Systems Architecture
Книга: Build APIs You Won’t Hate
Диссертация Филдинга: Architectural Styles and the Design of Network-Based Software Architectures

2.2. API как продукт

Как упоминалось выше, Zalando превращается из интернет-магазина в обширную модную платформу, включающую богатый набор продуктов, следующих модели “Программное обеспечение как платформа” (SaaP) для наших бизнес-партнеров. Как компания, мы хотим предоставлять продукты нашим (внутренним и внешним) клиентам, которые могут использоваться как услуга.

Продукты платформы предоставляют свою функциональность через (публичные) API; следовательно, проектирование наших API должно основываться на принципе “API как продукт”:

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

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

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

Принцип “API как продукт” тесно связан с нашим принципом “API First” (см. следующую главу), который больше сосредоточен на том, как мы разрабатываем высококачественные API.

2.3. API First

Актуальность принципа “API First”:
- Принцип “API First” остается краеугольным камнем в Zalando, подчеркивая важность проектирования API до начала кодирования. Это способствует своевременному получению обратной связи, выявлению проблем на ранних этапах и формированию API, не привязанных к конкретным реализациям.
- Этот подход не противоречит принципам гибкой разработки, а, наоборот, дополняет их, обеспечивая итеративное развитие API с постоянным получением обратной связи.

Детализация “API First”:
- Определение API вне кода: API должны быть определены с использованием стандартных языков спецификации (например, OpenAPI) до реализации. Это способствует глубокому пониманию предметной области и обобщению бизнес-сущностей.
- Ранний обзор: Регулярные коллегиальные и клиентские обзоры являются обязательными для обеспечения высокого качества, согласованности дизайна и архитектуры, а также для поддержки независимой разработки клиентских приложений.
- Единый источник истины: Спецификация API служит единым источником истины, являясь критически важной частью контракта между поставщиком и потребителем сервиса.
- Инструментальная поддержка: Стандартизированные форматы спецификации облегчают создание инструментов для обнаружения API, пользовательских интерфейсов, документации и автоматических проверок качества.

3. Общие рекомендации

Принцип “API First”: `ДОЛЖЕН` следовать принципу “API First”.
Спецификация API (OpenAPI): `ДОЛЖЕН` предоставлять спецификацию API с использованием OpenAPI. `СЛЕДУЕТ` использовать OpenAPI 3.0, но поддержка OpenAPI 2.0 (Swagger 2) также допускается. Рекомендуется использовать единый YAML-файл для спецификации.
Руководство пользователя API: `СЛЕДУЕТ` предоставлять руководство пользователя API в дополнение к спецификации. Оно должно описывать область применения, примеры использования, обработку ошибок, архитектурный контекст и быть опубликовано в интернете, со ссылкой из спецификации (`#/externalDocs/url`).
Язык API: `ДОЛЖЕН` писать API на американском английском (U.S. English).
Ссылки: `ДОЛЖЕН` использовать только долговечные и неизменяемые удаленные ссылки, если не указано иное. Для ссылок на фрагменты API, контролируемые Zalando, разрешены специальные URL (`https://infrastructure-api-repository.zalandoapis.com/` и `https://opensource.zalando.com/restful-api-guidelines/{model.yaml}`).

4. Основы REST – Метаинформация

4.1. Должна содержать метаинформацию API

`ДОЛЖЕН` содержать следующую метаинформацию OpenAPI:
- `#/info/title`: уникальное, функционально-описательное имя API.
- `#/info/version`: для различия версий спецификаций API в соответствии с семантическими правилами.
- `#/info/description`: подробное описание API.
- `#/info/contact/{name,url,email}`: сведения об ответственной команде.
`ДОЛЖЕН` дополнительно предоставлять следующие свойства расширения OpenAPI:
- `#/info/x-api-id`: уникальный идентификатор API (см. правило 4.3).
- `#/info/x-audience`: предполагаемая целевая аудитория API (см. правило 4.4).

4.2. Должна использовать семантическое версионирование

`ДОЛЖЕН` соблюдать правила семантического версионирования 2.0 (правила с 1 по 8 и 11) в формате `
.
.
`.
- `MAJOR`: инкрементируется при `несовместимых` изменениях API.
- `MINOR`: инкрементируется при добавлении `обратно совместимой` функциональности.
- `PATCH`: опционально инкрементируется при `обратно совместимых` исправлениях ошибок или редакционных изменениях.
Предварительные версии (`0.y.z`) могут использоваться для начального проектирования API.

4.3. Должны предоставляться идентификаторы API

Каждая спецификация API `ДОЛЖНА` иметь глобально уникальный и неизменяемый идентификатор API в `info`-блоке OpenAPI. Рекомендуется использовать UUID (например, `d0184f38-b98d-11e7-9c56-68f728c1ba70`).
Идентификатор `ДОЛЖЕН` соответствовать шаблону `^[a-z0-9][a-z0-9-:.]{6,62}[a-z0-9]$`.

4.4. Должна быть указана аудитория API

Каждый API `ДОЛЖЕН` быть классифицирован по предполагаемой целевой аудитории. Допускаются следующие значения (`x-extensible-enum`):
- `component-internal`
- `business-unit-internal`
- `company-internal`
- `external-partner`
- `external-public`
Это определяется в `#/info/x-audience`. Меньшая группа аудитории не требует дополнительного объявления, если она включена в более широкую.

4.5. Использование функциональной схемы именования

В зависимости от аудитории API `ДОЛЖЕН`/`СЛЕДУЕТ`/`МОЖЕТ` следовать функциональной схеме именования:
- `MUST` (должен): `external-public`, `external-partner`
- `SHOULD` (следует): `company-internal`, `business-unit-internal`
- `MAY` (может): `component-internal`
Формат: ` ::= -`. Functional Name Registry `ДОЛЖЕН` использоваться для регистрации.

4.6. Должно соблюдаться соглашение об именовании хостов

Имена хостов `ДОЛЖНЫ` (или `СЛЕДУЕТ`, в зависимости от аудитории) соответствовать функциональному именованию:
- `external-public`, `external-partner`: `.zalandoapis.com`
- Устаревшие конвенции (`..zalan.do`) разрешены только для `component-internal` API.

5. Основы REST – Безопасность

5.1. Все конечные точки должны быть защищены

Каждая конечная точка API `ДОЛЖНА` быть защищена аутентификацией и авторизацией.
`ДОЛЖЕН` указывать схему безопасности (bearer или oauth2).
Для большинства внутренних API рекомендуется использовать `http` тип `Bearer Authentication` (`Authorization: Bearer `).

5.2. Разрешения (скоупы) должны быть определены и назначены

Конечные точки `ДОЛЖНЫ` быть оснащены разрешениями, если требуется авторизация клиента (например, для оранжевых/красных данных).
Для конечных точек, не требующих специальных разрешений, `ДОЛЖЕН` использовать псевдоразрешение `uid`.

5.3. Должна соблюдаться конвенция именования разрешений (скоупов)

Имена разрешений `ДОЛЖНЫ` соответствовать следующему шаблону именования:
- ``: `.` (например, `order-management.read`)
- ``: `..` (например, `order-management.sales-order.read`)
- ``: `uid`
`access-mode` включает `read` и `write`.
Эта конвенция применяется к скоупам для связи сервис-к-сервису с использованием токенов Platform IAM.

6. Основы REST – Форматы данных

6.1. Должны использоваться стандартные форматы данных

`ДОЛЖЕН` всегда использовать стандартные форматы OpenAPI, а также дополнительные форматы Zalando для электронной коммерции (например, для языковых, страновых и валютных кодов).
Таблица форматов:
- `integer`: `int32`, `int64`, `bigint`
- `number`: `float`, `double`, `decimal`
- `string`: `byte`, `binary`, `date`, `date-time`, `time`, `duration`, `period`, `password`, `email`, `idn-email`, `hostname`, `idn-hostname`, `ipv4`, `ipv6`, `uri`, `uri-reference`, `uri-template`, `iri`, `iri-reference`, `uuid`, `json-pointer`, `relative-json-pointer`, `regex`, `iso-639-1`, `bcp47`, `iso-3166-alpha-2`, `iso-4217`, `gtin-13`.

6.2. Должен быть определен формат для числовых и целочисленных типов

`ДОЛЖЕН` всегда указывать формат (`int32`, `int64`, `bigint` для `integer`; `float`, `double`, `decimal` для `number`).
Двоичные данные `ДОЛЖНЫ` быть закодированы в `base64url`.

6.3. Должны использоваться стандартные форматы для свойств даты и времени

`ДОЛЖЕН` использовать формат `string` с `date`, `date-time`, `time`, `duration` или `period`.
При создании данных `ДОЛЖЕН` использовать заглавную букву `T` как разделитель между датой и временем и заглавную `Z` в конце для обозначения UTC.
Пример: `2015-05-28T14:07:17Z`. Избегайте смещений часовых поясов, если это не требуется стандартом (например, HTTP-заголовки).

6.4. Следует выбирать подходящий формат даты или даты-времени

`date`: `СЛЕДУЕТ` использовать для свойств, где точное время не требуется (например, даты документов, дни рождения).
`date-time`: `СЛЕДУЕТ` использовать для всех остальных случаев, где требуется точная точка во времени.

6.5. Следует использовать стандартные форматы для свойств продолжительности и интервала времени

`СЛЕДУЕТ` представлять продолжительность и временные интервалы в виде строк, отформатированных согласно ISO 8601 (RFC 3339).

6.6. Должны использоваться стандартные форматы для свойств страны, языка и валюты

`Country codes`: `ISO 3166-1-alpha-2` (например, `DE`).
`Language codes`: `ISO 639-1` (например, `en`).
`Language variant tags`: `BCP 47` (например, `en-DE`).
`Currency codes`: `ISO 4217` (например, `EUR`).

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

Если API поддерживает различные представления ресурсов (JSON, PDF, TEXT, HTML), `СЛЕДУЕТ` использовать согласование контента через заголовки `Accept`, `Accept-Language`, `Accept-Encoding`.
`СЛЕДУЕТ` использовать стандартные типы мультимедиа (например, `application/json`, `application/pdf`).

6.8. Следует использовать UUID только при необходимости

UUID `СЛЕДУЕТ` использовать только при необходимости крупномасштабной генерации ID (например, в распределенных системах без координации).
Избегайте UUID в качестве первичных ключей для справочных данных или данных конфигурации с низким объемом ID.
`ДОЛЖЕН` всегда использовать строковый тип для идентификаторов.
`СЛЕДУЕТ` рассмотреть использование ULID вместо UUID для пагинации, упорядоченной по времени создания.

7. Основы REST – URL

7.1. Не следует использовать `/api` в качестве базового пути

`СЛЕДУЕТ` избегать использования `/api` в качестве базового пути. В большинстве случаев все ресурсы должны быть доступны по корневому пути `/`.
Если есть как публичные, так и внутренние API, `СЛЕДУЕТ` поддерживать две различные спецификации API и указывать соответствующую аудиторию.

7.2. Имена ресурсов должны быть во множественном числе

`ДОЛЖЕН` использовать имена ресурсов во множественном числе, так как обычно предоставляется коллекция экземпляров ресурсов.
Исключение: псевдоидентификатор `self`.

7.3. Должны использоваться URL-дружественные идентификаторы ресурсов

Идентификаторы ресурсов `ДОЛЖНЫ` соответствовать регулярному выражению `[a-zA-Z0-9:._\-/]*` (только ASCII-символы: буквы, цифры, подчеркивание, дефис, двоеточие, точка, иногда слеш).
Идентификаторы ресурсов `НЕ ДОЛЖНЫ` быть пустыми.

7.4. Сегменты пути должны использовать kebab-case

Сегменты пути `ДОЛЖНЫ` быть строками в `kebab-case` (`^[a-z][a-z\-0-9]*$`). Первый символ — строчная буква, последующие — буквы, дефисы или цифры.
Пример: `/shipment-orders/{shipment-order-id}`.

7.5. Должны использоваться нормализованные пути без пустых сегментов и конечных слешей

`ДОЛЖЕН` не указывать пути с дублирующими или конечными слешами (например, `/customers//addresses` или `/customers/`).
Сервисы `СЛЕДУЕТ` реализовать так, чтобы они были устойчивы к ненормализованным путям, нормализуя их перед обработкой.

7.6. URL-адреса должны быть без глаголов

`ДОЛЖЕН` использовать только существительные в URL-адресах, так как API описывает ресурсы, а действия выражаются HTTP-методами.
Пример: вместо `/cancel-order` используйте `POST /cancellations`.

7.7. Избегайте действий – думайте о ресурсах

`ДОЛЖЕН` моделировать API вокруг ресурсных сущностей, используя стандартные HTTP-методы в качестве индикаторов операций (CRUD-подобные операции).
Пример: для блокировки статьи используйте `PUT /article-locks/{article-id}` вместо действия `lock`.

7.8. Следует определять полезные ресурсы

`СЛЕДУЕТ` определять ресурсы, которые покрывают 90% случаев использования клиентов, содержат необходимую, но минимальную информацию.
`СЛЕДУЕТ` поддерживать фильтрацию и встраивание для расширения информации.

7.9. Должны использоваться доменные имена ресурсов

`ДОЛЖЕН` использовать доменную номенклатуру для имен ресурсов (например, `sales-order-items` вместо `order-items`). Это улучшает понимание и уменьшает необходимость в дополнительной документации.

7.10. Следует моделировать полные бизнес-процессы

API `СЛЕДУЕТ` содержать полные бизнес-процессы со всеми ресурсами, представляющими этот процесс. Это способствует согласованному проектированию и устраняет неявные зависимости между API.

7.11. Ресурсы и подресурсы должны идентифицироваться через сегменты пути

`ДОЛЖЕН` идентифицировать ресурсы и подресурсы через сегменты пути: `/resources/{resource-id}/sub-resources/{sub-resource-id}`.
Исключение: псевдоидентификатор `self`, если идентификатор ресурса передается через информацию авторизации.

7.12. Могут быть доступны составные ключи в качестве идентификаторов ресурсов

Если ресурс лучше всего идентифицируется составным ключом (например, `/shopping-carts/{country}/{session-id}`), `МОЖЕТ` использовать его в URL.
Это ограничивает возможность эволюции структуры идентификатора, поэтому API `ДОЛЖЕН` последовательно применять абстракцию составного ключа во всех параметрах запросов и ответов.

7.13. Можно рассмотреть использование (не)вложенных URL

`МОЖЕТ` использовать вложенные URL (например, `/shoping-carts/.../cart-items/1`), если подресурс доступен только через родительский ресурс.
Если ресурс имеет уникальный глобальный ID, `СЛЕДУЕТ` предоставлять его как ресурс верхнего уровня.

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

`СЛЕДУЕТ` ограничивать количество типов ресурсов, предоставляемых через один API (рекомендуется 4-8).
Ресурсный тип определяется как набор тесно связанных ресурсов (коллекция, ее члены и прямые подресурсы).

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

`СЛЕДУЕТ` использовать до 3 уровней подресурсов, чтобы избежать чрезмерной сложности API и длинных URL.

7.16. Параметры запроса должны использовать snake\_case (никогда camelCase)

`ДОЛЖЕН` использовать `snake_case` для имен параметров запроса (например, `customer_number`, `sales_order_number`).
Имена свойств `ДОЛЖНЫ` соответствовать регулярному выражению `^[a-z_][a-z_0-9]*$`.

7.17. Следует придерживаться общепринятых параметров запроса

`ДОЛЖЕН` придерживаться следующих соглашений об именовании для параметров запроса (`REST Design – Pagination`):
- `q`: общий параметр запроса.
- `sort`: список полей через запятую, с `+` (по возрастанию) или `-` (по убыванию).
- `fields`: выражение для получения подмножества полей ресурса.
- `embed`: выражение для встраивания подсущностей.
- `offset`: числовое смещение для пагинации.
- `cursor`: непрозрачный указатель для пагинации.
- `limit`: предложенный клиентом лимит на количество записей на странице.

8. Основы REST – JSON-нагрузка

8.1. JSON должен использоваться как формат обмена данными нагрузки

`ДОЛЖЕН` использовать JSON (RFC 7159) для представления структурированных данных.
JSON-нагрузка `ДОЛЖНА` использовать JSON-объект в качестве структуры данных верхнего уровня.
`ДОЛЖЕН` также соответствовать RFC 7493 (UTF-8, действительные Unicode-строки, уникальные имена членов).

8.2. Следует проектировать единую схему ресурсов для чтения и записи

`СЛЕДУЕТ` использовать общую модель для чтения и записи одного и того же типа ресурса.
Различия `СЛЕДУЕТ` учитывать с помощью `writeOnly` (только для запроса) и `readOnly` (только для ответа).

8.3. Следует учитывать сервисы, не полностью поддерживающие JSON/Unicode

Серверы и клиенты, перенаправляющие JSON-содержимое на другие инструменты, `СЛЕДУЕТ` проверять полную поддержку JSON или Unicode. Если нет, `СЛЕДУЕТ` отклонять или санировать неподдерживаемые символы.

8.4. Может передавать не-JSON типы носителей с использованием специфичных для данных стандартных форматов

`МОЖЕТ` поддерживать не-JSON типы носителей, если используются специфичные для бизнес-объектов стандартные форматы (например, изображения, документы, архивы).
Общие форматы, кроме JSON (XML, CSV), `МОГУТ` предоставляться только дополнительно к JSON в качестве формата по умолчанию с использованием согласования контента.

8.5. Следует использовать стандартные типы носителей

`СЛЕДУЕТ` использовать стандартные типы носителей IANA (например, `application/json`, `application/problem+json`).
Избегайте пользовательских типов (`application/x.zalando.article+json`). Исключение: версионирование конечных точек API.

8.6. Имена массивов должны быть во множественном числе

`СЛЕДУЕТ` использовать имена массивов во множественном числе (например, `items`), а имена объектов — в единственном (например, `item`).

8.7. Имена свойств должны быть camelCase (не snake_case)

ИЗМЕНЕНИЕ ОТ ОРИГИНАЛЬНОГО РУКОВОДСТВА: В отличие от исходного руководства, которое предписывало `snake_case`, данное обновленное руководство `РЕКОМЕНДУЕТ` использовать **camelCase для имен свойств в JSON-нагрузке. Это соответствует большинству современных гайдлайнов по проектированию API (например, Google, Microsoft, AWS) и более гармонично сочетается с распространенными языками программирования (Java, JavaScript, C#), где `camelCase` является стандартной конвенцией для имен переменных и полей.
- Пример: `customerNumber`, `salesOrderNumber`, `billingAddress`.
Обоснование изменения:** Хотя `snake_case` был принят некоторыми крупными компаниями, `camelCase` имеет более широкое распространение и лучшую интеграцию с современными инструментами и библиотеками, что упрощает разработку и поддержку клиентских приложений. `camelCase` также способствует более естественному чтению JSON-нагрузки в коде, написанном на большинстве объектно-ориентированных и скриптовых языков.
Исключение:** Для параметров запроса и заголовков HTTP `ДОЛЖЕН` по-прежнему использовать `snake_case` и `kebab-case` соответственно, как указано в соответствующих разделах.

8.8. Следует объявлять значения перечислений с использованием формата строки UPPER_SNAKE_CASE

`СЛЕДУЕТ` использовать `UPPER_SNAKE_CASE` для значений перечислений (например, `VALUE`, `YET_ANOTHER_VALUE`).
Исключение: чувствительные к регистру значения из внешних источников (например, коды языков ISO 639-1) или значения `sort`
параметра.

8.9. Следует использовать соглашение об именовании для свойств даты/времени

Имена свойств даты и времени `СЛЕДУЕТ` заканчивать на `_at` или содержать `date`, `time`, `timestamp`.
Примеры: `created_at`, `modified_at`, `arrival_date`, `campaign_start_time`.

8.10. Следует определять карты с использованием additionalProperties

`СЛЕДУЕТ` представлять карты (отображения строковых ключей на другие типы) с использованием `additionalProperties` в схеме OpenAPI.
Пример: `translations` в объекте сообщения.

8.11. Должна использоваться одинаковая семантика для ‘null’ и отсутствующих свойств

Если свойство может быть `null` или отсутствовать, `ДОЛЖЕН` обрабатывать обе ситуации одинаково.
Это позволяет избежать ошибок из-за тонких различий в семантике, которые могут быть неправильно интерпретированы клиентами.
Исключение: `JSON Merge Patch` (RFC 7396) использует `null` для удаления свойства.

8.12. Не рекомендуется использовать ‘null’ для булевых свойств

`НЕ РЕКОМЕНДУЕТСЯ` использовать `null` для булевых свойств. Если `null` имеет смысл, `СЛЕДУЕТ` использовать перечисление (например, `YES`, `NO`, `UNDEFINED`).

8.13. Не рекомендуется использовать ‘null’ для пустых массивов

`НЕ РЕКОМЕНДУЕТСЯ` использовать `null` для пустых массивов. Используйте пустой список `[]`.

8.14. Должны использоваться общие имена полей и семантика

`ДОЛЖЕН` использовать общие имена полей и семантику:
- `id`: идентификатор объекта (строка, непрозрачная, уникальна в контексте).
- `xyz_id`: идентификатор другого объекта (например, `partner_id`).
- `etag`: ETag для оптимистической блокировки.
Примеры: `created_at`, `modified_at`, `parent_node_id`.

8.15. Должны использоваться общие поля адреса

`ДОЛЖЕН` использовать стандартные имена и семантику для всех атрибутов, относящихся к информации об адресе (например, `addressee`, `address` с полями `street`, `city`, `zip`, `country_code`).

8.16. Должен использоваться общий денежный объект

`ДОЛЖЕН` использовать следующую общую структуру для денежных объектов:
```yaml
Money:
type: object
properties:
amount:
type: number
format: decimal
currency:
type: string
format: iso-4217
required:
- amount
- currency
```
`ДОЛЖЕН` рассматривать `Money` как закрытый тип данных, предпочитая композицию наследованию.
`ДОЛЖЕН` обеспечивать высокую точность (`decimal`) и не использовать `float` или `double` для расчетов.

9. Основы REST – HTTP-запросы

9.1. HTTP-методы должны использоваться правильно

`ДОЛЖЕН` соблюдать стандартизированную HTTP-семантику (RFC-9110 “HTTP Semantics”).

GET:
- `ДОЛЖЕН` использоваться для чтения одиночного или коллективного ресурса.
- Возвращает 404, если ресурс не существует (для одиночных).
- Возвращает 200 (коллекция пуста) или 404 (коллекция отсутствует) для коллекций.
- `НЕ ДОЛЖЕН` иметь тела запроса.
- GET с телом запроса**: Если требуется передача сложной структурированной информации с `GET`, а использование query-параметров невозможно (из-за ограничений на размер), `СЛЕДУЕТ` использовать `POST` с телом запроса и явно документировать это.
  - `НЕ ДОЛЖЕН` использовать заголовки для передачи сложной структурированной информации из-за ненадежных ограничений на размер.

PUT:
- `ДОЛЖЕН` использоваться для полного обновления (и иногда создания) ресурсов (одиночных или коллективных).
- Семантика: “пожалуйста, поместите приложенное представление по URI, заменяя любой существующий ресурс”.
- Обычно применяется к одиночным ресурсам.
- Как правило, `УСТОЙЧИВ` к отсутствию ресурсов, неявно создавая их перед обновлением.
- При успешном выполнении сервер `ЗАМЕНЯЕТ` весь ресурс.
- Успешные `PUT` запросы возвращают 200 или 204 (без возврата ресурса), 201 (если ресурс был создан), 202 (если запрос принят для асинхронной обработки).
- `СЛЕДУЕТ` отдавать предпочтение `POST` для создания (как минимум ресурсов верхнего уровня), а `PUT` — для обновлений. Если идентификатор ресурса полностью контролируется клиентом, `МОЖЕТ` использовать `PUT` для создания, передавая идентификатор в качестве параметра пути.
- Повторное выполнение `PUT` *должно быть* идемпотентно.

POST:
- Обычно**: `ДОЛЖЕН` использоваться для создания одиночных ресурсов на конечной точке коллекции (`add the enclosed representation to the collection resource`).
- Редко**: `МОЖЕТ` использоваться для выполнения хорошо специфицированного запроса на одиночном ресурсе (`execute the given well specified request on the resource identified by the URL`).
- successful `POST` на коллекции создает один или несколько экземпляров ресурсов.
- Для одиночных ресурсов `СЛЕДУЕТ` возвращать 201 и новый объект ресурса (включая идентификатор).
- URL для получения ресурса `СЛЕДУЕТ` предоставлять в заголовке `Location`.
- Идентификатор ресурса `НЕ ДОЛЖЕН` передаваться клиентом в теле запроса, а `ДОЛЖЕН` создаваться и поддерживаться сервисом.
- Для нескольких ресурсов `СЛЕДУЕТ` возвращать 201, если они создаются атомарно.
- `ДОЛЖЕН` использовать код 207 для пакетных или массовых запросов, если запрос может частично завершиться неудачей.
- Повторное выполнение `POST` *не обязательно* является идемпотентным, но `СЛЕДУЕТ` `РАССМОТРЕТЬ` проектирование его как идемпотентного.
- `МОЖЕТ` поддерживать асинхронную обработку запросов (статус 202).

PATCH:
- `ДОЛЖЕН` использоваться для частичного обновления объектов ресурсов.
- Тело запроса `ДОЛЖНО` содержать документ исправления (patch document) с определенным типом носителя.
- Успешные `PATCH` возвращают 200, 204 или 202.
- `СЛЕДУЕТ` выбирать один из следующих шаблонов (порядок предпочтения):
  1. `PUT` с полными объектами.
  2. `PATCH` с `JSON Merge Patch` (`application/merge-patch+json`).
  3. `PATCH` с `JSON Patch` (`application/json-patch+json`).
  4. `POST` (с явным описанием).
- Повторное выполнение `PATCH` *не обязательно* является идемпотентным, но `СЛЕДУЕТ` `РАССМОТРЕТЬ` проектирование его как идемпотентного.

DELETE:
- `ДОЛЖЕН` использоваться для удаления ресурсов.
- Обычно применяется к одиночным ресурсам.
- `МОЖЕТ` применяться к нескольким ресурсам одновременно с использованием параметров запроса.
- Успешные `DELETE` возвращают 200, 204 или 202.
- Неуспешные `DELETE` возвращают 404 (не найден) или 410 (уже удален).
- После `DELETE` `GET` на ресурс `ДОЛЖЕН` возвращать 404 или 410.
- DELETE с query-параметрами**: `МОЖЕТ` иметь query-параметры в качестве фильтров.
- DELETE с телом запроса**: Если требуется дополнительная информация, не являющаяся фильтрами, `РЕКОМЕНДУЕТСЯ` использовать `POST`, так как семантика `DELETE` с телом не определена RFC-9110.

HEAD:
- `ДОЛЖЕН` использоваться для получения информации заголовка для одиночных ресурсов и коллекций.
- Имеет ту же семантику, что и `GET`, но возвращает только заголовки, без тела.

OPTIONS:
- `МОЖЕТ` использоваться для проверки доступных операций (HTTP-методов) для данной конечной точки.
- Ответы `OPTIONS` обычно возвращают список методов в заголовке `Allow`.

9.2. Должны выполняться общие свойства методов

Реализации методов `ДОЛЖНЫ` соответствовать следующим свойствам согласно RFC 9110 Section 9.2:
- `Safe`: `GET`, `HEAD`, `OPTIONS`, `TRACE`
- `Idempotent`: `GET`, `HEAD`, `PUT`, `DELETE`, `OPTIONS`, `TRACE` (для `POST`/`PATCH` `СЛЕДУЕТ` рассмотреть идемпотентность)
- `Cacheable`: `GET`, `HEAD` (для `POST` `МОЖЕТ` быть, но редко поддерживается)

9.3. Следует рассмотреть проектирование POST и PATCH как идемпотентных операций

`СЛЕДУЕТ` рассмотреть проектирование `POST` и `PATCH` как идемпотентных, чтобы предотвратить дублирование ресурсов или потерю обновлений.
Применяемые шаблоны:
- Conditional key (условный ключ):** через заголовок `If-Match` (например, для `ETag`). Предотвращает дублирование и потерю обновлений.
- Secondary key (вторичный ключ):** через свойство ресурса в теле запроса. Хранится постоянно в ресурсе, обеспечивает идемпотентность при создании (избегает дубликатов).
- Idempotency-Key header:** клиентский ключ через заголовок `Idempotency-Key` (временный). Обеспечивает точно такой же ответ для повторных запросов.
Пример использования вторичного ключа: `shopping cart ID` в ресурсе заказа.

9.4. Следует использовать вторичный ключ для идемпотентного проектирования POST

`СЛЕДУЕТ` использовать вторичный ключ, предоставляемый в теле запроса, для идемпотентного создания `POST`, чтобы избежать дублирования ресурсов.
Вторичный ключ хранится постоянно в ресурсе как альтернативный или комбинированный ключ, защищенный ограничением уникальности.

9.5. Может поддерживать асинхронную обработку запросов

`МОЖЕТ` использовать асинхронную обработку для долгих запросов.
`РЕКОМЕНДУЕТСЯ` представлять асинхронную обработку через ресурс “job” со статусом (например, `POST /report-jobs` возвращает 201 с `job-id` и URL в `Location`).
Если нет отдельного ресурса “job”, `МОЖЕТ` использовать 202 с заголовком `Location`, указывающим на отчет.
`НЕ ДОЛЖЕН` использовать 204 или 404 вместо 202.

9.6. Формат коллекции заголовков и параметров запроса должен быть определен

`ДОЛЖЕН` явно определить формат коллекции (либо список через запятую, либо повторение параметра) в спецификации OpenAPI, так как OpenAPI не поддерживает оба варианта одновременно.
Для заголовков: `style: simple, explode: false` (не разрешено).
Для запросов: `style: form, explode: false` или `style: form, explode: true`.

9.7. Следует проектировать простые языки запросов с использованием параметров запроса

`СЛЕДУЕТ` использовать параметры запроса для простых языков запросов, так как это нативно для HTTP, легко расширяемо и хорошо поддерживается.
Для API, используемых внешними командами, `СЛЕДУЕТ` использовать простые языки запросов. Для внутренних или специфичных случаев `МОЖЕТ` использовать более сложные.
Примеры: `name=Zalando`, `color=red,green`, `limit=5`, `created_after=2019-07-17`.

9.8. Следует проектировать сложные языки запросов с использованием JSON

Для сложных языков запросов (например, для поиска, каталогов продуктов) с большим количеством фильтров, динамическими фильтрами или сложными операторами (`and`, `or`, `not`), `СЛЕДУЕТ` использовать вложенные JSON-структуры.
Пример: JSON-документ для сложного запроса с `and` и `or`.
Подразумевает использование шаблона `GET` с телом запроса.

9.9. Должна быть документирована неявная фильтрация ответов

Если в коллекции ресурсов или запросах применяется неявная фильтрация (например, по авторизации пользователя), `ДОЛЖЕН` документировать это в описании конечной точки в спецификации API.
Пример: `GET /business-partners` возвращает только партнеров, доступных текущему пользователю.

10. Основы REST – Коды состояния HTTP

10.1. Должны использоваться официальные коды состояния HTTP

`ДОЛЖЕН` использовать только официальные коды состояния HTTP (из RFC и IANA Status Code Registry) и в соответствии с их семантикой.
Избегайте неофициальных кодов (например, от Nginx).

10.2. Должны быть указаны успешные и ошибочные ответы

`ДОЛЖЕН` определить все успешные и специфичные для сервиса ошибочные ответы в спецификации API.
Описания ошибок `ДОЛЖНЫ` предоставлять информацию об условиях, приведших к ошибке.
Исключение: стандартные клиентские и серверные ошибки (401, 403, 404, 500, 503) не требуют индивидуального определения, если их семантика очевидна.

10.3. Следует использовать только наиболее распространенные коды состояния HTTP

`СЛЕДУЕТ` использовать только наиболее распространенные и понятные коды (200, 201, 202, 204, 207, 304, 400, 401, 404, 405, 406, 409, 412, 415, 428, 429, 500, 501, 502, 503, 504).
Избегайте менее распространенных кодов (`205`, `206`, `301`, `302`, `303`, `307`, `308`, `408`, `410`, `411`, `417`, `418`, `422`, `423`, `424`, `431`, `505`, `507`, `511`), если они не имеют четкой, специфичной для API семантики.
Коды, которые не возвращаются API, `НЕ ДОЛЖНЫ` документироваться.

10.4. Должны использоваться наиболее специфичные коды состояния HTTP

`ДОЛЖЕН` использовать наиболее специфичные коды состояния HTTP при возврате информации о статусе обработки запроса или ошибках.

10.5. Должен использоваться код 207 для пакетных или массовых запросов

`ДОЛЖЕН` использовать 207 (Multi-Status) для пакетных или массовых запросов, если могут быть частичные неудачи или требуется информация о статусе для каждого элемента.
Ответ с 207 `ДОЛЖЕН` содержать `multi-status response` в теле, включающий `id`, `status` и `description` для каждого элемента.

10.6. Должен использоваться код 429 с заголовками для ограничения скорости

`ДОЛЖЕН` использовать 429 (Too Many Requests) при превышении лимита запросов.
`ДОЛЖЕН` включать заголовки `Retry-After` (с задержкой в секундах) или `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset` (время в секундах до сброса).

10.7. Должна поддерживаться проблема JSON

`ДОЛЖЕН` поддерживать `Problem JSON` (RFC 9457, `application/problem+json`) для предоставления расширяемой информации об ошибках.
Каждая конечная точка `ДОЛЖНА` быть способна возвращать `Problem JSON` для ошибок 4xx и 5xx.
Клиенты `ДОЛЖНЫ` быть устойчивы и не зависеть от возврата `Problem JSON`.
`МОЖЕТ` определять пользовательские типы проблем для более подробной информации об ошибках.
Идентификаторы типов и экземпляров проблем `НЕ ПРЕДНАЗНАЧЕНЫ` для разрешения (`URI references`), но `МОГУТ` указывать на документацию.

10.8. Не должны раскрываться трассировки стека

`НЕ ДОЛЖЕН` раскрывать трассировки стека в ответах, так как они содержат детали реализации, утечки конфиденциальной информации и информацию об уязвимостях.

10.9. Не следует использовать коды перенаправления

`НЕ СЛЕДУЕТ` использовать коды перенаправления (кроме 304). Перенаправление трафика `ЛУЧШЕ` выполнять на уровне API (например, через обратный прокси) без участия клиента.
Для идемпотентных `POST` запросов, где ресурс уже существует, `СЛЕДУЕТ` возвращать 200 с заголовком `Location`.
Для неидемпотентных `POST` запросов, где ресурс не может быть создан повторно, `СЛЕДУЕТ` возвращать 409.

11. Основы REST – HTTP-заголовки

11.1. Использование стандартных определений заголовков

`СЛЕДУЕТ` использовать стандартные определения HTTP-заголовков из руководства для упрощения API.
Пример: `parameters` или `headers` в `components`.

11.2. Могут использоваться стандартные заголовки

API `МОГУТ` использовать HTTP-заголовки, определенные не устаревшими RFC. Поддерживаемые заголовки `ДОЛЖНЫ` быть явно упомянуты в спецификации API.

11.3. Следует использовать kebab-case с прописными буквами для HTTP заголовков

`СЛЕДУЕТ` использовать `kebab-case` с прописными буквами для первых букв каждого слова (например, `If-Modified-Since`, `Accept-Encoding`, `Content-ID`).
Исключение: общепринятые сокращения, такие как `ID`.
Заголовки HTTP нечувствительны к регистру, но это для согласованности.

11.4. Заголовки `Content-*` должны использоваться правильно

`ДОЛЖЕН` правильно использовать заголовки `Content-*`, которые описывают содержимое тела сообщения и могут использоваться как в запросах, так и в ответах.
Примеры: `Content-Disposition`, `Content-Encoding`, `Content-Length`, `Content-Language`, `Content-Location`, `Content-Range`, `Content-Type`.

11.5. Следует использовать заголовок `Location` вместо `Content-Location`

`СЛЕДУЕТ` использовать заголовок `Location` вместо `Content-Location` для указания местоположения ресурса в ответах на создание или перенаправление.
Это позволяет избежать сложностей и двусмысленности, связанных с `Content-Location`.

11.6. Может использоваться заголовок `Content-Location`

`МОЖЕТ` использовать `Content-Location` в успешных операциях записи (`PUT`, `POST`, `PATCH`) и чтения (`GET`, `HEAD`) для управления кэшированием или указания фактического местоположения переданного ресурса.
При использовании `Content-Location` `Content-Type` `ДОЛЖЕН` быть также установлен.

11.7. Может рассматриваться поддержка заголовка Prefer для управления предпочтениями обработки

`МОЖЕТ` рассматривать поддержку заголовка `Prefer` (RFC 7240), который позволяет клиентам запрашивать желаемое поведение обработки с сервера (например, `respond-async`, `return=minimal`, `return=total-count`, `wait`, `handling=strict`).
Поддержка `Prefer` является опциональной и `РЕКОМЕНДУЕТСЯ` по сравнению с проприетарными заголовками `X-`.

11.8. Может рассматриваться поддержка ETag вместе с заголовками If-Match / If-None-Match

`МОЖЕТ` рассматривать поддержку заголовка `ETag` вместе с `If-Match` и `If-None-Match` для обнаружения конфликтов при конкурентных операциях обновления (`PUT`, `POST`, `PATCH`).
`If-Match`: для проверки, соответствует ли версия обновляемой сущности запрошенному `ETag`. Если нет, возвращает 412.
`If-None-Match`: для обнаружения конфликтов при создании ресурсов. Если найдена соответствующая сущность, возвращает 412.

11.9. Может рассматриваться поддержка заголовка Idempotency-Key

`МОЖЕТ` рассматривать поддержку заголовка `Idempotency-Key` для обеспечения строгой идемпотентности (одинаковые ответы для повторных запросов) при создании или обновлении ресурсов.
Клиент предоставляет уникальный ключ запроса, который временно хранится на сервере вместе с ответом.
Ключи `ДОЛЖНЫ` иметь достаточную энтропию (например, UUID v4). Истекают через 24 часа.

11.10. Следует использовать только указанные проприетарные Zalando заголовки

`СЛЕДУЕТ` избегать проприетарных HTTP-заголовков, но `МОЖЕТ` использовать разрешенные Zalando проприетарные заголовки для передачи общей, неспецифичной для бизнеса контекстной информации (например, `X-Flow-ID`, `X-Tenant-ID`, `X-Sales-Channel`, `X-Frontend-Type`, `X-Device-Type`, `X-Device-OS`, `X-Mobile-Advertising-ID`).
Имена `ДОЛЖНЫ` начинаться с `X-` и использовать `dash-case`.
Исключение: `X-RateLimit-*` заголовки.

11.11. Проприетарные заголовки должны распространяться

Все проприетарные заголовки Zalando, определенные в 11.10, `ДОЛЖНЫ` распространяться по всей цепочке вызовов (end-to-end) без изменений.
Значения `МОГУТ` влиять на результаты запросов.

11.12. Должен поддерживаться X-Flow-ID

`ДОЛЖЕН` поддерживать `X-Flow-ID` в запросах RESTful API и поле `flow_id` в событиях.
`X-Flow-ID` — это общий параметр для отслеживания потоков вызовов через систему и корреляции действий сервисов.
Допустимые форматы: UUID (RFC-4122), base64 (RFC-4648), base64url (RFC-4648 Section 5), случайная строка (ASCII, макс. 128 символов).
Сервисы `ДОЛЖНЫ` создавать новый `Flow-ID`, если он не предоставлен.
Сервисы `ДОЛЖНЫ` распространять `Flow-ID` (передавать во все дальнейшие вызовы API и события, записывать в логи).

12. Проектирование REST – Гипермедиа

12.1. Должен использоваться уровень зрелости REST 2

`ДОЛЖЕН` стремиться к хорошей реализации уровня зрелости REST 2 (использование HTTP-глаголов и кодов состояния).
Это означает: `ДОЛЖЕН` избегать действий в URL, `ДОЛЖЕН` оставлять URL без глаголов, `ДОЛЖЕН` правильно использовать HTTP-методы, `СЛЕДУЕТ` использовать только наиболее распространенные коды состояния HTTP.

12.2. Может использоваться уровень зрелости REST 3 – HATEOAS

`НЕ РЕКОМЕНДУЕТСЯ` реализовывать уровень зрелости REST 3 (HATEOAS) в общем случае, так как он добавляет сложность без явной ценности в контексте SOA Zalando.
Основные опасения: HATEOAS не добавляет ценности для самоописания API в условиях API First; общие клиенты HATEOAS не работают на практике в SOA; спецификации OpenAPI не поддерживают HATEOAS в достаточной мере.
`МОЖЕТ` использовать HATEOAS только в случае, если выявлена явная ценность, оправдывающая дополнительную сложность.

12.3. Должны использоваться общие элементы управления гипертекстом

При встраивании ссылок на другие ресурсы в представления `ДОЛЖЕН` использовать общий объект `hypertext control`.
Объект `ДОЛЖЕН` содержать как минимум атрибут `href`: URI ресурса, на который указывает ссылка (только HTTP(s)).
Имя атрибута, содержащего `HttpLink` объект, `ДОЛЖНО` указывать на связь между ссылающимся и ссылаемым ресурсами.
`СЛЕДУЕТ` использовать имена из IANA Link Relation Registry. Дефисы в IANA-именах `ДОЛЖНЫ` быть заменены на подчеркивания (`snake_case`).

12.4. Следует использовать простые элементы управления гипертекстом для пагинации и само-ссылок

Для пагинации и само-ссылок `СЛЕДУЕТ` использовать упрощенную форму расширяемых общих гипертекстовых элементов управления, состоящую из простого URI-значения в сочетании с соответствующими отношениями ссылок (например, `next`, `prev`, `first`, `last`, `self`).

12.5. Для идентификации ресурсов должен использоваться полный, абсолютный URI

Ссылки на другие ресурсы `ДОЛЖНЫ` всегда использовать полный, абсолютный URI.
Это снижает сложность на стороне клиента и избегает двусмысленности с базовыми URI.

12.6. Не следует использовать заголовки ссылок с JSON-сущностями

`НЕ ДОЛЖЕН` использовать заголовки `Link` (RFC 8288) в сочетании с JSON-носителями. Ссылки `ПРЕДПОЧТИТЕЛЬНЕЕ` встраивать непосредственно в JSON-нагрузку.

13. Проектирование REST – Производительность

13.1. Следует снижать потребность в пропускной способности и улучшать отзывчивость

API `СЛЕДУЕТ` поддерживать методы для снижения пропускной способности и ускорения ответа, особенно для мобильных клиентов.
Общие методы: gzip-сжатие, фильтрация полей, ETag (для условных запросов), заголовок `Prefer`, пагинация, кэширование мастер-данных.

13.2. Следует использовать gzip-сжатие

Серверы и клиенты `СЛЕДУЕТ` поддерживать кодирование содержимого `gzip` для уменьшения передаваемых данных и ускорения ответа.
Серверы `ДОЛЖНЫ` также поддерживать несжатый контент для тестирования.
Спецификация API `СЛЕДУЕТ` определять `Accept-Encoding` и `Content-Encoding`.

13.3. Следует поддерживать частичные ответы через фильтрацию

`СЛЕДУЕТ` поддерживать фильтрацию возвращаемых полей сущностей с помощью параметра запроса `fields`.
Пример: `GET http://api.example.org/users/123?fields=(name,friends(name))`
OpenAPI не поддерживает формальное описание различных схем, поэтому `СЛЕДУЕТ` документировать это в описании конечной точки.

13.4. Следует разрешать опциональное встраивание подресурсов

`СЛЕДУЕТ` разрешать встраивание связанных ресурсов (расширение ресурсов) для уменьшения количества запросов, используя параметр запроса `embed`.
Пример: `GET /order/123?embed=(items)`.

13.5. Должны быть документированы кэшируемые конечные точки GET, HEAD и POST

Кэширование на стороне клиента и прозрачное веб-кэширование `СЛЕДУЕТ` избегать, если только сервис не требует его для самозащиты.
По умолчанию, серверы и клиенты `ДОЛЖНЫ` устанавливать `Cache-Control: no-store`.
Если кэширование требуется, `ДОЛЖЕН` документировать все кэшируемые конечные точки `GET`, `HEAD` и `POST` путем объявления поддержки заголовков `Cache-Control`, `Vary` и `ETag` в ответе.
`Default Cache-Control`: `private`, `must-revalidate`, `max-age`.
`Default Vary`: `accept`, `accept-encoding`.
`РЕКОМЕНДУЕТСЯ` прикреплять кэш непосредственно к сервисной (или шлюзовой) слою приложения.

14. Проектирование REST – Пагинация

14.1. Должна поддерживаться пагинация

`ДОЛЖНА` поддерживаться пагинация для доступа к спискам данных, чтобы защитить сервис от перегрузки и поддержать итерацию на стороне клиента.
`ДОЛЖЕН` придерживаться общих имен параметров запроса (`offset`, `cursor`, `limit`).

14.2. Следует предпочитать пагинацию на основе курсоров, избегать пагинации на основе смещения

`СЛЕДУЕТ` предпочитать пагинацию на основе курсоров из-за ее эффективности, особенно для больших объемов данных и NoSQL-баз данных.
Курсор `ДОЛЖЕН` быть непрозрачной строкой для клиентов, шифрующей (или кодирующей) позицию страницы, направление и примененные фильтры запроса.

14.3. Следует использовать объект страницы ответа пагинации

`СЛЕДУЕТ` использовать объект страницы ответа с полями `self`, `first`, `prev`, `next`, `last` (`uri|cursor`).
`ДОЛЖЕН` включать поле `items` для содержимого страницы.
`МОЖЕТ` включать поле `query` для примененных фильтров запроса, если используется `GET` с телом.

14.4. Следует использовать ссылки пагинации

`СЛЕДУЕТ` поддерживать упрощенные гипертекстовые элементы управления в качестве стандартных ссылок пагинации (полные URL с параметрами).
Пример: `{“self”: “https://my-service.zalandoapis.com/resources?cursor=”, ...}`.

14.5. Следует избегать общего количества результатов

`СЛЕДУЕТ` избегать предоставления общего количества результатов в ответах пагинации, так как его расчет является дорогостоящей операцией.
Если клиент действительно требует общее количество результатов, `МОЖЕТ` поддерживать это требование через заголовок `Prefer` с директивой `return=total-count`.

15. Проектирование REST – Совместимость

15.1. Обратная совместимость не должна нарушаться

`ДОЛЖЕН` изменять API, сохраняя при этом работоспособность всех потребителей. API — это контракты, которые не могут быть нарушены в одностороннем порядке.
Используйте совместимые расширения или новые версии API с поддержкой старых.

15.2. Следует предпочитать совместимые расширения

`СЛЕДУЕТ` применять следующие правила:
- Добавлять только опциональные, никогда не обязательные поля.
- Никогда не изменять семантику полей.
- Никогда не делать логику валидации более строгой.
- Диапазоны перечислений (`enum`) могут быть уменьшены для входных параметров, если сервер поддерживает старые значения. Для выходных параметров `НЕ МОГУТ` быть расширены.
- `СЛЕДУЕТ` использовать `x-extensible-enum` для перечислений, которые будут расширяться.

15.3. Следует проектировать API консервативно

Разработчики `СЛЕДУЕТ` быть консервативными и точными в том, что они принимают от клиентов:
- Неизвестные входные поля `НЕ СЛЕДУЕТ` игнорировать; серверы `СЛЕДУЕТ` возвращать 400.
- `ДОЛЖЕН` быть точными в определении ограничений входных данных и возвращать специальные ошибки при их нарушении.
- `ПРЕДПОЧТИТЕЛЬНО` быть более специфичным и ограничительным.

15.4. Клиенты должны быть готовы принимать совместимые расширения API

Клиенты сервисов `ДОЛЖНЫ` применять принцип устойчивости:
- Быть консервативными с запросами API и входными данными.
- Быть толерантными при обработке и чтении данных ответов API: игнорировать новые поля в полезной нагрузке, не удалять их для последующих `PUT` запросов.
- Быть готовыми к тому, что `x-extensible-enum` параметры могут возвращать новые значения; быть агностиками или предоставлять поведение по умолчанию для неизвестных значений.
- Быть готовыми обрабатывать коды состояния HTTP, явно не указанные в определениях конечных точек.
- Следовать перенаправлениям (301).

15.5. Спецификация OpenAPI должна по умолчанию рассматриваться как открытая для расширения

`ДОЛЖЕН` рассматривать определения объектов OpenAPI как открытые для расширения по умолчанию (как в JSON-Schema 5.18 `additionalProperties`).
Клиенты `НЕ ДОЛЖНЫ` предполагать, что объекты закрыты для расширения без `additionalProperties` и `ДОЛЖНЫ` игнорировать неизвестные поля.
Серверы, получающие неожиданные данные, `СЛЕДУЕТ` отклонять запросы с неопределенными полями, чтобы сигнализировать клиентам, что эти поля не будут сохранены.
Форматы API `НЕ ДОЛЖНЫ` объявлять `additionalProperties` как `false`.

15.6. Следует избегать версионирования

`СЛЕДУЕТ` избегать создания дополнительных версий API.
Если изменение API несовместимо, `СЛЕДУЕТ` создать новый ресурс (вариант), новый сервис или новую версию API.
Настоятельно `РЕКОМЕНДУЕТСЯ` использовать первые два подхода.

15.7. Должно использоваться версионирование типа носителя

Если версионирование API неизбежно, `ДОЛЖЕН` использовать версионирование типа носителя (`media type versioning`, например, `application/x.zalando.cart+json;version=2`).
Это менее тесно связано и поддерживает согласование контента.
Версионирование применяется только к схеме полезной нагрузки, а не к URI или семантике метода.
`СЛЕДУЕТ` включать `Content-Type` в заголовок `Vary`.

15.8. Не следует использовать версионирование URL

`НЕ ДОЛЖЕН` использовать версионирование URL (например, `/v1/customers`). Это приводит к более тесной связи и усложняет управление релизами. Вместо этого `ДОЛЖЕН` использовать версионирование типа носителя.

15.9. Всегда должны возвращаться JSON-объекты как структуры данных верхнего уровня

`ДОЛЖЕН` всегда возвращать JSON-объект (а не массив) в качестве структуры данных верхнего уровня в теле ответа, чтобы обеспечить будущую расширяемость.
Карты (`additionalProperties`), хотя и являются технически объектами, также `ЗАПРЕЩЕНЫ` как структуры верхнего уровня, поскольку они не поддерживают совместимые будущие расширения.

15.10. Следует использовать открытый список значений (x-extensible-enum) для типов перечислений

`СЛЕДУЕТ` использовать `x-extensible-enum` для перечислений, которые, вероятно, будут расширяться.
Это позволяет избежать проблем совместимости, присущих `enum` JSON-схемы (которые по определению являются закрытым набором значений).
Клиенты `ДОЛЖНЫ` быть готовы к расширениям перечислений и реализовать запасное/поведение по умолчанию для неизвестных значений.

16. Проектирование REST – Устаревшая функциональность

16.1. Устаревшая функциональность должна быть отражена в спецификациях API

`ДОЛЖЕН` установить `deprecated: true` для устаревших элементов (конечная точка, параметр, объект схемы, свойство схемы).
Если планируется отключение, `ДОЛЖЕН` указать дату `sunset` и документировать альтернативы.

16.2. Должно быть получено одобрение клиентов перед отключением API

`ДОЛЖЕН` убедиться, что все клиенты дали согласие на дату `sunset` перед отключением API, его версии или функции.
`СЛЕДУЕТ` помогать клиентам с миграцией, предоставляя руководства.

16.3. Должно быть собрано согласие внешних партнеров на срок устаревания

Если API используется внешними партнерами, владелец API `ДОЛЖЕН` определить разумный срок поддержки API после объявления об устаревании.
Все внешние партнеры `ДОЛЖНЫ` выразить согласие с этим сроком.

16.4. Использование устаревшего API, запланированного к выводу из эксплуатации, должно отслеживаться

Владельцы API `ДОЛЖНЫ` отслеживать использование API, запланированных к выводу из эксплуатации, для мониторинга прогресса миграции и избежания неконтролируемых сбоев.

16.5. Следует добавлять заголовки Deprecation и Sunset к ответам

В течение фазы устаревания `СЛЕДУЕТ` добавлять заголовки `Deprecation: ` (или `true`) и `Sunset: ` к каждому ответу, затронутому устаревшим элементом.
Это информирует клиентов о предстоящих изменениях.
Пример: `Deprecation: Tue, 31 Dec 2024 23:59:59 GMT`, `Sunset: Wed, 31 Dec 2025 23:59:59 GMT`.

16.6. Следует добавлять мониторинг для заголовков Deprecation и Sunset

Клиенты `СЛЕДУЕТ` отслеживать эти заголовки и создавать оповещения для планирования миграционных задач.

16.7. Не следует начинать использовать устаревшие API

Клиенты `НЕ ДОЛЖНЫ` начинать использовать устаревшие API, версии API или функции API.

17. Операции REST

17.1. Спецификация OpenAPI должна быть опубликована для не-компонентных внутренних API

Все сервисные приложения `ДОЛЖНЫ` публиковать спецификации OpenAPI своих внешних API.
Публикация происходит путем копирования спецификации OpenAPI в зарезервированный каталог `/zalando-apis` артефакта развертывания.
Это обеспечивает обнаружаемость API через API Portal Zalando.

17.2. Следует отслеживать использование API

Владельцы API `СЛЕДУЕТ` отслеживать использование API в продакшене для получения информации о клиентах.
Идентификация клиентов `СЛЕДУЕТ` осуществляться путем логирования `client-id` из токена OAuth.

18. Основы Событий – Типы Событий

18.1. События должны быть определены в соответствии с общими рекомендациями API

События `ДОЛЖНЫ` быть согласованы с другими данными API и общими рекомендациями API (насколько это применимо).
Большинство разделов руководства (Общие рекомендации, Основы REST – Форматы данных, Основы REST – JSON-нагрузка, Проектирование REST – Гипермедиа) применимы к обмену данными событий.

18.2. События должны рассматриваться как часть интерфейса сервиса

События являются частью интерфейса сервиса с внешним миром, эквивалентной по значимости REST API сервиса.
Сервисы, публикующие данные, `ДОЛЖНЫ` относиться к своим событиям как к первоочередной задаче проектирования (принцип “API First”).

18.3. Схема события должна быть доступна для просмотра

Сервисы, публикующие данные событий, `ДОЛЖНЫ` предоставить схему события, а также определение типа события для просмотра.

18.4. События должны быть специфицированы и зарегистрированы как типы событий

В архитектуре Zalando события регистрируются с использованием структуры, называемой `Event Type`.
`Event Type` `ДОЛЖЕН` определять: категорию (общая, изменение данных), имя, аудиторию, владеющее приложение, схему полезной нагрузки, режим совместимости.
Пример объекта `EventType` на основе OpenAPI представлен в исходном документе.

18.5. Должно соблюдаться соглашение об именовании типов событий

Имена типов событий `ДОЛЖНЫ` (или `СЛЕДУЕТ`, в зависимости от аудитории) соответствовать функциональному именованию:
- ` ::= .[.]`
- Примеры: `transactions-order.order-cancelled`, `customer-personal-data.email-changed.v2`.
`СЛЕДУЕТ` использовать согласованное именование, если одна и та же сущность представлена как событием изменения данных, так и RESTful API.

18.6. Должно быть указано владение типами событий

Определения событий `ДОЛЖНЫ` иметь явное владение, указываемое через поле `owning_application` в `EventType`.

18.7. Режим совместимости должен быть тщательно определен

Владельцы типов событий `ДОЛЖНЫ` уделять внимание выбору режима совместимости в `EventType` (`compatible`, `forward`, `none`).
`none`: любые изменения схемы разрешены.
`forward`: пользователи могут читать события с последней версией схемы, используя предыдущую версию.
`compatible`: изменения должны быть полностью совместимы (только добавление новых опциональных свойств, запрещены другие изменения).

18.8. Схема события должна соответствовать объекту схемы OpenAPI

`ДОЛЖЕН` использовать `Schema Object` из OpenAPI Specification для определения схем событий.
`НЕ ДОЛЖЕН` использовать запрещенные ключевые слова `JSON Schema` (`additionalItems`, `contains`, `patternProperties`, `dependencies`, `propertyNames`, `const`, `not`, `oneOf`).
`Schema Object` изменяет `additionalProperties` и добавляет `readOnly`, `discriminator`.

18.9. Следует избегать additionalProperties в схемах типов событий

`СЛЕДУЕТ` избегать использования `additionalProperties` в схемах типов событий, чтобы поддерживать эволюцию схемы и обратную совместимость.
Публиканты, стремящиеся обеспечить совместимость, `ДОЛЖНЫ` определять новые опциональные поля и обновлять свои схемы заранее.
Потребители `ДОЛЖНЫ` игнорировать поля, которые они не могут обработать.

18.10. Должно использоваться семантическое версионирование схем типов событий

Схемы событий `ДОЛЖНЫ` версионироваться аналогично REST API (`MAJOR.MINOR.PATCH`).
Изменения в `compatible` или `forward` режиме приводят к `PATCH` или `MINOR` ревизии (major changes не разрешены).
Изменения в `none` режиме могут привести к `PATCH`, `MINOR` или `MAJOR` изменениям.

19. Основы Событий – Категории Событий

19.1. Должно быть обеспечено соответствие событий категории событий

`ДОЛЖЕН` обеспечить, чтобы события соответствовали предопределенной структуре категории (например, `GeneralEvent` или `DataChangeEvent`).
`GeneralEvent`: общая категория, с полем `metadata`.
`DataChangeEvent`: для изменений сущностей, с полями `metadata`, `data_op`, `data_type`, `data`.

19.2. Должны предоставляться обязательные метаданные события

`ДОЛЖЕН` предоставлять `eid` (идентификатор события) и `occurred_at` (технический временной штамп создания события производителем) в метаданных события.
Другие поля (`received_at`, `version`, `parent_eids`, `flow_id`, `partition`) могут быть обогащены посредниками.

19.3. Должны предоставляться уникальные идентификаторы событий

`ДОЛЖЕН` предоставлять `eid` как уникальный идентификатор для события в пределах его типа/потока.
Производители `ДОЛЖНЫ` использовать тот же `eid` при повторной публикации того же объекта события.
`eid` поддерживает потребителей событий в обнаружении и устойчивости к дубликатам.

19.4. Общие события должны использоваться для сигнализации шагов в бизнес-процессах

При публикации событий, представляющих шаги в бизнес-процессе, типы событий `ДОЛЖНЫ` основываться на категории `General Event`.
`ДОЛЖЕН` содержать специфический идентификатор процесса (bp-id) и средства для корректного упорядочивания.
`ДОЛЖЕН` публиковать событие надежно.

19.5. Следует обеспечивать явный порядок событий для общих событий

`СЛЕДУЕТ` предоставлять явную информацию о деловом порядке событий для общих событий.
`ДОЛЖЕН` указывать свойство `ordering_key_fields` и `СЛЕДУЕТ` `ordering_instance_ids` в определении типа события.
Строго монотонно возрастающие версии сущностей или последовательные счетчики `МОГУТ` использоваться для упорядочивания.

19.6. События изменения данных должны использоваться для сигнализации мутаций

`ДОЛЖЕН` использовать события изменения данных для сигнализации изменений экземпляров сущностей и содействия захвату измененных данных (CDC).
События `ДОЛЖНЫ` предоставлять полные данные сущности, включая идентификатор измененного экземпляра.
`ДОЛЖЕН` обеспечивать явный порядок событий для событий изменения данных.
`ДОЛЖЕН` публиковать события надежно.

19.7. Должен быть обеспечен явный порядок событий для событий изменения данных

`ДОЛЖЕН` предоставлять информацию об упорядочивании для событий изменения данных, так как она критически важна для поддержания синхронизации транзакционных наборов данных (CDC).
Эта информация определяет порядок создания, обновления и удаления экземпляров данных.
Исключение: если транзакционные данные только добавляются (append only).

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

`СЛЕДУЕТ` использовать стратегию хэш-секционирования для событий изменения данных.
Это позволяет всем связанным событиям для сущности быть последовательно назначенными одному разделу, обеспечивая относительно упорядоченный поток событий для этой сущности.
Ключ секционирования `ПОЧТИ ВСЕГДА` `ДОЛЖЕН` представлять изменяемую сущность.

20. Проектирование Событий

20.1. Следует избегать записи конфиденциальных данных в событиях

`СЛЕДУЕТ` избегать записи конфиденциальных данных (например, персональных данных) в событиях, если это не требуется для бизнеса.
Конфиденциальные данные создают дополнительные обязательства по контролю доступа и соответствию нормативным требованиям, увеличивая риски защиты данных.

20.2. Должна быть устойчивость к дубликатам при потреблении событий

Потребители событий `ДОЛЖНЫ` быть устойчивы к дубликатам событий (несколько вхождений одного и того же объекта события).
Устойчивость может включать дедупликацию, основанную на `eid` и информации об упорядочивании изменения данных (CDC).
Источники дубликатов: повторные попытки публикации, сбои, “at-least-once” доставка.

20.3. Следует проектировать для идемпотентной обработки вне порядка

События, разработанные для идемпотентной обработки вне порядка, `СЛЕДУЕТ` проектировать так, чтобы они содержали достаточно информации для восстановления их исходного порядка или чтобы порядок становился неактуальным.
Это позволяет пропускать, задерживать или повторять обработку событий без порчи результата.

20.4. Должно быть обеспечено определение полезных бизнес-ресурсов событиями

События `ДОЛЖНЫ` определять полезные бизнес-ресурсы, основанные на предметной области сервиса и ее естественном жизненном цикле.
`СЛЕДУЕТ` определять типы событий, достаточно абстрактные/общие, чтобы быть ценными для нескольких сценариев использования.

20.5. Следует обеспечивать соответствие событий изменения данных ресурсам API

Представление сущности в событии изменения данных `СЛЕДУЕТ` соответствовать представлению в REST API.
Это уменьшает количество публикуемых структур и упрощает поддержку API.
Исключения: сильно отличающиеся представления от хранилища данных, агрегированные данные, результаты вычислений.

20.6. Должна поддерживаться обратная совместимость для событий

Изменения в событиях `ДОЛЖНЫ` быть основаны на аддитивных и обратно совместимых изменениях.
Обратно совместимые изменения: добавление опциональных полей, изменение порядка полей, удаление опциональных полей, удаление значений из перечисления, добавление новых значений в `x-extensible-enum`.
Обратно несовместимые изменения: удаление обязательных полей, изменение значений по умолчанию, изменение типов полей, добавление значений в обычное перечисление.

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

Приложение A: Ссылки
Приложение B: Инструментарий
Приложение C: Лучшие практики
Приложение D: Журнал изменений (текущий Changelog из оригинального документа)

Итог:

В ходе данного анализа и обновления “Zalando RESTful API and Event Guidelines” была проведена систематическая работа по пересмотру и улучшению исходного документа. Основные цели заключались в устранении двусмысленностей, обеспечении соответствия современным тенденциям в проектировании API и повышении общей читаемости и применимости руководства.

Ключевым изменением, отражающим современные практики и обеспечивающим лучшую совместимость с широко используемыми языками программирования и инструментами, стало `РЕКОМЕНДАЦИЯ` использования `camelCase` для имен свойств в JSON-нагрузке, вместо ранее предписанного `snake_case`. Это решение было тщательно обосновано с учетом удобства разработки и консистентности с глобальными стандартами. Хотя это отступление от одной из конкретных конвенций исходного документа, оно полностью соответствует его духу “API как продукта” и направлено на улучшение опыта разработчиков.

Кроме того, были уточнены и усилены правила, касающиеся:

HTTP-статусов: Более детальный и выборочный подход к использованию HTTP-кодов, отдавая предпочтение наиболее распространенным и понятным.
Идемпотентности: Расширенное рассмотрение различных подходов к обеспечению идемпотентности для `POST` и `PATCH` операций, включая заголовки `Idempotency-Key`.
Безопасности: Четкие указания по работе со скоупами и защите конечных точек.
Версионирования: Подтверждение предпочтения версионирования через `media type` и категорический отказ от версионирования URL.
Обработки ошибок: Настоятельная рекомендация использовать `Problem JSON` (RFC 9457) для стандартизированного и расширяемого представления ошибок.
Событий: Дополнительные пояснения и уточнения по проектированию, совместимости и структуре типов событий, а также по обработке дубликатов.

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

И еще немного про безопасность в масштабе

Fri, 29 Aug 2025 00:02:28 +0300

Ranger vs. OPA: Битва архитектур... и почему OPAL меняет правила игры

● Ranger has a fixed development model
● To add new systems you need to write new modules,
compile and roll out Ranger
● OPA is all REST
● Basically everything is configuration
● We can build the 80% abstraction layer easily
● Anybody else -> they can build whatever extra they need -> in config!

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

У Ranger фиксированная модель разработки. Чтобы добавить поддержку новых систем, нужно писать новые модули. [...] OPA полностью построен на REST. По сути, всё является конфигурацией. [...] Мы можем создать 80% абстракции, а остальные сами допишут всё, что нужно, через конфиг!

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

Давайте рассмотрим все три компонента по порядку.

1. “Классический” подход: Apache Ranger

Apache Ranger — это зрелая и мощная система для централизованного управления политиками безопасности в экосистеме больших данных (Hadoop, Hive, Kafka и т.д.).

Как это работает: Ranger работает по принципу “сервер + плагины”. Центральный сервер хранит все политики доступа. В каждую защищаемую систему (например, в Hive) устанавливается специальный плагин, который периодически опрашивает сервер Ranger, скачивает актуальные политики и кэширует их для быстрой проверки доступа.

Сильные стороны:
- Централизация: Единый центр для аудита и управления доступом.
- Мощность: Глубокая интеграция с поддерживаемыми системами (например, безопасность на уровне колонок в Hive).

Слабые стороны (те самые “фиксированные модели разработки”):
- Негибкость: Поддержка новой системы, не входящей в стандартный набор, требует написания плагина на Java, компиляции и развертывания новой версии Ranger. Это медленно и требует узкой экспертизы.
- “Бутылочное горлышко”: Все изменения проходят через центральную команду, что замедляет продуктовые команды.
- Не для микросервисов: Этот подход плохо подходит для динамичного мира микросервисов, где новые сервисы появляются каждый день.

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

2. “Гибкий” подход: Open Policy Agent (OPA)

OPA — это универсальный движок политик с открытым исходным кодом. Его философия прямо противоположна Ranger. OPA ничего не знает о тех, кого он защищает.

Как это работает:
1. Ваш сервис, получив запрос, формирует JSON-документ с контекстом (`{“user”: “alice”, “action”: “read”, “resource”: “document”}`).
2. Он отправляет этот JSON в OPA через простой REST API-вызов.
3. OPA применяет к этому JSON’у правила, написанные на языке Rego, и мгновенно возвращает решение: `allow` или `deny`.

Сильные стороны:
- Универсальность: OPA может управлять доступом к чему угодно — микросервисам, Kubernetes, конвейерам CI/CD, базам данных.
- Policy-as-Code: Политики на Rego — это код. Их можно хранить в Git, версионировать, тестировать и автоматически развертывать.
- Децентрализация: OPA обычно развертывается как “сайдкар”-контейнер рядом с каждым экземпляром сервиса, что обеспечивает низкую задержку и высокую отказоустойчивость.

Проблема, которую OPA создает:
Представьте, у вас 500 микросервисов, и рядом с каждым работает свой экземпляр OPA. Возникают вопросы:

Как доставить обновление политики во все 500 экземпляров OPA одновременно?
Откуда OPA возьмет данные для принятия решений (например, список ролей пользователя или владельцев документа)? Если каждый из 500 экземпляров OPA будет сам ходить в базу данных, это создаст колоссальную нагрузку.

Здесь на сцену выходит OPAL.

3. “Связующее звено”: OPAL (Open Policy Administration Layer)

OPAL — это не еще один движок политик. Это административный слой реального времени для OPA. Его единственная задача — поддерживать политики и данные в ваших OPA-агентах в актуальном состоянии.

Как это работает (OPA + OPAL):**
1. Политики (Rego-файлы) хранятся в Git-репозитории. Данные (роли, атрибуты) — в базах данных или API.
2. OPAL Server подписывается на изменения в этих источниках (например, через веб-хуки из Git или топики Kafka).
3. Когда происходит изменение (например, разработчик пушит новую политику в Git), OPAL Server получает уведомление.
4. Сервер немедленно публикует сообщение об обновлении в легковесный канал (pub/sub, обычно через WebSockets).
5. OPAL Clients, работающие рядом с каждым OPA, получают это сообщение.
6. Клиенты сами скачивают нужные обновления (новую политику из Git, свежие данные из БД) и загружают их в свой локальный OPA.

Что это дает:
- Обновления в реальном времени: Изменение политики в Git моментально распространяется по всей системе.
- Событийная архитектура: Нет необходимости постоянно опрашивать источники. Это очень эффективно.
- Полное разделение: OPA отвечает только за принятие решений. OPAL — за доставку “знаний” для этих решений.
- Масштабируемость: Эта архитектура легко управляет тысячами OPA-агентов, решая проблему синхронизации.
- Завершение истории GitOps: Вы управляете доступом ко всей вашей инфраструктуре через `git push`, что полностью соответствует исходному тезису: “всё является конфигурацией”. medium.com

Итоговое сравнение

Критерий	Apache Ranger	OPA (самостоятельно)	OPA + OPAL (Современный стек)
Архитектура	Монолитный сервер + плагины	Децентрализованный движок политик	Децентрализованный движок + слой управления реального времени
Процесс обновления	Код -> Компиляция -> Развертывание	Ручная загрузка политик через API	`git push` -> Автоматическое распространение
Гибкость	Низкая (только для поддерживаемых систем)	Очень высокая (универсальный)	Очень высокая + управляемость в масштабе
Управление данными	Встроено	Требует самостоятельного решения	Встроено в архитектуру (OPAL следит за данными)
Масштабируемость	Масштабируется, но обновления медленные	Плохо масштабируется с точки зрения управления	Отлично масштабируется
Подход	Классический, централизованный	`Policy-as-Code`, но неполный	`Policy-as-Code` + `GitOps`, событийно-ориентированный

Вывод

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

Ranger — это мощный, но неповоротливый инструмент из прошлого, идеальный для статичных, гомогенных сред.
OPA — это гениально простой и гибкий движок, сердце современной авторизации.
OPAL — это нервная система, которая соединяет это сердце с “мозгом” (Git, базы данных) и позволяет всему организму (вашим микросервисам) реагировать на изменения мгновенно.

Современный, масштабируемый и по-настоящему гибкий “слой абстракции”, о котором говорилось в начале, строится именно на связке OPA + OPAL. Это позволяет создавать платформу, ценность которой, как и было сказано, “заключается в способности объединять внешние инструменты, команды, данные и процессы”.

Еще было это: https://gavrilov.info/all/evolyuciya-upravleniya-dostupom-opa-opal-vs-fga-rbac-rebac/

Платформа

Thu, 28 Aug 2025 23:44:51 +0300

Оригинал:

A platform is a set of software and a surrounding ecosystem of resources that helps you to grow your business. A platform enables growth through connection: its value comes not only from its own features, but from its ability to connect external tools, teams, data, and processes.

Перевод:

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

Дополнение с учетом современных трендов и опыта

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

Вот несколько ключевых аспектов, дополняющих это определение:

Платформа как основа бизнес-стратегии.
Современные лидеры рынка рассматривают платформы не как набор инструментов, а как основу для полного переосмысления своего бизнеса. Платформенный подход позволяет заново выстроить всю цепочку поставок, клиентский путь и процессы принятия решений. Это критический компонент «цифрового ядра» компании, стремящейся к постоянному обновлению и росту accenture.com https://www.accenture.com/us-en/insights/strategy/platform-strategy.

Ценность требует инвестиций и настройки.
Платформа сама по себе не является готовым решением. Она требует значительных инвестиций в настройку и интеграцию для того, чтобы начать генерировать ценность. Как отмечает Forrester, пустой аккаунт в `Amazon Web Services` (AWS) бесполезен до тех пор, пока вы не установите и не настроите на нём программное обеспечение и не окружите его дополнительными возможностями forrester.com https://www.forrester.com/blogs/a-simple-definition-of-platform.

Переход от монолита к экосистеме.
Эпоха единых монолитных IT-приложений, которые должны были решать все задачи бизнеса, подходит к концу. Современная парадигма — это создание гибкой архитектуры, в которой решения от разных поставщиков могут быть бесшовно развёрнуты и интегрированы. Такие «инновационные платформы» позволяют компаниям быстро адаптироваться к изменениям и использовать лучшие в своём классе инструменты для каждой функции cimdata.com https://www.cimdata.com/en/platformization-some-common-definitions.

Драйвер новых бизнес-моделей и конкурентного преимущества.
Платформенные бизнес-модели — это проверенный способ достижения успеха. Они позволяют технологическим компаниям монетизировать свои продукты через модели `as-a-service` (по подписке или на основе потребления), повышать лояльность клиентов за счёт связанных сервисов и масштабироваться гораздо быстрее. Для 80% компаний, ещё не перешедших на платформенную модель, главным вызовом становится растущая конкуренция со стороны тех, кто уже сделал этот шаг ey.com https://www.ey.com/en_nz/insights/technology/how-can-your-platform-business-model-fuel-competitiveness-and-growth.

Создание сетевого эффекта.
Ключевая особенность успешной платформы — способность создавать сетевой эффект. Чем больше пользователей, разработчиков, партнёров и сервисов подключается к платформе, тем выше становится её ценность для каждого участника. Примерами могут служить операционные системы (`Windows`, `macOS`), платформы для разработки (`Java`), браузеры (`Chrome`) или социальные сети, где ценность напрямую зависит от количества и активности пользователей и создателей контента appmarketplace.com https://appmarketplace.com/blog/what-is-a-platform.

Итоговое современное определение можно сформулировать так:

Платформа — это стратегический бизнес-актив, представляющий собой гибкую и масштабируемую технологическую основу, которая объединяет внутренние и внешние ресурсы (инструменты, данные, команды, партнёров) в единую экосистему. Её главная цель — не просто предоставлять функции, а стимулировать рост, инновации и создание сетевых эффектов, позволяя компании переосмысливать бизнес-модели и получать устойчивое конкурентное преимущество.

Руководство по REST-каталогам для Trino и Iceberg

Wed, 13 Aug 2025 00:31:21 +0300

https://docs.lakekeeper.io – картинка как у меня не грузится сайт лейкипера. https://github.com/lakekeeper/lakekeeper/issues/1119

В мире современных озер данных (Data Lakehouse) связка Trino и Apache Iceberg стала синонимом производительности и гибкости. Но чтобы эта связка работала по-настоящему эффективно, необходим центральный элемент — каталог метаданных. И если раньше выбор был ограничен Hive Metastore или JDBC, то сегодня стандарт де-факто — это REST Catalog API.

REST-каталог — это не просто технология, это идеология. Он отделяет движок запросов от хранилища метаданных, позволяя десяткам инструментов (Trino, Spark, Flink, dbt) работать с данными через единый, универсальный и не зависящий от вендора интерфейс.

Это руководство — погружение во все доступные на рынке REST-каталоги ( почти все ). Мы оценим их готовность к продакшену в Kubernetes, уникальные преимущества и то, как они вписываются в современный стек данных.

Почему REST-каталог — это новый стандарт?

Централизация и универсальность: Один каталог для всех. Trino, Spark и Flink видят одно и то же состояние данных. Атомарные коммиты для нескольких таблиц и серверное разрешение конфликтов становятся возможными.
Гибкость развертывания: REST-сервис — это независимый, stateless-компонент, идеально подходящий для Kubernetes. Его можно легко развернуть, масштабировать и обновлять.
Безопасность на уровне каталога: Вы можете централизованно управлять доступом, использовать OAuth2 и даже выдавать временные учетные данные для доступа к S3, не прописывая секреты в каждом движке.
Поддержка всех функций Iceberg: REST API спроектирован для поддержки самых передовых возможностей Iceberg, которые не всегда доступны в старых типах каталогов.

Обзор и рейтинг REST-каталогов: Битва титанов

Рассмотрим ключевых игроков, их сильные стороны и готовность к бою в продуктивной среде.

1. Project Nessie: Git для ваших данных

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

Ключевые преимущества:
- Git-like операции: Создавайте изолированные ветки для экспериментов (`dev`, `feature-branch`) и сливайте их в основную (`main`) атомарно. Идеально для CI/CD пайплайнов данных.
- Декларативные транзакции: Гарантирует консистентность при одновременных операциях с несколькими таблицами.
- Экосистема: Отличная документация, интеграция с dbt и инструменты для миграции с Hive Metastore.
Готовность к Kubernetes: Высокая. Nessie имеет официальный Helm chart, что значительно упрощает развертывание и управление в K8s. Требует отдельного процесса для сборки мусора (Garbage Collection).
Кому подходит: Командам, которые хотят внедрить DevOps-практики (DataOps) в работу с данными, обеспечивая изоляцию, воспроизводимость и безопасные обновления.
GitHub: projectnessie/nessie

2. Apache Gravitino (Incubating): Универсальный федеративный мета-каталог

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

Ключевые преимущества:
- Федерация: Может выступать прокси для существующих каталогов (Hive, JDBC, REST), объединяя их под единым API.
- Каскадные запросы в Trino: Позволяет одному кластеру Trino запрашивать данные из каталогов другого кластера Trino.
- Широчайшая экосистема: Поддерживает не только Iceberg, но и реляционные СУБД, ClickHouse, и даже каталог для Kafka, позволяя управлять топиками. Есть планы по управлению метаданными ИИ/ML моделей.
- Безопасность: Поддерживает OAuth2 и Kerberos для бэкенда Hive.
Готовность к Kubernetes: Средняя. Проект активно развивается, но требует внимательной конфигурации. Необходимо учитывать требования к версиям Trino (например, 435-439 для некоторых функций).
Кому подходит: Крупным организациям со сложной, гетерогенной средой, которые стремятся унифицировать управление метаданными из разных источников (Data Lake, DWH, Streaming).
GitHub: apache/gravitino

3. Apache Amoro (Incubating, ранее Arctic): Самооптимизирующийся каталог

Amoro фокусируется на решении одной из главных проблем озер данных — оптимизации хранения.

Ключевые преимущества:
- Автоматическая оптимизация: Встроенные механизмы для `compaction` (объединение мелких файлов) и `clustering` для поддержания высокой производительности запросов без ручного вмешательства.
- Поддержка смешанных форматов: Может управлять не только Iceberg, но и Paimon (Flink), а также таблицами смешанного формата.
- Экосистема: Есть интеграция с ClickHouse, Flink, Spark и Trino. Предлагается облачная версия Arctic Cloud.
Готовность к Kubernetes: Высокая. Проект нацелен на облачные развертывания и предоставляет инструменты для автоматизации обслуживания.
Кому подходит: Компаниям с высоконагруженными озерами данных (high-throughput data lakes), где постоянно идет запись данных, и требуется автоматическое поддержание производительности.
Сайт: ((https://amoro.apache.org/ amoro.apache.org)

4. Lakekeeper: Крепость безопасности на Rust

Lakekeeper — это новый игрок, написанный на Rust, с абсолютным фокусом на безопасности, управлении доступом и интеграции с облаками.

Ключевые преимущества:
- Безопасность во главе угла: Использует Vended-Credentials для безопасного доступа к S3, интегрируется с OpenID для аутентификации и OpenFGA для детальной авторизации (Fine Grained Access).
- Нативен для Kubernetes: Развертывается через Helm chart, может аутентифицировать сервисные аккаунты Kubernetes. Оператор в разработке.
- Событийная архитектура: Генерирует события об изменениях (CloudEvents) в Kafka или NATS, что позволяет строить реактивные пайплайны.
- Data Contracts: Может проверять изменения по внешним системам контрактов данных, чтобы предотвратить нарушение схем.
- Легковесность: Единый бинарный файл без зависимостей от JVM или Python.
Готовность к Kubernetes: Очень высокая. Это, возможно, самый “Kubernetes-native” каталог из всех, созданный с нуля для облачных сред.
Кому подходит: Организациям, для которых безопасность, управление доступом и аудит являются главным приоритетом. Идеален для мульти-облачных и мульти-тенантных сред.
GitHub: lakekeeper/lakekeeper

5. Denali: Минималистичная “зверюга” на Go

Denali от Bodo.ai — это антитеза сложным enterprise-системам. Его философия — максимальная простота и производительность.

Ключевые преимущества:
- Экстремальная легковесность: Написан на Go, менее 5000 строк кода, развертывается как один бинарный файл на ~20MB.
- Простота развертывания: Минимальные зависимости (бэкендом может быть SQLite или PostgreSQL). Идеален для быстрых тестов и легковесных продакшен-сред.
- Высокая производительность: Отсутствие оверхеда JVM и компилируемая природа Go.
Готовность к Kubernetes: Высокая. Благодаря своей простоте и отсутствию состояния, Denali легко упаковывается в контейнер и управляется в Kubernetes.
Кому подходит: Командам, которые ценят простоту, производительность и полный контроль над инфраструктурой. Отличный выбор для стартапов и проектов, где не нужна сложная федерация или enterprise-функции.
GitHub: [Bodo-inc/denali](https://github.com/Bodo-inc/denali)

6. Tabular: Управляемый сервис от создателей Iceberg

Tabular — это не open-source проект, а полностью управляемый SaaS-продукт от сооснователей Apache Iceberg.

Ключевые преимущества:
- Нулевое администрирование: Вы просто получаете эндпоинт REST-каталога и используете его. Вся инфраструктура, обновления и безопасность — на стороне Tabular.
- Надежность и поддержка: Коммерческая поддержка от экспертов, которые создали Iceberg.
- Интеграции: Глубокая интеграция с dbt, Confluent/Kafka.
Готовность к Kubernetes: Неприменимо. Это SaaS-решение, вы не развертываете его самостоятельно.
Кому подходит: Компаниям любого размера, которые хотят сфокусироваться на аналитике, а не на управлении инфраструктурой.

Другие важные игроки

Apache Polaris (Incubating): Официальная реализация REST-каталога от Apache. Цель — стать эталонной. Имеет роли, неймспейсы и документацию для продакшена, но пока менее зрелый, чем конкуренты. [polaris.apache.org](https://polaris.apache.org/)
Databricks Unity Catalog: Мощнейший каталог, но тесно интегрированный в экосистему Databricks. Поддерживает REST API и уникальную технологию Delta Sharing для безопасного обмена данными. “Модный, молодежный” выбор для тех, кто уже живет в мире Databricks.

Сводная таблица

Каталог	Стек	Ключевое преимущество	Готовность к PROD в K8s	Лучше всего для...
:---	:---	:---	:---	:---
Project Nessie	Java	Git-версионирование данных	✅ Высокая (Helm Chart)	Команд, внедряющих DataOps и CI/CD для данных.
Apache Gravitino	Java	Федерация и универсальность (ClickHouse, Kafka)	✅ Средняя (требует настройки)	Сложных гетерогенных enterprise-сред.
Apache Amoro	Java	Автоматическая оптимизация	✅ Высокая	Высоконагруженных озер данных с постоянной записью.
Lakekeeper	Rust	Безопасность и Governance (Vended Credentials)	✅✅ Очень высокая (Native K8s)	Компаний с высокими требованиями к безопасности.
Denali	Go	Простота и производительность	✅ Высокая (легковесный контейнер)	Гибких команд, ценящих минимализм и скорость.
Tabular	SaaS	Нулевое администрирование	N/A (SaaS)	Всех, кто хочет готовое решение “под ключ”.
Apache Polaris	---	---	---	---
Databricks Unity Catalog	---	---	---	---

Пример конфигурации Trino

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

# etc/catalog/my_iceberg_catalog.properties
connector.name=iceberg
iceberg.catalog.type=rest
# URI вашего REST-сервиса
iceberg.rest-catalog.uri=http://lakekeeper-service.default.svc.cluster.local:8181/catalog
# Путь к хранилищу по умолчанию
iceberg.rest-catalog.warehouse=s3://my-warehouse/
# Настройки безопасности (пример для OAuth2)
iceberg.rest-catalog.security=OAUTH2
iceberg.rest-catalog.oauth2.token=<your-token>

Заключение: Как сделать правильный выбор?

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

🥇 Для Enterprise с фокусом на безопасность и Kubernetes: Lakekeeper — очевидный лидер благодаря нативным K8s-интеграциям и мощным функциям безопасности.
🥈 Для сложных сред и федерации: Apache Gravitino предлагает уникальные возможности по объединению разрозненных источников метаданных.
🥉 Для чистого DataOps: Project Nessie остается лучшим в своем классе для реализации Git-подобных рабочих процессов.
🚀 Для быстрого старта и простоты: Denali позволяет запустить производительный каталог с минимальными усилиями.
💸 Когда время дороже денег: Tabular снимает всю головную боль по администрированию.

Эпоха привязки к одному инструменту прошла, поэтому ждем Cedrus Catalog с батарейками и свистелками 🤪REST-каталоги дают свободу, а Trino, и не только — возможность этой свободой воспользоваться. Выбирайте оружие по своей задаче и стройте по-настоящему открытый и мощный Data Lakehouse 🏡

ps: Конечно печатала ИИ, может не очень объективно давать оценки, но список хороший. Я ей помогал, как мог.

Ссылки:
https://github.com/projectnessie/nessie – https://projectnessie.org
https://github.com/apache/gravitino – https://gravitino.apache.org
https://github.com/apache/amoro – https://amoro.apache.org
https://github.com/lakekeeper/lakekeeper – https://docs.lakekeeper.io
https://github.com/apache/polaris – https://polaris.apache.org
https://github.com/unitycatalog/unitycatalog – https://unitycatalog.io

Экосистема инструментов для Data Science и AI: От Дашбордов до Продвинутого MLOps

Sun, 10 Aug 2025 23:40:36 +0300

Все это можно быстро и просто запустить тут: https://www.ploomber.io

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

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

Категория 1: Фреймворки для создания веб-приложений и дашбордов

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

Streamlit

GitHub Stars: 40.8k+
Официальный сайт: streamlit.io
GitHub Repo: streamlit

Описание и назначение: Streamlit — это, возможно, самый популярный фреймворк для быстрого создания data-приложений. Его философия — превратить скрипты в красивые веб-интерфейсы с минимальными усилиями. Приложение работает по простой модели: скрипт выполняется сверху вниз при каждом взаимодействии пользователя, что упрощает управление состоянием.

Особенности и оценка:

Сильные стороны: Невероятная простота и скорость разработки. Идеально подходит для создания прототипов, демо и внутренних инструментов medium.com. Отличная документация и большое сообщество.
Слабые стороны: Модель “перезапуска всего скрипта” может быть неэффективной для сложных приложений с большим количеством состояний. Кастомизация интерфейса за пределами стандартных компонентов может быть сложной задачей ai.gopubby.com.

Dash

GitHub Stars: 23.9k+
Официальный сайт: plotly.com/dash
GitHub Repo: github.com/plotly/dash

Описание и назначение: Dash от создателей Plotly — это мощный фреймворк для создания аналитических веб-приложений. Он использует Flask, Plotly.js и React.js под капотом, предоставляя Python-разработчикам доступ к современным веб-технологиям.

Особенности и оценка:

Сильные стороны: Высокая степень кастомизации и контроля. Идеален для корпоративных дашбордов и сложных приложений, требующих уникального дизайна и функциональности. Отличная интеграция с экосистемой Plotly.
Слабые стороны: Более высокий порог вхождения по сравнению со Streamlit. Концепция “коллбэков” требует времени для освоения.

Solara

GitHub Stars: 2.1k+
Официальный сайт: solara.dev
GitHub Repo: github.com/widgetti/solara

Описание и назначение: Solara позволяет создавать веб-приложения на чистом Python, используя компонентный подход, похожий на React. Он построен на базе Ipywidgets и может работать как в Jupyter Notebook, так и в виде самостоятельных приложений.

Особенности и оценка:

Сильные стороны: Компонентная архитектура способствует созданию чистого и переиспользуемого кода. Хорошо подходит для создания масштабируемых приложений корпоративного уровня ai.gopubby.com.
Слабые стороны: Менее известен, чем Streamlit или Dash, что означает меньшее сообщество и меньше готовых решений.

Gradio

GitHub Stars: 39.4k+
Официальный сайт: gradio.app
GitHub Repo: github.com/gradio-app/gradio

Описание и назначение: Gradio создан для невероятно быстрого создания демо для моделей машинного обучения. Всего за несколько строк кода можно обернуть любую Python-функцию (например, предсказание модели) в простой веб-интерфейс.

Особенности и оценка:

Сильные стороны: Максимальная простота для демонстрации моделей. Поддерживает различные типы ввода/вывода (текст, изображения, аудио). Легко встраивается в Jupyter/Colab и генерирует публичные ссылки для демонстрации.
Слабые стороны: Не предназначен для создания сложных, многостраничных дашбордов. Фокус смещен на “вход -> модель -> выход”. Структура приложения `app.py` часто используется для бэкенда при создании мультимодальных инструментов ai.plainenglish.io.

Shiny for Python & Shiny Express

GitHub Stars: 1.6k+ (Python)
Официальный сайт: shiny.posit.co/py
GitHub Repo: github.com/posit-dev/py-shiny

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

Особенности и оценка:

Сильные стороны: Мощная реактивная модель позволяет создавать очень эффективные приложения. Отличная интеграция с инструментами от Posit (ранее RStudio).
Слабые стороны: Сообщество в Python пока меньше, чем у аналогов. Реактивная модель требует особого подхода к мышлению.

Panel

GitHub Stars: 5.4k+
Официальный сайт: panel.holoviz.org
GitHub Repo: github.com/holoviz/panel

Описание и назначение: Panel — это мощный фреймворк из экосистемы HoloViz. Его главная особенность — совместимость практически с любой библиотекой для визуализации в Python. Он позволяет объединять виджеты и графики в гибкие макеты.

Особенности и оценка:

Сильные стороны: Непревзойденная гибкость и совместимость с другими библиотеками. Отлично подходит, если вы уже используете инструменты HoloViz (hvPlot, HoloViews).
Слабые стороны: Может показаться более многословным и сложным для простых задач по сравнению со Streamlit.

Другие интересные фреймворки UI

Chainlit (10k+ звезд): Специализированный фреймворк для быстрого создания чат-интерфейсов для LLM-агентов и приложений на базе LangChain/LlamaIndex.
Hyperdiv (900+ звезд): Предлагает новый подход: Python-код выполняется на сервере и мгновенно синхронизирует UI в браузере. Компоненты объявляются в простом, декларативном стиле.
Vizro (3k+ звезд): Конфигурационный фреймворк поверх Dash. Позволяет создавать дашборды через YAML или Pydantic-модели, что упрощает разработку.
Voilà (5.8k+ звезд): Превращает Jupyter-ноутбуки в самостоятельные веб-приложения, скрывая код и оставляя только виджеты и выводы ячеек.

---

Категория 2: Бэкенд и MLOps (Развертывание и управление)

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

FastAPI

GitHub Stars: 88.2k+
Официальный сайт: fastapi.tiangolo.com
GitHub Repo: github.com/tiangolo/fastapi

Описание и назначение: FastAPI — это современный, высокопроизводительный веб-фреймворк для создания API на Python. Он стал де-факто стандартом для развертывания моделей машинного обучения в виде REST API благодаря своей скорости, автоматической документации и использованию стандартных аннотаций типов Python.

Особенности и оценка:

Сильные стороны: Невероятная производительность. Автоматическая интерактивная документация (Swagger UI, ReDoc). Простота использования благодаря Pydantic и аннотациям типов.
Слабые стороны: Это бэкенд-фреймворк. Для создания UI его нужно использовать в связке с фронтенд-технологиями.

vLLM

GitHub Stars: 54.8k+
Официальный сайт: vllm.ai
GitHub Repo: github.com/vllm-project/vllm

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

Особенности и оценка:

Сильные стороны: Значительно ускоряет работу LLM благодаря инновационным техникам, таким как PagedAttention. Совместимость с моделями Hugging Face. Становится стандартом для быстрого self-hosting LLM.
Слабые стороны: Узкоспециализированный инструмент для инференса LLM.

MLflow

GitHub Stars: 21.5k+
Официальный сайт: mlflow.org
GitHub Repo: github.com/mlflow/mlflow

Описание и назначение: MLflow — это платформа с открытым исходным кодом для управления полным жизненным циклом машинного обучения. Он включает в себя компоненты для отслеживания экспериментов (Tracking), упаковки кода (Projects), управления моделями (Models) и их развертывания (Registry).

Особенности и оценка:

Сильные стороны: Комплексное решение для MLOps. Помогает стандартизировать и воспроизводить ML-эксперименты. Интегрируется с большинством ML-библиотек.
Слабые стороны: Требует настройки и внедрения в рабочий процесс. Может быть избыточным для небольших проектов.

---

Категория 3: Интерактивные вычисления и отчетность

Эти инструменты меняют представление о статических отчетах и ноутбуках, делая их интерактивными и воспроизводимыми.

Quarto

GitHub Stars: 4.7k+ (CLI)
Официальный сайт: quarto.org
GitHub Repo: github.com/quarto-dev/quarto-cli

Описание и назначение: Quarto — это система публикации научных и технических документов нового поколения от Posit. Она позволяет создавать динамические документы и презентации из Jupyter-ноутбуков или простого Markdown, смешанного с кодом на Python, R или Julia.

Особенности и оценка:

Сильные стороны: Поддерживает множество форматов вывода (HTML, PDF, DOCX, презентации и др.). Языковая агностичность. Позволяет создавать красивые, профессиональные и воспроизводимые отчеты.
Слабые стороны: В первую очередь это инструмент для публикации, а не для создания интерактивных real-time приложений.

Marimo

GitHub Stars: 15.3k+
Официальный сайт: marimo.io
GitHub Repo: github.com/marimo-team/marimo

Описание и назначение: Marimo — это реактивная среда для Python, которая решает многие проблемы традиционных Jupyter-ноутбуков. В Marimo ноутбук — это интерактивное веб-приложение. Изменение в одной ячейке автоматически обновляет все зависимые ячейки.

Особенности и оценка:

Сильные стороны: Реактивность обеспечивает консистентность состояния. Встроенные UI-элементы. Ноутбуки легко экспортируются в виде приложений.
Слабые стороны: Новый инструмент с растущим, но пока небольшим сообществом. Отличается от привычного рабочего процесса в Jupyter.

---

Как выбрать подходящий инструмент?

Для быстрого прототипа или демо модели: Streamlit или Gradio.
Для сложного, кастомизированного корпоративного дашборда: Dash или Solara.
Для создания бэкенда и API для вашей модели: FastAPI.
Для максимальной производительности при развертывании LLM: vLLM.
Для построения полноценного MLOps-цикла: MLflow.
Для создания чат-бота на базе LLM: Chainlit.
Для создания красивых, воспроизводимых отчетов и статей: Quarto.
Если вы хотите попробовать реактивный, state-of-the-art ноутбук: Marimo.
Если вы из мира R или вам нравится реактивная парадигма: Shiny for Python.

Тетрадки наше всё – marimo.io и уточкаdb

Thu, 07 Aug 2025 22:34:19 +0300

marimo is an open-source reactive notebook for Python — reproducible, Git-friendly, AI-native, SQL built-in, executable as a script, shareable as an app.

Ставим скорее..

pip install marimo && marimo tutorial intro

Ну и small data тоже любит тетрадки https://duckdb.org/docs/stable/guides/python/marimo

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

про bi as a code можно посмотреть тут: https://gavrilov.info/all/samye-populyarnye-instrumenty-biznes-analitiki-na-osnove-koda-ob/

А тут есть пример использования iceberg каталога R2 c Marimo https://developers.cloudflare.com/r2/data-catalog/get-started/

А так в него можно добавить AI

UW PICO 5.09                          File: /Users/yuriygavrilov/.config/marimo/marimo.toml                             

[completion]
activate_on_typing = true
copilot = "custom"
api_key = "sk-GIkXXXXXXXXXX"
model = "openai/o1"
base_url = "https://openai.api.proxyapi.ru/v1"

и чуть ниже так..

[ai.open_ai]
api_key = "sk-GIkXXXXXXXXXX"
model = "openai/o1"
base_url = "https://openai.api.proxyapi.ru/v1"

Но как полечить это я еще не разгадал:

[E 250811 22:03:05 tools:173] Failed to get MCP tools: mcp is required for MCP server connections.

а пока усложняем задачу.

Хех, работает :)

Кстати уже писал про Bi as Code тут https://gavrilov.info/all/samye-populyarnye-instrumenty-biznes-analitiki-na-osnove-koda-ob/

Но будет полезно еще почитать по WASM контейнеры и запуст их в браузере, так как вся эта история на них хорошо работает, Evidence.dev например.

UPD: https://a.gavrilov.info/my_app2/dist/ – тут можно посмотреть экспортированную демо тетрадку в формате wasm с хостингом на s3

Экспортируются тетрадки так:

uv run  marimo export html-wasm markdown-format1.md -o my_app2/dist --include-cloudflare --mode run

Потом просто надо загрузить папку my_app2 в нужную директорию в все будет работать.

А вот еще пример генерации кода c ИИ

Тут можно посмотреть пример барчата https://a.gavrilov.info/my_app3/dist/

RAW Hollow – революция в управлении данными от Netflix

Wed, 30 Jul 2025 00:08:12 +0300

Оригинал тут: RAW Hollow – революция в управлении данными от Netflix

Или тут 👉 https://hollow.how/raw-hollow-sigmod.pdf

Пояснения для тех, кто не знаком с темой

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

Традиционные методы хранения данных (базы данных) бывают медленными, когда нужно получать данные очень-очень быстро, или сложными, когда их очень много и они постоянно меняются. Например, когда вы заходите посмотреть что-то, Netflix должен мгновенно понять, что вам показать на основе ваших предпочтений и доступного контента. Обычные базы данных могут не справляться с такой скоростью и объемом запросов.

Распределенные системы: Это означает, что Netflix не использует один огромный компьютер. Вместо этого у них тысячи маленьких компьютеров (серверов), расположенных в разных точках мира, которые работают вместе, чтобы обеспечить бесперебойный сервис.
In-Memory: “В памяти” означает, что данные хранятся прямо в оперативной памяти сервера (как в вашем компьютере, когда вы запускаете программы), а не на медленном жестком диске. Это делает доступ к данным невероятно быстрым.
Co-Located: “Совместно размещенный” означает, что данные хранятся на том же самом сервере, где работает программа, которой эти данные нужны. Не нужно отправлять запрос по сети на другой сервер, чтобы получить данные, что экономит время.
Object Store: Это не традиционная реляционная база данных с таблицами. Вместо этого данные хранятся как объекты (подобно файлам или записям), что более гибко.
Hollow (оригинальный): Это была технология Netflix для очень быстрого чтения данных. Она позволяла хранить целые каталоги данных в памяти для моментального доступа, но не позволяла изменять эти данные. Представьте, что это очень быстрая, но только для чтения, копия огромной книги.
RAW Hollow (Read After Write Hollow): Это развитие Hollow. Теперь можно не только читать, но и записывать данные, сохраняя при этом молниеносную скорость. Добавлена возможность изменять “книгу”, причем изменения мгновенно становятся видны другим, а система гарантирует, что данные не потеряются.
CAP Theorem: Это фундаментальная концепция в распределенных системах. Она утверждает, что из трех свойств – согласованность (Consistency), доступность (Availability), устойчивость к разделению (Partition tolerance) – можно одновременно гарантировать только два. Netflix же, благодаря RAW Hollow, предлагает гибкость в выборе: можно работать в режиме максимальной доступности (AP), где данные становятся согласованными со временем, или в режиме максимальной согласованности (CP), где данные всегда актуальны, но могут быть короткие задержки.

Важное в статье

Проблема, которую решает RAW Hollow: Традиционные базы данных страдают от непредсказуемой производительности, сложности синхронизации кэшей и накладных расходов сети. RAW Hollow решает эти проблемы, предоставляя сверхбыстрый доступ к данным (микросекунды для чтения) за счет их хранения в памяти непосредственно в приложении.

Эволюция от Hollow: RAW Hollow является развитием уже зарекомендовавшей себя технологии Hollow, которая использовалась Netflix более ~~10 лет~~ как кеш *только для чтения*. Новая версия добавляет возможность записи и гарантии атомарности и согласованности.

Архитектура RAW Hollow:
- Writers (Записывающие): Точка входа для всех операций записи. Используют Zookeeper для выбора лидера и синхронную репликацию для обеспечения долговечности данных. Способны обрабатывать до 1000 записей в секунду с нагрузкой 10 КБ.
- Logkeepers (Хранители логов): Простая, но надежная инфраструктура для долговечности. В памяти хранят циклический лог, обеспечивая быструю фиксацию записей. Высокая отказоустойчивость за счет развертывания в нескольких зонах доступности AWS.
- Producers (Производители): Синхронизируют данные из Logkeepers и распространяют их через внутренний паб/саб сервис Netflix (Gutenberg) на Writers и Local Clients. Создают снимки данных каждые 30 секунд для долгосрочного хранения в S3, что обеспечивает надежность на уровне “11 девяток”.
- Local Clients (Локальные клиенты): Самая уникальная особенность. Каждое приложение-клиент поддерживает полную, материализованную копию всего набора данных в своей памяти. Это позволяет осуществлять операции чтения без сетевых задержек (микросекунды). Получают обновления в реальном времени от Logkeepers.

Свойства ACID и согласованность:
- Атомарность: Гарантируется через API Bulk Update, где все операции в транзакции либо выполняются полностью, либо не выполняются вовсе.
- Согласованность: Поддерживается за счет всесторонней валидации схемы. API Conditional Bulk Update позволяет применять предварительные условия для предотвращения состояний гонки.
- Изоляция: Реализован уровень Read Committed, предотвращающий “грязные” чтения.
- Долговечность: Обеспечивается синхронной репликацией на Logkeepers и регулярными снимками в S3.

Гибкость модели согласованности (CAP Theorem):
- Eventually Consistent (AP-система по умолчанию): Приоритет доступности и отказоустойчивости. Чтения мгновенны, обновления распространяются быстро, но временные несоответствия могут быть (идеально для рекомендаций).
- Strong Consistency (CP-система по запросу): Позволяет запрашивать сильную согласованность для отдельных операций. Клиент временно синхронизируется с последними изменениями. Это позволяет достичь баланса между производительностью и точностью данных для критически важных операций (например, финансовые транзакции).

Производительность и масштабируемость:
- Чтение: Микросекунды, так как данные “co-located”.
- Запись: До 1000 записей/сек (10 КБ полезной нагрузки), задержка распространения обновлений — миллисекунды.
- Масштаб данных: До 100 миллионов записей на сущность, благодаря эффективному сжатию.

Применение в реальном мире: RAW Hollow уже активно используется в более чем 160 критически важных сервисах Netflix (Tier-0), включая:
- Управление метаданными видео (каталоги контента).
- Системы рекомендаций и персонализации.
- Управление сетевой инфраструктурой CDN (Open Connect).
- Управление идентификацией и доступом (OneID).
- Потенциал для игр, финансовых услуг (рыночные данные, борьба с мошенничеством), электронной коммерции.

Операционная готовность: Наличие инструментов мониторинга, отслеживания изменений, возможность “нулевого копирования” для окружений и быстрого отката версий.

---

Вывод ИИ

RAW Hollow от Netflix представляет собой парадигмальный сдвиг в проектировании высокопроизводительных, распределенных систем управления данными для сценариев с малым и средним объемом данных. Он демонстрирует, как глубокое понимание компромиссов CAP-теоремы и инновационный подход к ко-локации данных в памяти могут обеспечить беспрецедентную комбинацию экстремально низкой задержки чтения, высокой доступности и гибко настраиваемой согласованности. Эта технология является эталоном для создания отказоустойчивых и масштабируемых микросервисов, особенно в условиях, где традиционные базы данных становятся узким местом. Успешное развертывание в критически важных сервисах Netflix подтверждает зрелость и применимость подхода RAW Hollow в реальных производственных средах. Это не просто инструмент, а архитектурный паттерн, который будет влиять на будущее распределенных систем.

---

Шаги по применению (для внедрения аналогичного подхода)

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

Анализ требований и выявление “боли”:
- Определите, какие ваши сервисы страдают от высокой задержки чтения, непредсказуемой производительности баз данных или сложностей с синхронизацией кэшей.
- Оцените, укладываются ли ваши наборы данных в категории “малые” или “средние” (помещаются ли в оперативную память). Слишком большие dataset’ы не подходят для RAW Hollow-подобных решений.

Исследование существующих решений:
- Прежде чем разрабатывать что-то свое, изучите готовые ин-мемори базы данных (Redis, Apache Ignite, GemFire/Pivotal CloudFoundry Data Services) и распределенные кэши. Hollow/RAW Hollow — это более низкоуровневое и кастомизированное решение.
- Оцените возможность использования Apache Kafka или подобных систем для потоковой обработки изменений, как это делает Netflix.

Проектирование архитектуры:
- Модель данных: Разработайте оптимальную схему данных, которая будет эффективно храниться в памяти и обеспечивать быстрый доступ. Учитывайте возможности сжатия и индексирования.
- Модель согласованности: Для каждого компонента или операции четко определите требуемый уровень согласованности (сильная или конечная). Это критический шаг.
- Компоненты: Определите необходимые компоненты, аналогичные Writers, Logkeepers, Producers и Local Clients.
  - Writers: Как будут приниматься и обрабатываться запросы на запись? Нужен ли механизм выбора лидера?
  - Durability Layer: Как будет обеспечиваться долговечность данных? Локальные логи? Репликация? Архивация в S3-подобные хранилища?
  - Change Propagation: Как изменения будут распространяться между узлами и клиентами? Нужен эффективный механизм паб/саб.
  - Local Data Stores: Как данные будут храниться в памяти клиентов/сервисов? Как будут обновляться?
- Отказоустойчивость: Разработайте механизмы для обработки сбоев отдельных компонентов (например, падение Writer, Logkeeper), восстановления после сбоев и обеспечения непрерывной работы.

Выбор технологий и инструментов:
- Для координации: Zookeeper или Consul для выбора лидера и управления распределенным состоянием.
- Для потоковой обработки/паб/саб: Kafka, Pulsar или Kinesis.
- Для хранения снимков: S3-совместимые хранилища.
- Для in-memory хранения: Возможно, придется использовать кастомные структуры данных или библиотеки для работы с памятью в выбранном языке программирования (например, Java ByteBuffer для эффективного управления памятью).

Разработка и реализация PoC (Proof of Concept):
- Начните с небольшой, изолированной PoC, чтобы проверить ключевые концепции: co-located storage, запись, распространение изменений, согласованность.
- Измерьте производительность и задержку на ранних этапах.

Тестирование и оптимизация:
- Нагрузочное тестирование: Проверьте систему под высокой нагрузкой чтения и записи.
- Chaos Engineering: Внедряйте контролируемые сбои (как Netflix с Chaos Monkey), чтобы убедиться в устойчивости системы.
- Мониторинг: Встройте комплексные системы мониторинга и логирования для отслеживания состояния, производительности и проблемных мест во всех компонентах.

Развертывание и эксплуатация:
- Постепенное развертывание в производственной среде, начиная с менее критичных сервисов.
- Обеспечение операционных процедур: обновление, резервное копирование, восстановление, масштабирование.

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

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

Sat, 31 May 2025 23:41:47 +0300

Опубликовано 21.10.2023. Изменено 06.11.2023.

Оригинал: https://unixdigest.com/articles/we-have-used-too-many-levels-of-abstractions-and-now-the-future-looks-bleak.html

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

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

Слишком мало и слишком много всё портит.

Какая польза от абстракции, когда она ломается и никто больше не понимает, как работает технология “под капотом”?

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

Сегодня программистов и системных администраторов больше не существует, вместо них у нас есть DevOps и даже DevSecOps, в которых индустрия очень старательно пытается втиснуть каждую отдельную задачу в должностную инструкцию одного человека. Специалисты по технологиям должны выполнять разработку (Dev), безопасность (Sec) и операции (Ops), то есть системное администрирование, но поскольку ни один человек не может по-настоящему освоить все это, нам нужно автоматизировать как можно больше, чтобы сэкономить деньги и избежать сложностей человеческого социального взаимодействия между различными техническими отделами. В результате современному специалисту по технологиям enseñan только тому, как использовать конкретные инструменты, и он или она очень мало знает о технологии “под капотом”.

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

Ваш браузер не поддерживает видео.

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

Да, давайте все вернемся к кодированию на ассемблере!

— Саркастический комментарий высокомерного разработчика

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

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

— Кен Томпсон

Уже сейчас большинство “специалистов по безопасности” очень мало знают о безопасности и только о том, как использовать какой-то готовый инструмент для тестирования на проникновение. Инструмент для тестирования на проникновение показывает кучу зеленых лампочек на своей веб-панели, и все считается в порядке. Тем не менее, настоящий эксперт по безопасности со злыми намерениями давно взломал систему и продолжает продавать ценные данные в даркнете. Ничего не утекло и ничего не обнаружено. Это может продолжаться годами, никто ничего не узнает, потому что, ну, на панели GUI написано, что все в порядке.

Некоторые студенты сегодня, по-видимому, даже не знают, что такое файлы и папки.

Советы изучающим технологии:

Никогда не следуйте за хайпом или трендами.
Будьте любопытны. Не просто изучайте инструменты, старайтесь понять, как работает базовая технология.
Если возможно, попробуйте хотя бы один раз вручную сделать то, что, например, делает для вас инструмент конфигурации.
Если возможно, попробуйте посмотреть код инструмента. Даже базовое понимание кода может быть очень ценным.
Сохраняйте любопытство. Продолжайте учиться. Экспериментируйте. Погружайтесь глубже в интересующие вас технологии. Если возможно, создайте домашнюю лабораторию и используйте ее как игровую площадку для обучения и слома вещей.
Ставьте под сомнение все. Особенно то, что вам кажется бессмысленным. Не думайте, что кто-то знает лучше — так вы быстро превратитесь в слепого последователя. Иногда кто-то действительно знает лучше, но не делайте такого вывода по умолчанию. И будьте смелыми! Стойте на стороне правды и своих убеждений, даже если это заставляет вас чувствовать себя одиноким.

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

Скорее, я затрагиваю важную ценность инженерного отношения к технологиям у людей, работающих с технологиями.

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

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

Примерно полгода назад я наткнулся на несколько фронтенд-веб-разработчиков, которые не знали, что веб-сайт можно создать без инструмента развертывания и что JavaScript вообще не нужен, даже если веб-сайт принимает платежи. Я спросил об этом своего друга, который в то время преподавал программирование на Python, и он сказал:

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

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

Если, например, я веб-разработчик, будь то фронтенд или бэкенд, или занимаюсь так называемой “интеграционной работой” и создаю веб-сайты без особого кодирования или каких-либо знаний о TCP/IP, DNS, HTTP, TLS, безопасности и т. д., используя только готовые инструменты или фреймворки, то это сделает меня примерно таким же полезным, как обезьяна с динамометрическим ключом, когда что-то пойдет не так.