[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

ТОП-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