[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

[2/2] The History of the Future: Oculus, Facebook, and the Revolution That Swept Virtual Reality (Oculus. Как создать лучшую в мире VR компанию и потерять все?) (Рубрика #Games)

Продолжая рассказ про книгу "The History of Future" надо рассказать про основную канву истории

Палмер Лаки начал с мечты о доступном VR-шлеме. Будучи подростком, он коллекционировал старые гарнитуры виртуальной реальности и видел их недостатки - узкий угол обзора, низкое разрешение и высокую цену. В своем трейлере во дворе родительского дома Лаки экспериментировал с линзами и дисплеями, и в итоге создал прототип Oculus Rift с широким углом обзора ~90° и малой задержкой обновления картинки.

Прорывом стал 2012 год. Лаки активно общался на форумах VR-энтузиастов и однажды получил личное письмо от кумира детства - Джона Кармака, где тот попросил выслать ему прототип Rift. Джон был настолько впечатлен им, что показал Rift в действии на выставке E3 2012 при демонстрации Doom 3 BFG Edition. Эта демонстрация вызвала интерес к проекту. Вокруг Лаки сформировалась команда единомышленников: к нему присоединились Брендан Ирибэ, Нейт Митчелл и Майкл Антонов, решившие основать компанию Oculus VR для развития технологии. В августе 2012 они запустили кампанию на Kickstarter, предлагая VR-гарнитуру для разработчиков игр (собрали 2.4m $).

Успех Kickstarter привёл к приходу крупных инвесторов. В 2013 году Oculus получил $75 млн от венчурных фондов во главе с Andreessen Horowitz. Лаки отвечал за технологию, а управление финансами и ростом взяли на себя Ирибэ и профессиональные инвесторы. К Oculus присоединились новые звёзды: Джон Кармак (ex id Software) и Майкл Абраш (ex Valve), что подчеркнуло серьёзность намерений команды. В течение 2013 года Oculus выпустил несколько версий devkit’ов Rift для разработчиков, и интерес к VR только рос.

Кульминацией взлёта стала покупка Oculus корпорацией Facebook в 2014 году. Марк Цукерберг лично посетил офис Oculus для демонстрации и был поражён: он назвал Rift "одной из самых крутых вещей, что я видел". В марте 2014 Facebook объявил о приобретении Oculus VR за ~$2 млрд (кеш и акции).Эта новость ошеломила отрасль: с одной стороны, гигантские ресурсы Facebook обещали ускорить развитие VR, с другой - часть сообщества встретила сделку настороженно. Тем не менее, финансовый успех был налицо: 21-летний Палмер Лаки попал на обложку Forbes, а его состояние оценили в ~$700 млн. Компания же стала подразделением Facebook, продолжив работу над потребительской версией Rift.

В 2016 году наконец вышел потребительский Oculus Rift CV1, ознаменовав начало новой эры VR-устройств на рынке. Однако вместе с достижениями нарастали и проблемы. Например, ZeniMax, бывший работодатель Кармака, предъявил иск, обвиняя Oculus в присвоении технологий VR. В 2017 году суд частично встал на сторону ZeniMax - сумма компенсации была $250 млн.

В том же 2016 году Палмер Лаки оказался в центре скандала - Лаки перевел 10к$ организации Nimble America, что разместила 1 билборд с карикатурой Хилари Клинтон. Также он под псевдонимом NimbleRichMan публиковал резкие политические комментарии. Для имиджа Oculus и Facebook (где руководство в основном придерживалось иных взглядов) это стало ударом. Facebook постарался минимизировать ущерб: Лаки принес публичные извинения, написав, что сожалеет о том, как его действия повлияли на репутацию Oculus. После этого основатель практически исчез из поля зрения, а весной 2017 года Палмер Лаки покинул Facebook/Oculus. Фактически, основателя вытеснили из созданной им же компании.

После увольнения Палмер Лаки недолго оставался в тени. В 2017 году, вскоре покинув Facebook, он основал новую компанию - Anduril Industries, выбрав для себя совершенно иную сферу деятельности. Anduril занимается разработкой высокотехнологичных систем безопасности и обороны - от автономных дронов-наблюдателей до стационарных башен слежения с ИИ. Стартап Лаки быстро получил поддержку инвесторов и правительственные контракты в США.

#Software #Hardware #Engineering #Management #Leadership #Startup #Strategy

10 years of engineering at Nubank: Lessons from scaling to 122+ million customers (Рубрика #Architecture)

Недавно прочитал статью про эволюцию NuBank за 10 лет от Lucas Cavalcant, Distinguished Software Engineer and Senior Architect. Эта история эволюции мне показалась интересной, поэтому я решил рассказать про lessons learned

Лидерство вне кода
Техническое лидерство требует не только писать отличный код, но и умения ясно доносить идеи, вдохновлять команду и направлять её к решению - особенно когда у вас нет формальных "рычагов" руководителя (это особенность staff+ ветки IC). По мере роста роли инженера - ему приходится заниматься стратегическим планированием, координировать несколько команд и принимать крупные технические решения. У нас в Т тоже есть такая ветка, о которой я много рассказывал.

Карьерный путь (техника vs менеджмент)
В первые годы Nubank инженеры работали в режиме выживания - проблемы возникали ежедневно, и каждый бросался их чинить. Лишь к 2017 году появились первые менеджеры, и многие сеньоры (включая Лукаса Кавалканти) тогда осознали, что им ближе трек IC (individual contributor) и компания это учла: в 2018-м Lucas стал первым Principal Engineer, а недавно поднялся до Distinguished Engineer.

Эволюция архитектуры под гиперрост
Масштабирование с нуля (в 2013 году) до десятков и сотен миллионов клиентов потребовало постоянных архитектурных переделок.
- Изначально система Nubank была написана на Clojure с базой Datomic и развёртывалась монолитно в AWS (CloudFormation + AMI). Подробнее в выступлении 2017 года на QCon. А про использование AWS здесь
- С ростом нагрузки перешли на Docker и Kubernetes, распилили монолит на микросервисы, а позже создали core-банкинг платформу, способную поддерживать множество продуктов в разных странах. Подробнее в статье 2019 года про микросервисы
- Международная экспансия внесла новые требования (локальные регуляции, языки и т.д.)
Но не все масштабные решения оказались долговечны: шардирование данных, введённое в 2016-м, сначала выручало, но в итоге уткнулось в физические пределы (AWS не успевало выдавать новые сервера). Сегодня, как отмечает спикер, для дальнейшего роста нужны уже принципиально новые архитектурные подходы.

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

Производительность команды без выгорания
Спикер делит свой путь на два этапа: ранние стартап-годы с бешеным темпом (постоянный "пожарный режим") и более структурированное настоящее, где выстроены процессы, не допускающие бесконечного тушения инцидентов. Его совет: на старте карьеры или продукта стоит выкладываться по максимуму, но постоянно так работать невозможно. Со временем Nubank сознательно улучшил work-life balance команд.

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

#Software #Engineering #Management #Architecture #Processes #Staff #SRE #DevOps

Как устроена инженерия в Uber (Рубрика #Engineering)

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

Инженерное крыло компании насчитывает 4к+ инженеров (в 2023 их было 4k) и распределено по всему миру. Инженерные команды делятся на две категории: “program” и “platform". Program команды полностью владеют своей частью продукта (как клиентской частью в приложении, так и необходимым бэкендом) и метриками его успеха. В свою очередь Platform-команды специализируются на развитиии универсальных технологических компонентов и инфраструктуры, которыми пользуются все продуктовые группы.

В 2023 году в Uber были большие перемены в IT - были созданы отдельные ветки под эти program и platform направления
- Правин Нага стал CTO по направлениям Mobility и Delivery, который курирует развитие всех пользовательских продуктов и приложений Uber с
- Альберт Гринберг стал VP по платформенной инженерии (раньше он работал VP в Azure). Он отвечает за общую техническую платформу, инфраструктуру, данные и инструменты.

Если говорить про архитектуру и инфраструктуру, то уже к 2016 году ребята распилили монолит на множество микросервисов, каждый отвечающий за свою функцию (поиск автомобилей, расчёт цены, профили пользователей, платежи, карты, уведомления и т.д.). Такая распределённая архитектура позволила командам развивать разные части системы параллельно и масштабировать их независимо. Однако она же требовала передовых решений для оркестрации, хранения данных и мониторинга - они создавали собственный "облачный" стек внутри компании. Например, в том же 2016 году ребята рассказывали как они разработали "Schemaless" - свой datastore с использованием MySQL. Дальше часть сервисов мигрировала в облака, например, Fulfillment платформа к 2021 году переехала на движок хранения в виде Google Spanner в GCP.

До начала 2023 года 95% нагрузок жили inhouse, а дальше пошел масштабный переезд в публичное облако, что было анонсировано в результатах Q1 2023 для инвесторов. Uber заключил стратегические соглашения с Google Cloud и Oracle Cloud на 7 лет, чтобы перенести свои серверные системы в облака этих провайдеров. Такой мультиоблачный подход выбран для повышения надёжности и гибкости. Кстати, в Oracle облаке они поехали на ARM-процессоры Ampere для сокращения костов и уже к 2024 году тысячи сервисов Uber мигрировали на Arm-архитектуру в Oracle Cloud, что дало выигрыш в соотношении цена/производительность и снизило зависимость от x86.

Backend архитектура построена вокруг контейнеризации и оркестратора, что позволяет разработчикам деплоить обновления сотни тысяч раз в неделю без простоев. В ходе переезда в облако Uber заменил устаревшую самописную систему деплоя (µDeploy) на новую multicloud платформу под названием “Up”. Благодаря этому к 2022 году в облако переехало 2+ mln 2 ядер, а также большинство сервисных команд абстрагировались от низкоуровневых деталей (т.е. для разработчиков деплой микросервиса теперь одинаков вне зависимости от среды: inhouse или cloud).

Развитие AI можно разделить на эпохи (подробнее в статье 2024 года):
1. Предиктивная ML (2016–2019) - упор на табличные задачи (ETA, риск, прайсинг) с XGBoost и зарождающиеся DL-кейсы (3D-маппинг, автопилот), запуск централизованной платформы Michelangelo и фичестора Palette
2. Масштабирование deep learning (2019–2023) - переход к DL как first-class citizen, унификация инструментов в Michelangelo 2.0, рост использования DL моделей (1+ mln rps)
3. Gen AI этап (с 2023) - LLM/GenAI для клиентского опыта и внутренней продуктивности, развитие LLMOps и GenAI Gateway с доступом к внешним и собственным моделям при сохранении единой платформы и MLOps-процессов.

В 2023 году компания запустила инициативу Uber AI Solutions, где предлагает своим корпоративным клиентам сервис по сбору и разметке данных для обучения моделей, а также тестированию AI-систем. А вот автономные машины Uber сам не развивает, а партнерится с внешними компаниями.

#Architecture #Management #Software #Leadership

Про Revolut (Рубрика #Business)

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

1) Куда движется Revolut (планы 2025–2027)
Компания открыла глобальный штаб в лондонском Canary Wharf и заложила инвестпрограмму на ~$13 млрд на 5 лет; целевой ориентир - 100 млн клиентов к середине 2027 года (в сентябре 2025 было 65 млн клиентов). Вектор роста: международная экспансия, продуктовые инновации, усиление B2B‑направления и партнёрства:
- Латинская Америка. В 2025 Revolut получил окончательное разрешение начать банковские операции в Мексике; в Колумбии - авторизацию на учреждение банка (первый из двух регэтапов).
- Индия. Официальный запуск в 2025 с интеграцией UPI; публичная цель - 20 млн пользователей к 2030.
- Западная Европа. Открыт региональный хаб в Париже и объявлена программа инвестиций €1,1 млрд на 3 года; подача заявки на французскую банковскую лицензию.
- Великобритания. В 2024 получили статус authorised with restrictions (стадия mobilisation); формальный запуск UK‑банка планировался в 2025.

2) Оргструктура и как устроена разработка
- Корпоративное управление. Совет директоров из 8 человек: председатель, 2 исполнительных директора и 5 независимых НЕД; работа ведётся через 4 комитета (аудит, риск/комплаенс, вознаграждения, назначения).
- Инженерия через "скводы" и "владение продуктом". Revolut работает маленькими кросс‑функциональными командами (типично 6–8 человек). Product Owner управляют командами как "локальные СЕО", что даёт end‑to‑end ответственность (в компании ~150 таких product owners)
- Масштаб ИТ. 1.3k инженеров, 1. 2k микросервисов, 1. 1k БД; платформой DevOps управляет команда ~15 инженеров благодаря высокому уровню автоматизации (централизованный каталог систем, self‑service пайплайны).
- Инженерная культура. Явная ставка на "качество в руках разработчиков": нет выделенного QA, инженеры сами пишут тесты, мониторят и эксплуатируют свои сервисы.

3) Архитектура и инфраструктура
- Размещение в облаке. Бэкенды и веб‑фронты хостятся в сертифицированных дата‑центрах Google Cloud; развертывание - Kubernetes (GKE), также используется Compute Engine. В 2025 объявлено углубление многолетнего партнёрства с Google Cloud под рост до 100 млн пользователей.
- Бекенд стек. Компания официально называет: Java 21, PostgreSQL (через jOOQ), Redis, Docker/Kubernetes, Google Cloud; архитектурные подходы - DDD, CQRS, TDD.
- Веб‑стек (2021 год). React + TypeScript, Redux, Rush (монорепо), TeamCity (CI/CD), Sentry; автоматические деплои на GKE.
- Микросервисы и события (2020 год). Широкое применение event‑driven архитектуры и собственная шина событий EventStore/EventStream

4) AI/ML: роль и приоритеты
- Клиентские и операционные ассистенты. Revolut официально сообщало о 2 gen AI‑ассистентах, а в 2024 анонсировали новый consumer‑AI‑ассистент и линейку "умных" сервисов (включая пилоты по ипотеке/банкоматам).
- Финансовая безопасность и эффективность. В годовом отчёте за 2024 - $800+ млн потенциального мошенничества предотвращено (оценка).
- Инфраструктурный AI. Расширение партнёрства с Google Cloud и использование Gemini и ML‑сервисов для фрода, персонализации
- Внутренние планы 2025. Компания исследует AI‑агентов для автоматизации продаж и поддержки, а также строит собственных агентов

Если обобщить, то ситуация примерно такая
- Revolut целенаправленно масштабируется глобально (ЛатАм, Индия, Западная Европа) с опорой на лицензирование и локальную инфраструктуру.
- ИТ‑модель - автономные продуктовые команды + небольшие платформенные команды, высокая степень стандартизации и автоматизации разработки
- Техстек - cloud‑native поверх Google Cloud Platform, на беке Java/Postgres/Redis, Kubernetes; на фронте React/TypeScript; ключевые паттерны - микросервисы, событийность, DDD/CQRS.
- AI в приоритете: от ассистентов до фрода и персонализации, с заметным влиянием на метрики безопасности и поддержки.

#Software #Engineering #Management #Architecture #Processes

[1/2] From Predictive to Generative - How Michelangelo Accelerates Uber’s AI Journey (Рубрика #PlatformEngineering)

Когда я изучал как устроена инженерия в Uber, я наткнулся на отличную статью с разбором эволюции ML/AI платформы Michelangelo. Мне показалось интересным отдельно рассказать про все три этапа эволюции платформы, какие у них были предпосылки, что получилось в итоге, а также что можно почерпнуть себе, если вы тоже делаете платформы в своих компаниях.

Ну и начать стоит с того, что в Uber машинное обучение (ML) уже много лет играет ключевую роль практически во всех аспектах бизнеса - от прогнозирования времени прибытия (ETA) и подбора водителя до ранжирования ресторанов в Uber Eats и выявления мошенничества. Для поддержки такого широкого применения ML Uber в 2016 году создала централизованную платформу Michelangelo (вот рассказ от 2017 года об этом), охватывающую весь жизненный цикл ML-моделей - от подготовки данных и обучения до деплоя и онлайн-инференса. Дальше платформа росла и развивалась, пройдя следующих три этапа эволюции

1️⃣ Predictive ML-платформа (2016–2019)
Фокус: табличные данные, модели типа XGBoost, классические predictive задачи: ETA, ценообразование, риск, антифрод.
Запуск Michelangelo 1.0 как централизованной ML-платформы:
- Единый Feature Store для повторного использования фичей,
- Стандартизованные пайплайны обучения/деплоя,
- Инструменты для мониторинга и дебага моделей.
Цель: перестать собирать ML-инфру в каждой команде как с нуля

2️⃣ Deep Learning & Michelangelo 2.0 (2019–2023)
Первая версия была хорошо, но требовалось порешать новые проблемы
- Deep learing начал давать выигрыш по качеству в high‑impact задачах, а платформа его плохо поддерживала
- Моделей и команд много, инструменты фрагментированы.
- Нет единого взгляда на качество моделей и приоритеты.
Ключевые изменения:
- Michelangelo 2.0: единый продукт вместо зоопарка тулов.
- Встроенная поддержка deep learning (GPU, distributed training, PyTorch/TensorFlow и т.д.).
- Добавлены следующие возможности
-- Model Excellence Score - сквозная метрика качества модели (от обучения до продакшена),
-- Tiering (Tier‑1…Tier‑4) для приоритизации ML-проектов по бизнес‑ценности.
-- Canvas / "model iteration as code": monorepo для ML, шаблоны ML-приложений, CI/CD для моделей, нормальные code review и reproducibility.

3️⃣ Generative AI и LLMOps (2023+)
После появления LLM надо было добавить в Michelangelo слой для generative AI:
- GenAI Platform / GenAI Gateway:
- Единый интерфейс к внешним и внутренним LLM (OpenAI, Llama2 и др.),
- Централизованный контроль доступа, логирование, cost‑контроль, безопасная работа с данными.

Michelangelo решили расширить до end‑to‑end LLMOps:
- Хранение и версионирование LLM,
- Репозиторий и version control для prompt’ов,
- Инструменты оценки качества и A/B-тестов LLM.

Технологический стек был выбран следующий: Hugging Face, DeepSpeed (model parallelism), Ray для распределённых вычислений и масштабирования GPU.

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

#Architecture #Engineering #Management #ML #AI #Software #Leadership #DistributedSystem #SystemDesign

[2/2] From Predictive to Generative - How Michelangelo Accelerates Uber’s AI Journey (Рубрика #PlatformEngineering)

Продолжая рассказ про ML-платформу Michelangelo хочется поделиться уроками, что можно извлечь из рассказа про 8 лет ее эволюции и развития внутри Uber. Вдруг вы тоже планируете делать свою платформу:)

1. Централизованная ML-платформа
Для средних и больших компаний централизация значительно повышает эффективность разработки ML-моделей, избавляя от дублирования и позволяя внедрять стандарты повсеместно. В Uber оргструктура выглядела так: сильная центральная ML Platform team + встраивание ML-инженеров и data scientist’ов в продуктовые команды. Это позволило совместить экспертизу платформы с глубоким знанием домена продукта

2. Единый и гибкий UX
Кто-то любит интерфейсы “point-and-click”, а другие предпочитают всё делать кодом. Но для платформы важно предоставить обе возможности в рамках единого платформенного опыта: UI-инструменты для визуализации и быстрого прототипирования, а также возможность полноценно работать через код (API, конфигурации, Git). В Uber эта дуальность была критичной для принятия платформы разными командами. Причем разные режимы существуют совместно и платформа синхронизирует изменения, будь то через UI или код, обеспечивая согласованность и version control

3. Высокоуровневые шаблоны + доступ к низкоуровневым компонентам
Платформа обеспечивает эффективность за счет предоставления high-level абстракций (шаблоны типовых ML-пайплайнов, авто-настройки, готовые интеграции) для большинства пользователей. Но для продвинутых команд нужно обеспечить доступ к низкоуровневым компонентам для кастомизации. Именно так сделано в Michelangelo 2.0: большинство используют готовые workflow templates и стандартные конфигурации, а power users при необходимости "спускаются" на уровень кастомных pipelines, встроенных в общую систему.

4. Модульная архитектура и открытость
Модульность позволяет компонентам платформы развиваться и масштабироваться независимо друг от друга. Plug-and-play дизайн позволяет быстро внедрять state-of-the-art технологии из open-source или сторонних сервисов по мере их появления. Uber держит фокус на основном пользовательском опыте, но технически может подключать лучшие решения для оркестрации, хранения данных, вычислений и т.д., не ломая общий продукт. Uber предпочитает открытые решения там, где это возможно, но использует и облачные модели, внимательно оценивая косты

5. Осознанное применение Deep Learning
Продвинутые методы вроде DL способны решать очень сложные задачи, но требуют огромных ресурсов и инфраструктуры, что должно быть оправдано бизнес-ценностью. Поэтому архитектура поддерживает разные типы моделей, а выбор делается прагматично. Для команд, планирующих внедрять DL, важно заранее обеспечить поддержку масштабируемого обучения (GPU/TPU, distributed training) и продумать мониторинг продуктивности моделей, так как обслуживание DL в продакшене сложнее и дороже обычных моделей.

6. Приоритизация ML-проектов
Не все модели равны - какие-то напрямую влияют на ключевые метрики бизнеса, другие играют вспомогательную роль. Вводите систему приоритетов (tiers) для ML-проектов, чтобы рационально распределять ресурсы и требования к надежности. Опыт Uber показывает эффективность четкого разделения
- Критичные (tier-1) модели получают максимальный уровень поддержки, мониторинга, строгие процессы деплоя
- Низкоприоритетные экспы (tier-4) могут обслуживаться по упрощенной схеме, предоставляя командам свободу творить, но без расходования чрезмерных ресурсов.

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

#Architecture #Engineering #Management #ML #AI #Software #Leadership #DistributedSystem #SystemDesign

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

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

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

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

#Conference