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

[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