[4/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Повышение продуктивности разработки (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2 и 3). Мы поговорим про то, какие аспекты позволяют быть разработчикам внутри Meta более продуктивными.

Continuous deployment и автоматизация
Одной из главных целей общей инфраструктуры Meta является ускорение работы разработчиков. В компании довели до экстрима подходы CI/CD, добившись практически полного автоматического выпуска обновлений. 97% сервисов Meta разворачиваются без ручного участия инженеров - изменения поставляются через автоматические пайплайны деплоя (более 30к пайплайнов следят за обновлениями). Около 55% сервисов используют реально непрерывный деплой, остальные ~42% - развёртываются роботами по расписанию (как правило, ежедневно или еженедельно). Например, фронтенд-платформа Meta (serverless-функции, обслуживающие пользовательские запросы) релизится каждые три часа, а она работает на 500к+ серверов и ее код ежедневно меняют 10к+ разработчиков.

Конфигурация как код и мгновенные изменения
В Meta разграничение между “кодом” и “настройками” практически стёрто - конфигурационные изменения обрабатываются теми же конвейерами, что и программный код. Каждый день более 100к изменений конфигураций автоматически применяется на продакшене с помощью внутренней системы управления настройками. Они затрагивают порядка 10к различных сервисов и 1M+ запущенных процессов по всему миру (настройки параметров балансировки нагрузки, включение feature flags, настройки A/B тестов, ...). Практически каждый инженер Meta, пишущий код, также вносит правки в “живые” конфиги:
- Они хранятся в репе как код
- Проходят peer-review
- Раскатываются через CD pipelines
- Агенты по принципу publish-subscribe раскатывают изменения на сервисы
- Приложения применяют новые параметры на лету, без перезапуска процессов
Из этого следует четвертый инсайт статьи

Insight 4 : Even for a large organization with O(10,000) services, it is feasible to adopt continuous deployment at extreme scales and speeds. Specifically, 97% of our services adopt fully automated deployments without manual intervention, and 55% deploy every code change instantly.

Инструменты для качества и быстрого отката
Стремление “выпускать сразу” неизбежно повышает риски сбоев, поэтому в Meta разработаны многоуровневые средства для безопасного развертывания. Перед полным выкатом новый код проходит автоматические тесты и канареечные прогоны. В случае обнаружения проблем хорошо отлажены механизмы мгновенного отката до предыдущей стабильной версии.

Serverless functions как основа разработки
Более 10 000 разработчиков Meta используют FaaS ежедневно, а это устраняет необходимость в управлении инфраструктурой: код автоматически масштабируется и разворачивается и оптимально использует инфру. Использование FaaS интегрировано в IDE (облегчен доступ к социальному графу и бэкенд‑системам). FaaS - это stateless архитектура, которая опирается на внешние кэш‑системы и базы данных, что обеспечивает предсказуемое поведение и простоту горизонтального масштабирования.У Meta есть две FaaS платформы:
- FrontFaaS для обработки пользовательских запросов (PHP, Python, Erlang, Haskell) с low latency
- XFaaS для обработки асинхронных, событийных функций с резкими пиковыми нагрузками. Они оптимизируются через глобальный балансировщик, отложенное выполнение и квот‑троттлинг, чтобы избежать оверпровижининга.
Эту часть обобщает пятый инсайт

Insight 5 : Serverless functions have become the primary coding paradigm for product development at Meta. More than 10,000 Meta engineers write code for serverless functions, exceeding the number of engineers writing regular service code by 50%.

В следующем посте мы поговорим про то, как Meta уменьшает свои затраты на инфраструктуру.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[5/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Снижение затрат на оборудование (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3 и 4) и обсудим снижение затрат на инфру.

All global datacenters as a computer
Подход Meta к восприятию своей инфры отлично описывается очередным инсайтом

Insight 6 : Meta is evolving from the practice of “the datacenter as a computer” to the vision of “all global datacenters as a computer.” In this model, the infrastructure autonomously determines and migrates deployments across global datacenters in response to workload changes, eliminating the need for user involvement. We have successfully demonstrated this approach for databases, ML systems, and diverse services operating at the scale of O(100,000) servers and O(100,000) GPUs.

Hardware and software co-design
Но при этому появляется потребность в совместном проектировании софта и железа для него
- Graceful degradation: эффективная инфраструктура должна уметь адаптивно деградировать при экстремальных ситуациях, чтобы не держать постоянный избыточный запас мощности про запас. В Meta система Defcon умеет отключать функциональность по уровням приоритетности, освобождая ресурсы для ключевых сервисов
- Экономия на proxy в service mesh: в индустрии распространена архитектура service mesh с sidecar proxy per service, который перехватывает и маршрутизирует запросы. Meta разработала свою систему ServiceRouter (~1% RPC-запросов проходят через proxy, а 99% - маршрутизируются напрямую с помощью встроенной в каждый сервис библиотеки). Это экономит 100k+ серверов
- Многоуровневое хранение данных: чтобы оптимизировать расходы на хранение, данные разделяются на категории по частоте доступа и допустимой задержке
-- Горячие данные (соцграф, ленты, кеши) хранятся в высокопроизводительных системах (RAM + SSD)
-- Тёплые данные (фото/видео пользователей, кликстрим) хранятся в распределенной файловой системе Tectonic на обычных HDD-дисках (1 server ~36 HDD + 2SSD для metadata)
-- Холодные данные (оригинальные видео высокого качества) архивируются на ультраплотных storage-серверах с большим числом медленных дисков (1 server ~216 HDD)
- Локальные SSD вместо сетевых хранилищ: в индустрии облачных сервисов считается хорошей практикой выносить хранение отдельно на блочное устройство для простоты миграций и балансировки нагрузки. Но в Meta ради экономии и низкой latency предпочитают локальные SSD даже для stateful-сервисов, где это возможно. От этого возникают сложности, которые Meta решает централизованно через систему управления шардированием (Shard Manager), которая абстрагирует размещение фрагментов данных и обеспечивает автоматический ребаланс
- Дешёвое оборудование с надёжностью через софт: в публичных облаках оборудование часто дублируется, потому что приложения клиентов могут быть не готовы к сбоям. Meta выбрала противоположный подход - использовать более простое и дешёвое железо, но заставить всё ПО быть устойчивым к отказам. В итоге, очередной инсайт звучит так

Insight 7 : To reduce hardware costs, we use software solutions to overcome the limitations of lower-cost hardware. Although this approach adds complexity to the software stack, we consider the trade-off worthwhile due to the significant cost savings.

In-house hardware design
Для всего описанного выше Meta сама разрабатывает конструкции ЦОДов (Open Compute датацентры), а также значительную часть оборудования. Контроль над дизайном позволяет убирать всё лишнее и повышать эффективность (особенно эффективность использования электроэнергии, что сейчас является бутылочным горлышком для ДЦ)

Insight 8 : To reduce hardware costs and power consumption, Meta designs its own datacenters, servers, racks, and network switches, and shares these designs through open source.

В следующем посте мы поговорим про то, как инженеры в Meta проектируют свои системы.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[6/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Проектирование масштабируемых систем (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3, 4 и 5) и обсудим как ребята подходят к проектированию масштабируемых приложений.

Централизация vs децентрализация
Инфраструктура планетарного масштаба исторически ассоциируется с децентрализованными архитектурами (BGP, BitTorrent, и т.п.). Они хорошо масштабируются без SPOF (single point of failure). Однако опыт Meta показал, что в пределах датацентра, где ресурсы относительно надёжны и управляются одной организацией, централизованные контроллеры зачастую упрощают систему и при этом обеспечивают достаточную масштабируемость. А часто это еще позволяет принимать более глобально оптимальные решения, чем множество локальных агентов. Поэтому Meta сознательно отошла от многих изначально распределённых дизайнов в сторону управляемых централизованно. Например,
- Внутренняя сеть ЦОД (Fabric) по-прежнему использует протокол BGP для совместимости, но маршрутизацией управляет центральный контроллер, который при перегрузках или обрыве линков переоптимизирует пути трафика взамен медленной сходящейся динамики BGP
- В магистральной глобальной сети (WAN) Meta изначально применяла децентрализованный протокол резервирования полосы (RSVP-TE), но затем перешла на центральный контроллер, рассчитывающий оптимальные пути для потоков между датацентрами и заранее прокладывающий резервные каналы на случай типовых отказов. Это позволило значительно эффективнее использовать пропускную способность каналов и упростило управление сетью.

В общем случае подход Meta можно сформулировать таким инсайтом

Insight 9 : In a datacenter environment, we prefer centralized controllers over decentralized ones due to their simplicity and ability to make higher-quality decisions. In many cases, a hybrid approach - a centralized control plane combined with a decentralized data plane-provides the best of both worlds.

В качестве примера подробнее разбирается гибридный service mesh под названием ServiceRouter (попытка получить “лучшее из двух миров”). ServiceRouter обслуживает миллиарды вызовов в секунду между микросервисами, распределёнными по миллионам программных маршрутизаторов уровня L7. В традиционных решениях service mesh (например, Istio) каждое приложение сопровождается локальным прокси, через который проходят все исходящие и входящие вызовы. В ServiceRouter Meta от этой схемы отказались (как упоминалось, ~99% запросов идут без sidecar-прокси). Вместо этого
- Control plane централизован - он агрегирует всю информацию о сервисах и глобальных метриках сети, вычисляет оптимальные правила маршрутизации и сохраняет их в RIB (outing Information Base), построенной поверх распределенной базы данных Delos с Paxos протоколом (то есть она распределена и отказоустойчива). Таким образом, центральные контроллеры ServiceRouter ответственны только за вычисление глобальных решений, а непосредическая работа по маршрутизации лежит на data plane.
- Data plane в виде отдельных L7 routers децентрализован - они автоматически подтягивают из RIB нужные им сведения (кэшируют небольшой необходимый поднабор) и работают автономно, без постоянного участия центрального координатора

Благодаря такому дизайну достигаются
- Простота управления - центрально видна вся картина
- Масштабируемость - нет узкого места, через которое прошёл бы весь трафик
В итоге, удаётся обеспечить полный функционал сервис-меша (балансировка, retries, discovery, мониторинг) при минимальном расходе ресурсов и с возможностью глобального оптимального распределения нагрузки.

В последнем посте из серии мы поговорим про будущие направления развития инфраструктуры и архитектуры Meta (это одна из самых интересных частей)

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[7/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Будущие направления развития (Рубрика #Infrastructure)

Этот пост финальный в рассмотрении крутой обзорной статьи от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3, 4, 5 и 6). Здесь мы обсудим как автор видит дальнейшее развитие инфраструктуры, архитектуры и проникновение AI в системы компании. Отмечу, что эта часть была мне очень интересна - сложить пазл о том, как развивалась история это одно, а сделать качественное предсказание - это уже задачка со звездочкой.

AI и новая архитектура дата-центров
AI-нагрузки уже стали главным потребителем ресурсов Meta: к концу десятилетия они займут более половины мощностей ЦОД. В отличие от классических веб-сервисов, обучение моделей требует сотен терабайт данных, мощных GPU и сверхбыстрых сетей. Это ведёт к смене парадигмы — от scale-out (много дешёвых узлов) к scale-up, когда создаются крупные AI-кластеры, напоминающие суперкомпьютеры. Meta выстраивает полный стек под AI: от PyTorch и моделей до собственных чипов (MTIA), сетевых решений, хранилищ и систем охлаждения. Всё проектируется комплексно, чтобы работать синхронно. В будущем датацентры наполовину станут «машинами для обучения ИИ» - это изменит всю их архитектуру.

Эра специализированного железа
После эпохи унификации серверов начинается обратный процесс: расцвет кастомных ASIC и ускорителей. Гиперскейлеры могут позволить себе проектировать собственные чипы для AI-тренинга, компрессии, шифрования, видео-кодирования, In-Network-/In-Storage-Processing и т.д. Meta ожидает, что ЦОДы превратятся в гетерогенные кластеры из множества типов оборудования. Главный вызов - научить софт эффективно использовать столь разнородные ресурсы. Для этого потребуются новые уровни абстракций и оркестрации. Но выигрыш в энергоэффективности и стоимости на миллионах серверов окупит усилия.

Краевые датацентры и метавселенная
Meta прогнозирует бурный рост инфраструктуры на «краю» сети — мини-ЦОД, близких к пользователям. Это нужно для AR/VR, облачного гейминга и IoT, где критична задержка <25 мс. Компания строит модель Global Data-center-as-a-Computer: приложения будут автоматически выполняться там, где ближе пользователь, без участия разработчика. Архитектура станет многоуровневой - крупные регионы + сеть микро-ЦОД, объединённых общей системой оркестрации.

Прорыв в средствах разработки
Meta ожидает качественного скачка продуктивности инженеров за счет двух факторов
1. Массовое внедрение AI-ассистентов (Copilot, GPT-4 и др.), которые автоматизируют генерацию кода, поиск багов и рефакторинг и так далее
2. Появление вертикально интегрированных платформ, где разработчик описывает только бизнес-логику, а инфраструктура скрыта под капотом.
Пример - внутренний проект FrontFaaS, ускоряющий создание веб-интерфейсов. Похожие фреймворки появятся и в других доменах, радикально повышая индивидуальную продуктивность.

Совместное развитие
Автор подчёркивает: за 20 лет гиперскейлеры задали темп всей индустрии, и ИИ лишь ускорит этот процесс. Чтобы инновации распространялись быстрее, нужно делиться опытом. Meta призывает публиковать открытые проекты и исследования — как она делает сама. Статья служит именно этой цели: показать, из каких «кирпичиков» строится инфраструктура Meta и какие принципы могут вдохновить инженеров по всему миру.

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

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

Modern Architecture 101 for New Engineers & Forgetful Experts - NDC Copenhagen 2025 (Рубрика #Architecture)

Отличное выступление Jerry Nixon, product manager из команд SQL Server и Data API Builder, в котором он говорит, что архитектура - это не про "best practices", а про контекстные решения и смелость говорить "нет". Фактически, Никсон разрушает мифы и дальше показывает как строить архитектуру под любой масштаб с учетом вашего контекста. А начинает он с провокации, говоря, что термин "best practice" используют как оправдание отсутствия аргументов. Единственная настоящая best practice - не использовать SQL injection. Все остальное зависит от:
- Политики и бюджета компании
- Уровня команды (джуниоры vs эксперты)
- Наследия систем и ограничений от объединения разных систем
- Возможности "платить за ошибки" (Twitter может себе позволить глупости, а вы - нет)
Дальше он показывает "годовые кольца" технологий: spaghetti code 90-х, трехуровневые приложения 2000-х и микросервисы 2010-х, а дальше заключает, что все это работает до сих пор. В итоге, architecture shaming - это просто неуважение к контексту, в котором были приняты прошлые архитектурные решения.

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

Совершенство достигается не тогда, когда нечего добавить, а когда нечего убрать

После этого спикер начинает показывать как можно начинать проектировать решение с базы и постепенно наращивать сложность по мере появления доп требований
- Client → Database
- Client → API → Database (добавили интерфейс)
- Write API → Primary DB (синхронизация через логи) и Read API → Read replica. Логика в том, что вы масштабируете запись и чтение независимо за счет простого изменения connection string, а также за счет eventual consistency (и вам сразу становитсья важно понимать модели консистентности)
- Дальше появляется API Manager (APIM) / Gateway для управления API, версионирования, балансировки нагрузки, постепенной раскатки и a/b тестов
- Дальше появляется история про мониторинг (Никсон советует OpenTelemetry), кеши и service bus
- Ну и вообще асинхронность - это способ работы на масштабе: CQRS (Command Query Responsibility Segregation), Queue для работы со спайками нагрузки
- И так далее

В общем, выступление очень интересное. Основные мысли примерно такие
- Все компромиссы исходят из реальности, а не идеологии
- Архитектор - это тот, кого винят. Ваши решения будут судить через 5 лет, когда вы уже покинете компанию
- Сложность должна оправдываться. Каждый добавленный компонент (service bus, cache, gateway) - это еще одна система, за которую вы отвечаете.

Ну и напоследок тезис от автора, что меня сначала повеселил, а потом заставил задуматься

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

#Architecture #DistributedSystems #Management #Software #Leadership #Patterns #SystemDesign

Meta looks to power trading supports its AI energy needs (Рубрика #AI)

В ноябре 2025 года стало известно о нетривиальном шаге запрещенной в России компании Meta, которая получила разрешение американских регуляторов на торговлю электроэнергией на оптовом рынке. Такой шаг призван удовлетворить стремительно растущий спрос ее центров обработки данных (ЦОД) на электричество для решений искусственного интеллекта (AI). По сути, Meta создает собственное направление энерготрейдинга, чтобы напрямую закупать электроэнергию, заключать долгосрочные контракты с электростанциями и при необходимости перепродавать излишки мощности на рынке. Интересно, что в документе "Meta’s Hyperscale Infrastructure: Overview and Insights", что я разбирал раньше, было рассказано как раз о энергии, как о главном лимитирующем факторе для датацентров и инфры (условно, железо можно и обновить, а вот новые мощности по питанию обеспечить сложнее)

Тезисы тут примерно такие
- Сейчас мы наблюдаем взрывной рост потребности в энергии для AI, которые требуют огромных вычислительных ресурсов
- Существующая энергосистема с трудом справляется с такими темпами роста нагрузки, что уже вызвало в отдельных регионах США рекордный рост цен на мощность на оптовых аукционах
- Традиционных подходов к закупке энергии недостаточно - разработчики новых электростанций нуждаются в “якорных” покупателях, готовых брать на себя долгосрочные обязательства по закупке энергии. Например, Meta для своего нового ДЦ в Луизиане потребовалось вкладываться в строительство трех газовых станций, чтобы запитать ДЦ (они закоммитились только на это потратить 1.6 млрд $)
- А закупая электричество оптом можно не только снижать издержки за счет оптовых закупок, но и получать прибыль в периоды избытка продавая её обратно в сеть по пиковым ценам

В итоге, Meta создала дочернюю компанию Atem Energy LLC и получила разрешение на торговлю электроэнергией оптом от федеральной комиссии по регулированию энергетики США (FERC). Компания планирует изначально сотрудничать с опытными партнёрами-трейдерами и сконцентрироваться на работе на рынке США

Интересно, что Meta пошла по стопам других корпораций, получавших аналогичные лицензии. На оптовом рынке уже есть Google Energy, Apple Energy, Energy LLC, Amazon Energy. В общем, Meta не прокладывает абсолютно новый путь, но масштаб её усилий в энергетике - один из крупнейших на сегодня в Big Tech.

Если подумать, то для инфраструктуры ЦОДов это может значить следующее
- Снятие энергетических ограничений на рост ИИ - раньше именно энергия была лимитирующим фактором
- Увеличение капитальных затрат на дата-центры - теперь при планировании новых центров обработки данных компаний уровня Meta или Google необходимо учитывать и строительство параллельной энергоструктуры (это приведет к росту стоимости ЦОД проектов)
- Дизайн будущих дата-центров - появляется стимул размещать их ближе к источникам энергии: например, строить кампусы рядом с зонами богатых ВИЭ-ресурсов (ветер, солнце) или возле действующих крупных электростанций, чтобы минимизировать нагрузку на сети.
- Новые стандарты надежности и устойчивости - включение дата-центров в активное управление энергопотреблением (через торги, регулирование нагрузки) повышает устойчивость энергосистем, но и задаёт новые стандарты самим ЦОД. Например, Google уже заключает demand response-контракты с энергокомпаниями, согласившись переносить часть вычислений на непиковое время во избежание перегрузок сети

В сумме, инициатива Meta сигнализирует всему ИИ-сектору: эры дешёвого и гарантированного электричества больше нет, и дальнейший прогресс ML/AI тесно увязан с энергетической инфраструктурой. Те, кто сумеют интегрироваться с энергосистемой (через инвестиции или партнерства), получат фору в гонке ИИ, а те, кто проигнорируют - рискуют столкнуться с энергетическим дефицитом, замедляющим их инновации.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #AI #Economics

[2/2] Communication Patterns: A Guide for Developers and Architects (Паттерны коммуникации: руководство для ИТ-разработчиков и архитекторов) (Рубрика #Management)

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

3️⃣ Передача знаний (Communicating Knowledge) - как управлять знаниями в команде и организации.
- Глава 10. Принципы управления знаниями (Knowledge Management Principles). Разница между данными, информацией и знаниями. Почему wiki-системы превращаются в свалку и как этого избежать.
- Глава 11. Знания и люди (Knowledge and People). Как люди усваивают информацию и почему "шаринг знаний" часто не работает. Психология обучения взрослых применительно к инженерным командам.
- Глава 12. Эффективные практики (Effective Practices). Конкретные инструменты: от ведения ADR (Architectural Decision Records) до проведения воркшопов и сессий совместного моделирования.

4️⃣ Удаленная работа (Remote Communication) - специфика общения в распределенных командах.
- Глава 13. Фактор времени при удаленной работе (Remote Time). Паттерны для асинхронной коммуникации и работы в разных часовых поясах. Как сохранить контекст и темп работы, когда команда разбросана по миру.
- Глава 14. Принципы дистанционного общения (Remote Principles). Здесь речь про создание четких коммуникационных каналов, протоколов, а также про адаптацию стиля общения в зависимости от нужд команды. На эту тему есть хорошая книга "Remote Team Interactions Workbook" (о которой я уже рассказывал) от авторов книги "Team Topologoies".
- Глава 15. Методы дистанционного общения (Remote Channels). Здесь автор рассказывает про установление культуры открытой и честной обратной связи, а также использование технологий для улучшения коммуникации и поддержания связи между членами команды. Кстати, про открытую и честную обратную связь можно почитать в книге "Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity", о которой я уже рассказывал.

#Thinking #Writing #Leadership #Management #DistributedSystems #Architecture #SoftwareArchitecture #SystemDesign #Software #Writing #Speaking

AI-инженерия. Построение приложений с использованием базовых моделей (AI Engineering) (Рубрика #AI)

Книгу "AI Engineering" уже перевели и скоро выпустят в издательстве Питер. А я эту книгу прочитал на английском еще в начале года и она мне супер зашла (мы ее вместе с Женей Сергеевым из Flo почти целиком разобрали за три серии подкаста: 1, 2 и 3). Собственно, книга отлична подходит инженерам, что строят GenAI‑продукт прямо сейчас, например, чат‑бот, copilot, RAG, ...

Книгу написала Chip Huyen, которая
- Преподавала Machine Learning Systems Design в Stanford (CS329S), а значит умеет объяснять системно и доступно
- Написала книгу "Designing Machine Learning Systems" (O’Reilly), которую многие считают must‑read для инженеров из ML/Platform команд
- Работала на стыке AI + инфраструктуры (NVIDIA, Snorkel AI), сейчас - Voltron Data (GPU‑ускорение аналитики)

Есть несколько факторов почему "AI Engineering" стала бестселлером
1. Попала в боль 2024–2025: команды массово интегрируют базовые модели, и нужен инженерный фреймворк, а не очередной набор промптов
2. Большой фокус был на evaluation: не “vibe check”, а измеримые метрики, регрессионные наборы, LLM‑as‑a‑judge, тестирование на деградации
3. Закрывает прод‑реальность: стоимость и латентность инференса, мониторинг, качество данных/фидбек‑лупы, безопасность и риск‑менеджмент
4. Даёт карту паттернов (prompting, RAG, fine‑tuning, tools/function calling, agents) и отвечает на главный вопрос: когда что выбирать
5. У книги есть публичные материалы/ресурсы (репо на 12.5к звездочек), поэтому вокруг неё быстро выросла “экосистема” практик

Вот чем может быть полезна эта книга инженерам, которые уже пилят GenAI
- Превращает "демку на фреймворке" в проект: требования → архитектура → eval harness → релиз → наблюдаемость
- Помогает говорить на одном языке с Product/Platform: какие SLO/SLI у LLM‑фичи, что логируем, где делаем гейтинг качества, как считаем cost‑per‑request
- Хороша для техлидов: много про компромиссы (качество vs цена, контекст vs retrieval, детерминизм vs креативность) и про то, где чаще всего “ломается” система

Мини‑чеклист из книги, который можно использовать хоть завтра:
- Golden кейсы + негативные кейсы (и регулярные регрессионные eval’ы)
- Версионирование промптов/моделей/ретривера + логирование контекста
- Метрика "стоимость ответа" + бюджет на фичу
- Eval гейты в CI перед деплоем (как unit/integration, только для LLM)

В общем, книга определенно заслуживает прочтения. Кстати: пока книга еще в предзаказе на нее действует скидка в 35% при использовании промокода "Предзаказ"

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

Топ-3 книги издательства Питер, что я могу порекомендовать в этом году (Рубрика #Software)

Все три приведенные ниже книги я считаю стоящими, но надо отметить, что читал я их еще в оригинале и в тот момент, когда они были опубликованы (на русском я их пока не перечитывал)

1️⃣ AI-инженерия. Построение приложений с использованием базовых моделей
Последние годы проходят во многом под знаком AI. Уровень хайпа просто бомбический, но это не значит, что за хайпом ничего не стоит, а сами технологии ничего не дают. Напротив, результаты есть и они масштабные, но только у тех, кто умеет пользоваться инструментом правильно. А эта книга как раз про то, как строить приложения с использованием фундаментальных моделей. Я уже рассказывал про эту книгу раньше и считаю, что она будет полезна инженерам

2️⃣ Паттерны проектирования API
Про эту книгу я тоже рассказывал раньше, но в рамках хайпа про AI она мне кажется становится важнее. Суть в том, что 2025 год прошел под знаком AI агентов и эта движуха дальше будет только разгоняться - осенью 2024 года был представлен протокол MCP (model context protocol), который описал формат API вызова инструментов моделями, весной 2025 года Google представил A2A протокол (agent to agent), но все эти штуки живут поверх хороших подходов к управлению API. А эта книга как раз про это, причем автор, Джей Джей Гивакс, работал в Google и был соавтором статьи "API Governance at Scale" про подходы в Google (см. мой разбор). Он же был сооснователем ресурса aip.dev и одним из главных идеологов процесса AIP (API Improvement Proposals), про который я рассказывал раньше. Интересно, что с момента издательства книги Джей Джей уже успел перейти в Meta (видимо там тоже нужно поработать над API Governance).

3️⃣ Распределенные данные. Алгоритмы работы современных систем хранения информации
Про эту книгу "Database Internals" я уже рассказывал и мы даже ее разбирали в подкасте "Code of Architecture". Если подвязывать эту книгу к теме AI, то можно много сказать про хранение данных, про важность их для контекста ... Но я не буду этого делать - я выбрал эту книгу, потому что она хорошо рассказывает про движки для хранения данных, а также про архитектуру распределенных систем. Автор книги, Алекс Петров, контрибьютил в Cassandra, поэтому у него релевантный опыт для рассказа об этих темах.

В общем, книги достойные - я получил большое удовольствие, когда их изучал:)

#Databases #Software #Engineering #Architecture #AI #ML #DistributedSystems #Architecture #API

[1/2] Databases in 2025: A Year in Review by Andy Pavlo (Рубрика #Databases)

Изучил ежегодный обзор рынка баз данных от Andy Pavlo, крутого преподавателя и исследователя мира БД из Carnegie Melon University. Ниже краткое саммари основных моментов

🐘 PostgreSQL правит бал
Доминирование PostgreSQL продолжается и именно вокруг Postgres сосредоточена большая часть энергии и инноваций в СУБД.
В 2025 это подтвердилось громкими сделками:
- Databricks купил облачный PostgreSQL-сервис Neon (~$1 млрд)
- Snowflake – Crunchy Data ($250 млн)
- Microsoft запустил свой PostgreSQL-DBaaS (HorizonDB)

Появились проекты масштабирования Postgres по горизонтали (шардинг):
- Supabase нанял соавтора Vitess для проекта Multigres
- PlanetScale анонсировал систему Neki – Postgres-на-стероидах для больших нагрузок
Pavlo приветствует эту волну "шардированного Postgres", хотя напоминает, что попытки сделать масштабируемый Postgres предпринимались и раньше.

🤖 MCP для LLM в каждый дом
Если 2023-й был годом "векторных индексов" в каждом движке, то 2025-й – годом поддержки Anthropic MCP (Model Context Protocol) во всех СУБД. После поддержки OpenAI этого протокола практически каждый вендор выпустил MCP-сервер к своей базе – от OLAP-систем (ClickHouse, Snowflake и др.) до NoSQL (MongoDB, Neo4j, Redis); а провайдеры PostgreSQL‑DBaaS написали свои реализации. По мнению Andy Pavlo появление такого стандарта взаимодействия ИИ с БД - это благо, но стоит нужно ограничивать и мониторить эти реализации (например, только read-only запросы, лимиты на результат и таймауты), иначе рано или поздно случится факап

⚖️ MongoDB против FerretDB – судный день?
Впервые за историю индустрии СУБД одна компания подала в суд на другую за имитацию её API. MongoDB, Inc. обвинила стартап FerretDB (прокси, переводящий запросы MongoDB в PostgreSQL) в нарушении авторских прав, патентов и лицензии. Andy Pavlo сравнивает этот иск с процессом Oracle vs Google за Java API – тогда суд встал на сторону свободной реализации. Исход дела неясен, но есть пикантный нюанс: FerretDB изначально назывался "MangoDB". Интересно, что параллельно Microsoft в 2025 открыла исходники собственной Mongo-совместимой базы DocumentDB (передав проект в Linux Foundation) – то есть фактически занялась тем же, в чём Mongo обвиняет FerretDB.

📁 Война форматов данных
Почти 15 лет формат Parquet царил в колонночных хранилищах, но в 2025 сразу пять новых open-source форматов бросили ему вызов (ещё несколько появились в 2024-м). Среди них – проекты от академиков (FastLanes, F3, AnyBlox), стартапов (Vortex от SpiralDB) и гигантов (Microsoft Amudai, правда, его тихо прикрыли к концу года). Сообщество Parquet встрепенулось и взялось за модернизацию стандарта. Andy Pavlo отмечает, что главная проблема Parquet – не в самом формате, а в фрагментации реализации: слишком много парсеров/писателей в разных языках, поддерживающих разный поднабор фич. В результате 94% файлов «в живой природе» до сих пор созданы с фичами v1 образца 2013 года. Никто не будет переписывать петабайты старых паркет-файлов, да и невозможно быть уверенным, что любая система прочитает новейший файл – вдруг ей не хватит поддержки специфичных опций. Новые форматы пытаются решить проблему совместимости по-разному. Например, формат F3 (разрабатываемый в том числе при участии Pavlo) встраивает в каждый файл собственные декодеры: и в виде нативных модулей, и в виде WASM-кода, лежащего прямо в файле. Идея в том, что база данных сможет прочесть колонку даже нового, незнакомого формата – исполнив прикреплённый WASM-декодер. Другие (AnyBlox) генерируют единый WASM для всего файла. Пока неясно, чей подход победит – Parquet повсеместен, и инерция огромна. Следующее сражение развернётся за поддержку GPU в форматах, прогнозирует Pavlo, но одно ясно уже сейчас: битва за эффективное хранение данных вошла в новую фазу.

В продолжении я расскажу про остальные пункты.

#Database #Architecture #Management #DistributedSystems #Software #Engineering #Future

[2/2] Databases in 2025: A Year in Review by Andy Pavlo (Рубрика #Databases)

Продолжая рассказ об обзоре рынка баз данных от Andy Pavlo, расскажу про оставшиеся тезисы.

💸 Деньги, слияния и поглощения
2025-й оказался богат на крупные сделки в мире данных
- Продолжилась охота на PostgreSQL-компании: Neon ушёл к Databricks, Crunchy Data – к Snowflake (за $250 млн)
- IBM не остался в стороне и забрал себе DataStax (Cassandra) примерно за $3 млрд
- Salesforce раскошелился на старейшую ETL-платформу Informatica (~$8 млрд)
- Даже MariaDB Corp. умудрилась в том же году дважды купить «саму себя» – вернув под своё крыло отколовшуюся облачную дочку SkySQL
- Неожиданностью года стало слияние Fivetran и dbt Labs – две взаимодополняющие компании объединились в ETL-колосс, метящий на скорый IPO

📉 Инвесторы охладели к новым СУБД
Хайп вокруг векторных баз спал, венчуры в 2025 меньше инвестировали в молодые DB-стартапы, предпочитая нести деньги в AI. Зато лидеры отрасли продолжают получать огромные раунды:
- Databricks привлёк $5 млрд (два раунда) за год
- ClickHouse – $350 млн
- Supabase – суммарно $300 млн (Series D + E)
- И даже совсем молодые проекты вроде SpiralDB (создатели Vortex) поднимают десятки миллионов.

💀 Не все выжили
Ряд компаний не пережил этот год
- Закрылся FaunaDB – амбициозный распределённый СУБД‑стартап с сильной консистентностью (Pavlo был у них техконсультантом и советовал добавить SQL, но его не послушали)
- Проект PostgresML (машинное обучение внутри PostgreSQL) тоже не взлетел
- Команда Hydra (коннектор DuckDB↔️Postgres) разбрелась кто куда
- Даже классика: Apache Derby (Java-СУБД с 1997 года) объявлен "read only" – разработка остановлена за отсутствием мейнтейнеров.
GPU-базы данных тоже постигла нелёгкая судьба
- Стартап-супергруппа Voltron Data с инвестициями $110M так и не успела выпустить свой GPU-ускоренный движок Theseus
- HeavyDB (ранее OmniSci/MapD, пионер GPU-СУБД) тихо прекратил самостоятельное существование – команду поглотила Nvidia
Andy Pavlo резюмирует: нишевые решения вроде Kinetica и Sqream по-прежнему где-то на периферии, а заметно потеснить классические CPU-ориентированные СУБД GPU-решения пока не смогли. Производительность современных колонночных систем на CPU уже настолько высока, что решающее значение имеют не сырые оптимизации, а удобство для разработчиков и «умность» оптимизатора запросов. Впрочем, Pavlo намекает, что в 2026-м мы услышим о новых попытках задействовать GPU на полную мощность – гонка продолжается.

🏆 Ларри Эллисон – вершина успеха
Для основателя Oracle этот год стал поистине триумфальным. В 81 год Ларри Эллисон возглавил список богатейших людей планеты, впервые «коронованный» как самый богатый человек в мире (состояние оценивалось около $393 млрд). Oracle взлетел в цене благодаря облачным сделкам в сфере ИИ, и в сентябре 2025 акции Oracle выросли на 40% за день, сделав Эллисона не только №1 в мире, но и самым богатым человеком в истории (с поправкой на инфляцию обошёл даже Рокфеллера). Правда, спустя пару месяцев стоимость Oracle откатилась и Ларри потерял порядка $130 млрд – в масштабе миллиардера это как для нас с вами лишиться одной зарплаты, шутит Pavlo. В течение года Oracle/Эллисон засветились в крупных событиях: Oracle выступил ключевым партнёром в сделке по «американизации» TikTok и финансировал попытку поглощения Warner Bros (через принадлежащий семье Эллисона холдинг Paramount). Andy Pavlo признаётся, что был даже рад услышать новость о том, что “благодаря базам данных кто-то стал самым богатым на земле” – наконец в нашей сфере случилось нечто позитивное. Он иронизирует над критиками Эллисона: мол, Ларри уже завоевал мир корпоративных баз данных, выиграл регаты и построил сеть люкс-спа для техно-богачей, так почему бы ему не купить новостной телеканал? Эллисон не обращает внимания на разговоры, делает что хочет – фанаты и новая жена его поддерживают, а остальное неважно.

#Database #Architecture #Management #DistributedSystems #Software #Engineering #Future