[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

ТОП-10 финтехов в мире по их капитализации (Рубрика #Fintech)

Я с большим интересом слежу развитием и планами мировых бигтехов, но внезапно понял, что не уделяю похожего внимания игрокам с более близкого мне рынка финансов. В этом посте я решил это исправить и рассказать про ТОП-10 финтехов. Для каждой компании приведены сведения о капитализации, годе основания, числе сотрудников, ключевых бизнес-продуктах, особенностях ИТ-инфраструктуры и планах развития. Получился такой список в формате: название (год основания), капитализация в млрд USD, штат, какой основной продукт (одним предложением), где инфра (своя vs cloud или гибрид), какой план развития

1. Visa (1958), 694 млрд USD,, 31k сотрудников, глобальная платежная система, 4 собственных ДЦ + интеграции с облаками для клиентов, рост за пределами карточного бизнеса
2. Tencent (1998), 607 млрд USD, 105k сотрудников, суперприложение WeChat с мобильными платежами и финуслугами, собственная облачная платформа Tencent Cloud + гиперскейл дата-центры, глобальная экспансия финтех-продуктов
3. Mastercard (1966), 529 млрд USD, 35k сотрудников, мультирейл платформа для карточных и мгновенных платежей, частное облако + AWS/Azure, рост с фокусом на open banking и аналитику
4. Intuit (1983), 185 млрд USD, 18k сотрудников, SaaS-платформа для налогов и бухгалтерии (TurboTax, QuickBooks), полностью в AWS, ставка для роста на генеративный ИИ
5. Stripe (2010), 91 млрд USD, 8.5k сотрудников, API-инфраструктура для онлайн-платежей и финуслуг, облачная архитектура (AWS), план расширения в офлайн и на международные рынки
6. Fiserv (1984), 88 млрд USD, 38k сотрудников, процессинг и IT-сервисы для банков и ритейла, гибридная ИТ-инфра (legacy + облако), план в модернизации платформ и экспансии POS-бизнеса
7. Ant Group (2014), 79 млрд USD, 16.6k сотрудников, Alipay и экосистема финуслуг в Китае, облако Alibaba + своя OceanBase, план экспансии вне Китая Alipay+ и финтех B2B-сервисов
8. PayPal (1998), 70 млрд USD, 24k сотрудников, глобальная система онлайн-платежей и кошелек (включая Venmo), гибридная ИТ (ДЦ + GCP/Azure), ставка на AI, крипто и офлайн-коммерцию
9. Nubank (2013), 63 млрд USD, 7.7k сотрудников, цифровой банк №1 в Латинской Америке, облако AWS, экспансия по ЛатАм и запуск финтех-платформы
10. Coinbase (2012), 62 млрд USD, 3.7k сотрудников, криптобиржа и кастодиальные сервисы, облачная архитектура + собственные ноды, глобальный рост и развитие Coinbase Cloud

Итого, видим, что у нас есть
- 2 компании старого толка с собственными ДЦ: Visa, Mastercard. Они живут в своих ДЦ + подключают облака или для удобства подключения клиентов или для новых нагрузок типа AI
- 2 компании с гибридным подходом: PayPal, Fiserv. Они сочетают свои серверы и облачные мощности. Например, PayPal переносит значительную часть сервисов в Google Cloud, оставаясь в гибридной модели
- 4 компании поверх облаков: Stripe, Nubank, Coinbase, Intuit. Первые три изначально строились как cloud-native, а последний переехал в облако в районе 2018 года
- 2 финтеха поверх бигтеха: Tencent (WeChat Pay) и Ant Group (AliPay). Они живут поверх облаков от своих бигтех родителей: Tencent Cloud и Alibaba Cloud, а значит могут практиковать вертикальную интеграцию, как hyperscalers

#Infrastructure #Architecture #Fintech #Strategy #Engineering #Software #DevOps

Code of Leadership #57 - Interview with Pavel Golubev, Principal DS at Microsoft, about DS & AI (Рубрика #AI)

Интервью с Павлом Голубевым, principal data scientist в Microsoft, который как и я когда-то закончил Физтех. Но дальше Паша ушел в консалтинг и оптимизировал цепочки поставок, а дальше двинулся в сторону data science. В какой-то момент он оказался зарубежом, где успел поработать над аналогом Uber из Греции (Beat), EPAM, а потом перейти в Microsoft и заняться DS проектами для клиентов Azure в EMEA. 

За 2 часа и 40 минут мы обсудили множество тем, среди которых следующие
- Знакомство с Павлом: Principal DS в Microsoft NL, индустриальные решения (энергетика/производство)
- Ранний путь: арабистика МГУ → первый разворот к аналитике
- Переход в IT: Женева, математика/статистика/программирование, MATLAB
- Возвращение в РФ: аналитика цепей поставок в Renault
- Консалтинг «в поле»: ТЭЦ, ручные журналы, наблюдение за процессами
- Рост компетенций: Python, курсы, ODS, статья на Хабре → новые офферы
- Кейсы из консалтинга: DSS с PPR, смарт-контракты, оптимизация распределения еды
- Reaktor и Ближний Восток: длинные продажи, «глянцевые» решения, специфика рынка
- Спад рынка/пандемия: сокращения инвестиций, закрытие офиса в Дубае
- Поиск в Европе: офферы, выбор Нидерландов («ruling»), переход в Beat
- Beat в Латам: безопасность, антифрод, «пирамида фрода» и профайлинг нарушителей
- Ошибки роста и крах Beat: Tesla, маркетинг, монолит, регуляторика → банкротство
- Мост через Epam: менеджерские проекты, осознанный поиск более амбициозной роли
- Microsoft: работа в Solutions Engineering, проекты, реструктуризации и переход в Principal Engineer из менеджерской ветки

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

P.S.
Паша ведет интересный канал https://t.me/corporateAI

#AI #DS #Career #Staff #Engineering #Software #Management #Leadership

[2/3] Google's AI‑powered next‑generation global network: Built for the Gemini era - Вызовы на сети в эру AI (Рубрика #Infrastructure)

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

1. WAN как новая LAN
Обучение современных foundation models требует объединения тысяч TPU/GPU. И то, что раньше размещалось в пределах одного датацентра, теперь распределено географически (континент как датацентр - примерно тот же посыл у запрещенной в России Meta). Сеть должна масштабироваться на порядок больше прежнего, чтобы связать удалённые кластеры так, словно они в одном локальном сегменте. При этом трафик от распределённого обучения идёт всплесками, которые нужно эффективно обнаруживать и маршрутизировать без потери производительности.

2. Нулевая терпимость к сбоям
Процессы обучения моделей ИИ и крупномасштабный inference очень чувствительны к перебоям. Остановка обучения из-за сетевого сбоя - неприемлема из-за простев дорого железа. От сети теперь ожидают практически 100% доступности, без ощутимых перерывов, а значит сеть должна быть спроектирована так, чтобы любые отказоустойчивые механизмы срабатывали мгновенно и вообще не влияли на долгий процесс обучения.

3. Повышенные требования безопасности и контроля
Данные, на которых обучаются модели, и сами модели - ценный и чувствительный ресурс. Их нужно защищать как от утечек, так и от несанкционированных изменений. Кроме того, по мере распространения ИИ растут требования к соблюдению региональных регуляторных норм и к контролю данных "на лету" (в транзите). Сеть должна обеспечивать изоляцию, шифрование, соответствие политикам разных стран и компаний, чтобы ИИ-сервисы оставались надёжными и законопослушными.

4. Операционное совершенство при возросшей сложности
Масштаб, растущий на порядок, не может управляться по-старому. Google применяет лучшие практики SRE и уже использует машинное обучение для управления сетью, но теперь ставится цель минимизировать человеческий фактор. Сеть должна работать с минимумом ручного вмешательства, потому что линейное наращивание инфраструктуры иначе приведёт к неуправляемому росту сложности и затрат. Новые подходы требуются для автоматизации, быстрого выявления и устранения проблем, оптимизации емкости.

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

#Software #DevOps #Architecture #Economics #DistributedSystem #SystemDesign

[3/3] Google's AI‑powered next‑generation global network: Built for the Gemini era - Новые принципы дизайна сетей (Рубрика #Infrastructure)

Продолжая рассказ про эволюцию сетей Google, стоит рассказать про то как новые подходы к архитектуре сетей решает вызовы, озвученные в прошлом посте

1. Экспоненциальная масштабируемость
Сеть должна гибко выдерживать лавинообразный рост трафика и данных, особенно в регионах, где сосредоточены ИИ-вычисления. Принцип "WAN - это новая LAN" реализуется через отказ от монолитна в пользу горизонтального масштабирования (архитектура multi-shard network). Шарды независимы - у каждого свой набор контроллеров и каналов. Это позволяет параллельно наращивать пропускную способность - с 2020 по 2025 год пропускная способность глобального WAN Google увеличилась в 7 раз. Кроме того, такая сегментация упрощает управление: каждая «шардинговая» подсеть более контролируема по размеру.

2. Надёжность выше традиционных “пяти девяток”.
В индустрии обычно говорят о 99.9% или 99.99% доступности, но для критичных AI нагрузок выжны long tail выбросы (нужен детерминизм и бесперебойная работа сети). На практике сеть должна локализовать проблемы и автоматически их обходить до того, как пользователи или процессы заметят сбой. Для этого
- Шарды изолированы друг от друга (сбои не кореллируют)
- Дополнительно введена изоляция по регионам, чтобы локальные неполадки не каскадировались глобально
- Создана технология Protective ReRoute для быстрого обнаружения потерь связи и перенаправления трафика за секунды
После включения Protective ReRoute суммарное время простоев по инцидентам сократилось на до 93%.

3. Программируемость, управляемая намерениями (Intent-driven programmability)
Сеть Google обслуживает миллиарды пользователей и множество корпоративных клиентов с разными требованиями, например
- Кому-то критична задержка
- Кому-то важно шифрование
- А кто-то должен географически раскидывать данные (с учетом регуляторики)

Для удовлетворения таких разных требований ребята сделали сеть полностью программируемой (SDN) на основе высокоуровневых политик (intent), то есть созданы
- Единые модели представления сети (например, модель MALT - Multi-Abstraction-Layer Topology)
- Открытые API для управления
- Централизованные SDN-контроллеры, которые могут трактовать намерения операторов или приложений и применять их к сети.
Такая гибкость позволяет задать политики для конкретных приложений или данных (например, чтобы определённый тип трафика шёл только через узлы в заданной стране для соблюдения суверенитета данных, или чтобы критичные сервисы всегда имели резервные каналы). А высокоуровневое управление не требует ручного конфигурирования (как в SQL достаточно указать что нужно, а умная сеть подстроится под запрос)

4. Автономная сеть
Сети уже прошли путь вида: ручное управление -> автоматизированное (скрипты) -> автоматическое (по жестким правилам). Новая цель в том, чтобы сделать сеть самоуправляемой при помощи машинного обучения и "цифрового двойника", где модели постоянно обучаются на телеметрии.Так сеть сможет симулировать и предвидеть сбои, быстро локализовать причину неполадок и даже оптимизировать планирование ёмкости каналов на будущее.
После внедрения этих инструментов время реакции на сбой сократилось с часов до минут, что существенно повысило эффективность и устойчивость работы сети без участия человека.

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

В последнем посте мы сравним эту стать/ про инфру от Google и статью от запрещенной в России Meta.

#Software #DevOps #Architecture #Economics #DistributedSystem #SystemDesign

WebSummit Lisbon (Рубрика #Conference)

В начале лета мы с женой сгонять на WebSummit в Португалию и купили early-bird tickets. Дальше мы купили билеты на самолет, забронировали отель и подали визу. Сегодня ночью мы должны были вылетать, но ... визовый центр Португалии вместе с консульством не смогли за четыре с половиной месяца рассмотреть заявление на визу и ответить да/нет. Правда, полторы недели назад нам пришлось забрать паспорта для полета на Мальдивы с детишками, но нам сказали вернуть паспорта 5 ноября обратно в визовый центр, чтобы успеть получить штампики 7 ноября. Сегодня 7 ноября, все сроки возврата по билетам и брони прошли, а паспортов нет ... В итоге, поездка на WebSummit сорвалась, денег не вернуть, настроение испорчено. Я отношусь к этому философски - примерно по этой же схеме мы с женой и детьми уже год ждем визу в Канаду, где тоже не могут ответить да/нет, правда, там электронная виза и паспорта не забирают.

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

#Conference

Фильм "WeWork: Or the Making and Breaking of a $47 Billion Unicorn" (Рубрика #Economics)

Пока летел восемь часов с Мальдив я прочитал несколько глав книги "Hands-On Large Language Models", а также посмотрел этот фильм про WeWork, который мне зашел как и многие другие документальные фильмы (см. список). Но это примечательная история провала, примерно как с Theranos, о которой я рассказывал раньше. Мне и во времена рассвета WeWork схема казалась слишком амбициозной, а при просмотре меня не покидало ощущение, что вся внутренняя культура была похожа на секту, которая прошла разные этапы

Начало мечты: коворкинг под видом tech-единорога
История WeWork началась в 2010 году, когда Адам Нейманн и Мигель МакКелви открыли первый коворкинг WeWork в Нью-Йорке. Нейманн, харизматичный выходец из израильского кибуца, с самого начала продавал не просто офисные метры, а мечту о глобальном сообществе единомышленников - этакой "первой физической социальной сети". Цель была в том, чтобы инвесторы поверили, что это не банальная аренда столов, а технологический стартап, меняющий мир. Это сработало и приватная оценки взлетела до $47 млрд - тут помог фонд SoftBank во главе с Масаёси Сон, который щедро вкладывал миллиарды в визионерские обещания Нейманна, а сами сотрудники верили, что «меняют мир» вместе с основателем. Однако уже тогда бизнес-модель вызывала вопросы: по сути, WeWork арендовала недвижимость по долгосрочным договорам и пересдавала мелким клиентам на короткий срок.

Пик ценности и крах
К 2019 году WeWork готовилась к триумфальному IPO с оценкой всё тех же ~$47 млрд. Однако публике достался проспект эмиссии, который отрезвил даже самых верующих. В документе всплыли гигантские убытки, сомнительное корпоративное управление и эксцентричные выходки Нейманна. Инвесторы и СМИ начали задавать неудобные вопросы о том, на чём же основана такая оценка и где прибыль ... оценка рухнула с $47 млрд до ~$10 млрд, а самого Нейманна вынудили оставить пост CEO и отказаться от контроля -SoftBank выплатили золотой парашют Адаму (~$1,7 млрд), а вот опционы сотрудников превратились в дырки от бубликов.

После: чем стал WeWork
После драматичного 2019 года WeWork попытался реанимироваться под новым руководством. В 2021-м стартап все же выполз на биржу через слияние с SPAC (с капитализацией в ~$9 млрд), но бизнес-модель оставалась уязвимой. Пандемия COVID-19 нанесла коворкингам удар: клиенты съезжали, офисы пустели, а у WeWork на балансе висели многомиллиардные обязательства по аренде. Компания закрывала локации, сокращала сотрудников, пыталась перекроить долги. Но в ноябре 2023 года, спустя четыре года после несостоявшегося IPO, WeWork официально подала заявление о банкротстве для проведения реструктуризаци

Чем занят основатель сейчас
Адам же, получив свои деньги, ненадолго пропал из новостей, но уже через пару лет снова напомнил о себе. В 2022 году Нейманн объявил о новом стартапе под названием Flow, который будет управлять арендой жилой недвижимости - крупный фонд Andreessen Horowitz вложил в Flow около $350 млн, оценив компанию более чем в $1 млрд еще до запуска

Урок: не всё, что называет себя "tech", является им
Сказка о WeWork наглядно показала, что не каждая компания, мнящая себя "технологической", действительно ей является. WeWork с самого начала был по сути девелоперским бизнесом, прикидывающимся айтишным, но наличие красивого приложения или крутых тусовок для резидентов не отменяет старых добрых законов экономики. Если у компании нет устойчивой модели прибыли, рано или поздно пузырь сдуется - как и произошло. Подобные случаи мы уже видели в эпоху доткомов: тогда интернет-компании тоже получали астрономические оценки без реальных доходов. Например, знаменитый онлайн-зоомагазин Pets.com в 2000 году вышел на биржу по $11 за акцию, но всего через несколько месяцев акции упали ниже $1, а вскоре фирма и вовсе закрылась, уволив сотни сотрудников (на момент ликвидации цена акции была $0,22). WeWork стал “pets.com” своего времени - символом того, как опасно верить исключительно в хайп.

#Economics #Software #Startup #Management #Leadership

Сравнение подходов Google и Meta к построению сетей и инфры (Рубрика #Architecture)

В этом посте я решил сравнить подходы Google запрещенной в России Meta к своей сетевой архитектуре. Суть в том, что обе эти компании в 2025 году написали статьи на тему того, как инфра меняется с учетом вызовов эры AI и я до этого разобрал обе
- Meta’s Hyperscale Infrastructure: Overview and Insights
- Google's AI‑powered next‑generation global network: Built for the Gemini era

Если обобщать, то обе компании сходятся во взгляде, что их глобальная инфраструктура должна работать как единый организм. У них похожи даже девизы
- Google: WAN – это новая LAN, континент стал датацентром
- Meta: все глобальные датацентры – это один компьютер

Но при реализация акценты у Google и Meta различаются:

1. Масштаб сети и для кого она
И Google, и Meta построили собственные глобальные сети на оптоволокне, связывающие датацентры напрямую, вместо зависимости от публичного интернета. Оба стремятся разместить узлы ближе к пользователям (кэши, PoP) для низких задержек. Но Google делает для себя и клиентов Google Cloud, а Meta только для себя и своих продуктов

2. Архитектура масштабирования
Подходы компаний к масштабируемости сети WAN очень схожи по концепции, хотя реализованы своими методами
- На уровне LAN внутри ДЦ все похоже и oversubscription нет - обе компании используют масштабируемые фабричные топологии (Clos/fat-tree) и добавляют коммутаторы на верхних уровнях
- На уровне WAN у Google шарды, у Meta отдельные planes, но у Google на уровне WAN нет oversubscription, а у Meta есть (а это влияет на возможность/невозможность распределенного обучени foundation models)

3. Надёжность и обновления
У обеих компаний сеть спроектирована с идеей локализации проблем и быстрого самовосстановления, но
- Google говорит об автономной сети - автоматическом реагировании самой сети на проблемы. Задача в том, чтобы сделать ультра-высокую надежность (beyond 9s) и для этого нужна автономная система, что обладает selfhealing возможностями
- Meta говорит об автоматизациях сетевой конфигурации - возможности быстро менять конфигурацию и софт без ущерба работе. То есть здесь закрыт уровень автоматизации, но изменения должен инициировать человек

4. Интеграция с AI-нагрузками
Оба гиганта осознают, что искусственный интеллект диктует новые требования к инфраструктуре. Однако подходы проявляются по-разному.
- У Google сеть позволяет делать распределенные тренировки и они могут горизонтально масштабироваться
- У Meta сеть позволяет распределенно гонять все нагрузки, кроме тренировок больших моделей. Там ребята ориентируютсяй на масштабирование через scale-up внутри ДЦ. Дальше они планируют допилить сеть для возможностей распределенных тренировок

5. Программируемость решений
Оба игрока применяют принципы software-defined networking и автоматизации управления. Но есть и разница
- У Google много разных клиентов (с учетом Google Cloud), поэтому им нужно было удобное централизованное управление политиками сети для разных задач (будь то обслуживание cloud-клиентов или внутренних сервисов)
- У Meta также центральные контроллеры для управления сетью - они постоянно оптимизируют распределение трафика от пользователей (PoP) к датацентрам с учётом загрузки и задержек, а в самих датацентрах контроллер может изменять маршруты при перегрузках или сбоях.

Итого, Google и Meta идут параллельными курсами: они решают схожие задачи гипер-масштабной сети, иногда разными методами, но общая цель одинакова - сеть, способная связать весь мир в единый “компьютер” для своих услуг и будущих AI-приложений. Но вот подход компаний к публикации результатов сильно отличается
- Google публикует научные статьи и продает коммерческие сервивсы, но не публикует код инструментов или дизайн железа
- Meta активно делится дизайнами аппаратного обеспечения через сообщество Open Compute Project, а также публикует многие свои наработки: фреймворки, базы данных

#Software #DevOps #Architecture #Economics #DistributedSystem #SystemDesign

„Я понял, что это конец“: как создатель „Алисы“ уволился из „Сбера“, эмигрировал и строит AI‑стартап (Рубрика #AI)

Посмотрел интересное интервью Константина Круглова, что он дал Елизавете Осетинской, иностранному агенту. Сам гость в этом выпуске очень интерсные - Константин до отъезда из России успел поработать в Tinkoff Digital, где строил платформу для programmatic buying, в Yandex, где занимался Алисой, а также в SberDevices, где тоже делал железо для колонок и голосовых ассистентов. После событий 22 года он уехал зарубеж и соосновал Aiphoria, enterprise‑платформа голосовых AI‑агентов. Кстати, это популярная тема - например, Брет Тейлор рассказывал о том, что строит сейчас такую платформу Sierra, а он ex-CTO Meta, ex-CEO Salesforce и ex-председатель правления OpenAI:)

Интервью длилось почти два с половиной часа, поэтому обо всем рассказывать не буду, но подсвечу интересные мысли для инженеров и фаундеров технологических стартапов, которые можно извлечь из него
1. Как делали железо и почему это урок про скорость
Константин рассказал про запуск колонки в Яндексе
- Битва за долю рынка, а не за технологическую чистоту. Идея "умной колонки" родилась как ответ на возможный заход Amazon в РФ
- Инженерные ходы, что применялись при разработке: реверс‑инжиниринг существующих устройств; покупка и доработка технологии (Cubic AI) для построения микрофонной решётки, многомесячный кранч, чтобы отработать технологию
- Итог - работающее устройство, устойчивый спрос
2. Оргдизайн и "скорость принятия решений"
Гость сравнил между Яндекс и Сбер с точки зрения культуры
- Яндекс: горизонтальная организация, высокое трение между командами - приходится «продавать» фичу каждому соседу.
- Сбер: «отточенная немецкая машина» - вертикаль, где решения и имплементация могут идти быстрее; при этом лидер (Греф) лично в теме и помнит контекст.
Мне кажется, что гость оценивает Сбер по тому, как он работал с топ-приоритетом Грефа, когда на его инициативы была зеленая волна - именно это обеспечивало скорость изменений:) А что бы было, если бы это не было топ-темой?
3. Причины отъезда из России
Были личные причины, но гость их не назвал, а вот про рабочие поговорил. Ему была важно, что он занимается фронтир вещами, а после 24 февраля это уже не реально. В итоге, за несколько дней он принял решение сменить среду на ту, где есть плотность талантов, капитала и заказчиков.
4. А про что стартап Aiphoria, который соосновал гость
Это платформа enterprise‑класса для голос‑first AI‑агентов: голосовые агенты, агенты в мессенджерах и email. Есть поддержка разных языков, on-prem для заказчиков типа банков, примеры сценариев для автоматизации: поддержка клиентов, взыскания, продажи, рекрутинг и др. Стратегией запуска было сначала доказать бизнес‑ценность на продакшене и выйти в прибыль, потом привлекать капитал под масштабирование.

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

#Startup #AI #Engineering #Leadership #Software

Extreme DevOps Automation - доклад от Revolut на QCon 2025 (Рубрика #PlatformEngineering)

Интересный доклад c QCon 2025 от Sérgio Amorim про работу их DevOps команды. Суть в том, что у ребят из Revolut практичный подход к своей платформе разработки - они плотно сидят на Google Cloud, одновременно добавляя кастомные автоматизации сверху. При таком подходе у них получается, что 15 инженеров могут поддерживать масштаб порядка 1.3к инженеров, 1.2к микросервисов и 1.1к баз данных (что ребята из платформенной команды поддерживают сами). В итоге, получается чуть меньше 1 сервиса и 1 бд на одного инженера:)

Для управления всем этим используется три столпа
- Каталог сервисов в виде внутреннего решения Tower - это главный источник истины
- Паттерны и стандарты для унификации подходов
- Автоматизации GitOps при помощи внутренней системы Rhea

А теперь давайте подробнее глянем под капот
1. Tower (каталог сервисов IDP)
Здесь существует минимальный набор параметров для сервиса: стек (Java/Python/Scala/ML), владелец, связи с БД/сервисами, окружения, критичность (tier), SLO, стоимость, "качество метаданных" и пр. В итоге, это не "статичная CMDB", а портал, откуда начинается управление и в который возвращается обратная связь (качество, аптайм, стоимость). Меньше полей - выше заполненность и точность данных → тем надёжнее автоматика.
2. Паттерны как "сужение свободы" ради скорости и соответствия
Малое число поддерживаемых стеков и шаблонов развёртывания. Это повышает повторяемость, упрощает владение и даёт выигрыш в соответствие требованиям - стандартизация автоматически реализует корпоративные и регуляторные правила
3. Автоматизация как Control Plane
Rhea «транспилирует» данные из Tower в коммиты (реализуя подход GitOps):
- генерирует пайплайны TeamCity и права на деплой для нужных команд (~10к управляемых пайплайнов)
- создаёт политики доступа к секретам (Vault) ровно по зарегистрированным связям сервис↔база (~37к политик секретов)
- создаёт ресурсы в Kubernetes/облаке
- формирует шаблонные алерты/дашборды/правила (~20к стандартных алертов и ~3к кастом‑алертов)
Всё это - без ручных действий команд

Для сервисов важен и вопрос observability - все начинается со SLO, которые тоже настраиваются в Tower, дальше автоматика генерирует стандартизованные алерты по сервисам и БД, а внутренний диспетчер шлёт единообразные сообщения в Slack командам‑владельцам. Слишком "шумные" системы признаются техдолгом: при накоплении баг‑тикетов включается стопор изменений до улучшения стабильности (этакая реализация error budget). Кстати, у сервисов всего 4 типовых уровня доступности (99.99/99.9/99.8/99.5)

Отдельно автор доклада рассказал про управление базами данных, а точнее Postgres, для которых не используются managed решения от Google, а команда DevOps сама оперирует ими, чтобы катать спокойно мажорные обновления СУБД + играть с репликами как хочется.

Если проанализировать устройство платформы, то можно отметить, что это работает из-за ряда факторов
- Минимальная платформа поверх облака - можно использовать облачную инфру провайдера, а поверх делать только необходимое
- Governance вшит прямо в happy path платформы - важные правила (SLO, алерты, секреты, права) применяются автоматически, потому что единственный удобный путь запуска системы - через каталог и паттерны. Ничего "донастраивать руками" не нужно и часто нельзя.
- Каталог систем + GitOps. Tower фактически становится "API компании" для всего инженерного ландшафта. Один набор артефактов порождает пайплайны, политики, ресурсы и мониторинг. Это снижает расхождение реальности и деклараций.
- Стандарты на масштабе ускоряют, а не тормозят. Ограничение стеков + шаблоны деплоя убирают вариативность, ускоряя онбординг и снижая операционный риск.
- SLO/алерты как механизм управления продуктом. Унифицированный шумомер и error‑budget freeze принуждают команды держать стабильность, а не "продавливаться" релизами любой ценой.
- Фокус DevOps‑платформы - не "поддержка руками", а инжиниринг инструментов и продуктовая работа над DX.

#Software #Engineering #Management #Architecture #Processes