[1/3] Google's AI‑powered next‑generation global network: Built for the Gemini era - Эволюция сети (Рубрика #Infrastructure)
Прочитал интересную статью от Google про эволюцию их сети за авторством Bikash Koley, VP по глобальным сетям и инфраструктуре. Основная идея статьи - показать эволюцию частной глобальной сети Google и новые принципы её дизайна, призванные удовлетворить стремительно растущие потребности ИИ-эры (а заодно порекламировать доступность этой сети Google клиентам GCP в качестве продукта CloudWAN).
Вот какие эпохи проходила сетевая архитектура Google
🌐 Internet era (2000-e)
Фокус был на быстром и надёжном получении результатов поиска, почты Gmail, карт и пр. Для этого Google строила собственные датацентры и каналы связи, а также изобретала технологии, позволявшие масштабировать сеть: частная магистраль, первый программно-определяемый WAN B4, контроллер трафика Orion и датацентровый коммутатор Jupiter
📱 Streaming era (конец 2000-х)
С ростом YouTube и потокового видео Google адаптировала сеть под видеостриминг - снизила задержки и jitters благодаря развитию своей CDN (Google Global Cache - кэширующие узлы у операторов связи) и новым протоколам передачи данных (Espresso, QUIC, TCP BBR и др.)
💭 Cloud era (2010-e)
Дальше наступил бурный рост облачных сервисов, а это потребовало усилить надёжность, изоляцию клиентов и безопасность сети. Google в ответ внедрила SDN (программно-определённые сети) везде: от виртуальной сети датацентра Andromeda до нового RPC-протокола gRPC и систем защиты трафика (PSP, Swift и др.).
Сейчас сеть Google очень масштабна
- 2 миллионов миль оптоволокна, инвестиции в 33 подводных кабеля через океаны, которые соденяют compute инфраструктуру
- 200+ узлов Point of Presence, 3000+ CDN-локаций по всему миру, 42 облачных региона, 127 зон
В продолжении я расскажу а как и куда дальше Google планирует развивать свои сети и сравню с подходом от запрещенной в России Meta.
#Software #DevOps #Architecture #Economics #DistributedSystem #SystemDesign
Прочитал интересную статью от Google про эволюцию их сети за авторством Bikash Koley, VP по глобальным сетям и инфраструктуре. Основная идея статьи - показать эволюцию частной глобальной сети Google и новые принципы её дизайна, призванные удовлетворить стремительно растущие потребности ИИ-эры (а заодно порекламировать доступность этой сети Google клиентам GCP в качестве продукта CloudWAN).
Вот какие эпохи проходила сетевая архитектура Google
Фокус был на быстром и надёжном получении результатов поиска, почты Gmail, карт и пр. Для этого Google строила собственные датацентры и каналы связи, а также изобретала технологии, позволявшие масштабировать сеть: частная магистраль, первый программно-определяемый WAN B4, контроллер трафика Orion и датацентровый коммутатор Jupiter
С ростом YouTube и потокового видео Google адаптировала сеть под видеостриминг - снизила задержки и jitters благодаря развитию своей CDN (Google Global Cache - кэширующие узлы у операторов связи) и новым протоколам передачи данных (Espresso, QUIC, TCP BBR и др.)
Дальше наступил бурный рост облачных сервисов, а это потребовало усилить надёжность, изоляцию клиентов и безопасность сети. Google в ответ внедрила SDN (программно-определённые сети) везде: от виртуальной сети датацентра Andromeda до нового RPC-протокола gRPC и систем защиты трафика (PSP, Swift и др.).
Сейчас сеть Google очень масштабна
- 2 миллионов миль оптоволокна, инвестиции в 33 подводных кабеля через океаны, которые соденяют compute инфраструктуру
- 200+ узлов Point of Presence, 3000+ CDN-локаций по всему миру, 42 облачных региона, 127 зон
В продолжении я расскажу а как и куда дальше Google планирует развивать свои сети и сравню с подходом от запрещенной в России Meta.
#Software #DevOps #Architecture #Economics #DistributedSystem #SystemDesign
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12🔥2👍1
[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
Продолжая рассказ про эволюцию сетей Google, стоит сказать, что сейчас они видят новый поворотный момент - взрывное развитие искусственного интеллекта, что предъявляет к сети беспрецедентные требования (например, обучение больших моделей резко меняют профиль нагрузки на сеть). На самом деле там есть целых четыре отдельных вызова, что приводят к изменению дизайн-принципов развертывания сетей
1. WAN как новая LAN
Обучение современных foundation models требует объединения тысяч TPU/GPU. И то, что раньше размещалось в пределах одного датацентра, теперь распределено географически (континент как датацентр - примерно тот же посыл у запрещенной в России Meta). Сеть должна масштабироваться на порядок больше прежнего, чтобы связать удалённые кластеры так, словно они в одном локальном сегменте. При этом трафик от распределённого обучения идёт всплесками, которые нужно эффективно обнаруживать и маршрутизировать без потери производительности.
2. Нулевая терпимость к сбоям
Процессы обучения моделей ИИ и крупномасштабный inference очень чувствительны к перебоям. Остановка обучения из-за сетевого сбоя - неприемлема из-за простев дорого железа. От сети теперь ожидают практически 100% доступности, без ощутимых перерывов, а значит сеть должна быть спроектирована так, чтобы любые отказоустойчивые механизмы срабатывали мгновенно и вообще не влияли на долгий процесс обучения.
3. Повышенные требования безопасности и контроля
Данные, на которых обучаются модели, и сами модели - ценный и чувствительный ресурс. Их нужно защищать как от утечек, так и от несанкционированных изменений. Кроме того, по мере распространения ИИ растут требования к соблюдению региональных регуляторных норм и к контролю данных "на лету" (в транзите). Сеть должна обеспечивать изоляцию, шифрование, соответствие политикам разных стран и компаний, чтобы ИИ-сервисы оставались надёжными и законопослушными.
4. Операционное совершенство при возросшей сложности
Масштаб, растущий на порядок, не может управляться по-старому. Google применяет лучшие практики SRE и уже использует машинное обучение для управления сетью, но теперь ставится цель минимизировать человеческий фактор. Сеть должна работать с минимумом ручного вмешательства, потому что линейное наращивание инфраструктуры иначе приведёт к неуправляемому росту сложности и затрат. Новые подходы требуются для автоматизации, быстрого выявления и устранения проблем, оптимизации емкости.
Отсюда появляются новые дизайн принципы сетей, которые мы обсудим в следующий раз.
#Software #DevOps #Architecture #Economics #DistributedSystem #SystemDesign
Telegram
Книжный куб
[1/3] Google's AI‑powered next‑generation global network: Built for the Gemini era - Эволюция сети (Рубрика #Infrastructure)
Прочитал интересную статью от Google про эволюцию их сети за авторством Bikash Koley, VP по глобальным сетям и инфраструктуре. Основная…
Прочитал интересную статью от Google про эволюцию их сети за авторством Bikash Koley, VP по глобальным сетям и инфраструктуре. Основная…
❤4👍4🔥4
[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
Продолжая рассказ про эволюцию сетей 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
Telegram
Книжный куб
[1/3] Google's AI‑powered next‑generation global network: Built for the Gemini era - Эволюция сети (Рубрика #Infrastructure)
Прочитал интересную статью от Google про эволюцию их сети за авторством Bikash Koley, VP по глобальным сетям и инфраструктуре. Основная…
Прочитал интересную статью от Google про эволюцию их сети за авторством Bikash Koley, VP по глобальным сетям и инфраструктуре. Основная…
❤5⚡2🔥1
WebSummit Lisbon (Рубрика #Conference)
В начале лета мы с женой сгонять на WebSummit в Португалию и купили early-bird tickets. Дальше мы купили билеты на самолет, забронировали отель и подали визу. Сегодня ночью мы должны были вылетать, но ... визовый центр Португалии вместе с консульством не смогли за четыре с половиной месяца рассмотреть заявление на визу и ответить да/нет. Правда, полторы недели назад нам пришлось забрать паспорта для полета на Мальдивы с детишками, но нам сказали вернуть паспорта 5 ноября обратно в визовый центр, чтобы успеть получить штампики 7 ноября. Сегодня 7 ноября, все сроки возврата по билетам и брони прошли, а паспортов нет ... В итоге, поездка на WebSummit сорвалась, денег не вернуть, настроение испорчено. Я отношусь к этому философски - примерно по этой же схеме мы с женой и детьми уже год ждем визу в Канаду, где тоже не могут ответить да/нет, правда, там электронная виза и паспорта не забирают.
В общем, летать походу надо в страны Глобального Юга, а не в те, где тебя мурыжат с визами ... иначе ты играешь в какую-то рулетку с непредсказуемым итогом.
#Conference
В начале лета мы с женой сгонять на WebSummit в Португалию и купили early-bird tickets. Дальше мы купили билеты на самолет, забронировали отель и подали визу. Сегодня ночью мы должны были вылетать, но ... визовый центр Португалии вместе с консульством не смогли за четыре с половиной месяца рассмотреть заявление на визу и ответить да/нет. Правда, полторы недели назад нам пришлось забрать паспорта для полета на Мальдивы с детишками, но нам сказали вернуть паспорта 5 ноября обратно в визовый центр, чтобы успеть получить штампики 7 ноября. Сегодня 7 ноября, все сроки возврата по билетам и брони прошли, а паспортов нет ... В итоге, поездка на WebSummit сорвалась, денег не вернуть, настроение испорчено. Я отношусь к этому философски - примерно по этой же схеме мы с женой и детьми уже год ждем визу в Канаду, где тоже не могут ответить да/нет, правда, там электронная виза и паспорта не забирают.
В общем, летать походу надо в страны Глобального Юга, а не в те, где тебя мурыжат с визами ... иначе ты играешь в какую-то рулетку с непредсказуемым итогом.
#Conference
😢28💯10🤯4❤1
Фильм "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
Пока летел восемь часов с Мальдив я прочитал несколько глав книги "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
❤5🔥5⚡2
Сравнение подходов 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
В этом посте я решил сравнить подходы 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
❤9🔥6⚡2
„Я понял, что это конец“: как создатель „Алисы“ уволился из „Сбера“, эмигрировал и строит 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
Посмотрел интересное интервью Константина Круглова, что он дал Елизавете Осетинской, иностранному агенту. Сам гость в этом выпуске очень интерсные - Константин до отъезда из России успел поработать в 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
1👍25❤9👎3🔥1
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
Интересный доклад 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
InfoQ
Extreme DevOps Automation
Sérgio Amorim shares how Revolut’s small DevOps team leverages a centralized systems catalog and automation to enable 1,300 engineers to build and deploy applications with speed and consistency. He explains how this approach reduces manual effort and improves…
🔥12❤9👍8
[1/2] The History of the Future: Oculus, Facebook, and the Revolution That Swept Virtual Reality (Oculus. Как создать лучшую в мире VR компанию и потерять все?) (Рубрика #Games)
С большим интересом я проглотил эту документалку о стремительном взлете стартапа взлёте Oculus VR, создавшего революционный VR-шлем Oculus Rift. Автор книги – американский писатель Блейк Дж. Харрис, известный по бестселлеру Console Wars (2014) о битве Sega vs Nintendo. Для работы над этой книгой Харрис получил беспрецедентный доступ к команде компании: с 2016 года он провёл сотни интервью с ключевыми сотрудниками Oculus, наблюдая запуск первого продукта и жизнь стартапа после многомиллиардного поглощения Facebook. Итогом стала захватывающая история о том, как группа энтузиастов пыталась "воплотить будущее" ... и что из этого вышло (запрещенная в России компания Meta на этой волне даже переименовалась из Facebook, но про это в книге не упоминается).
Главным героем книги является Палмер Лаки - молодой самоучка и изобретатель, который в 19 лет сконструировал в своем трейлере прототип VR-шлема Oculus Rift, но и не думал о создании компании. Но его переубедил Брендан Ирибэ - сооснователь и первый CEO Oculus VR. Брендан был опытным менеджером из игровой индустрии, он помог превратить любительский проект в бизнес - привлёк инвесторов и выстроил команду, разделив с Лаки стратегическое руководство компанией. Также в этой истории замешан Джон Кармак - легендарный программист (создатель Doom и Quake), чьё участие придало проекту весомость. Кармак увлёкся прототипом Лаки и интегрировал его в демонстрацию игры Doom 3 BFG Edition на E3 2012, чем произвёл фурор. А в 2013 году Кармак оставил id Software и стал техническим директором (CTO) Oculus VR, усилив компанию своим авторитетом и экспертизой. Ну и куда уж без Марка Цукерберга, сыгравшего ключевую роль во второй части истории. Увидев потенциал Oculus Rift, Марк в 2014 году приобрёл Oculus VR за ~$2 млрд. Причем в этой книге он не герой истории, а катализатор перемен - после сделки Oculus из стартапа превратился в подразделение корпорации Facebook, что принесло как ресурсы для развития, так и новые вызовы ...
В продолжении я расскажу основную канву истории и поделюсь финалом, который объясняет почему в России не очень широко известно про изобретателя Лаки Палмера, но хорошо известно про Джона Кармака и его участие в истории Oculus.
#Software #Hardware #Engineering #Management #Leadership #Startup #Strategy
С большим интересом я проглотил эту документалку о стремительном взлете стартапа взлёте Oculus VR, создавшего революционный VR-шлем Oculus Rift. Автор книги – американский писатель Блейк Дж. Харрис, известный по бестселлеру Console Wars (2014) о битве Sega vs Nintendo. Для работы над этой книгой Харрис получил беспрецедентный доступ к команде компании: с 2016 года он провёл сотни интервью с ключевыми сотрудниками Oculus, наблюдая запуск первого продукта и жизнь стартапа после многомиллиардного поглощения Facebook. Итогом стала захватывающая история о том, как группа энтузиастов пыталась "воплотить будущее" ... и что из этого вышло (запрещенная в России компания Meta на этой волне даже переименовалась из Facebook, но про это в книге не упоминается).
Главным героем книги является Палмер Лаки - молодой самоучка и изобретатель, который в 19 лет сконструировал в своем трейлере прототип VR-шлема Oculus Rift, но и не думал о создании компании. Но его переубедил Брендан Ирибэ - сооснователь и первый CEO Oculus VR. Брендан был опытным менеджером из игровой индустрии, он помог превратить любительский проект в бизнес - привлёк инвесторов и выстроил команду, разделив с Лаки стратегическое руководство компанией. Также в этой истории замешан Джон Кармак - легендарный программист (создатель Doom и Quake), чьё участие придало проекту весомость. Кармак увлёкся прототипом Лаки и интегрировал его в демонстрацию игры Doom 3 BFG Edition на E3 2012, чем произвёл фурор. А в 2013 году Кармак оставил id Software и стал техническим директором (CTO) Oculus VR, усилив компанию своим авторитетом и экспертизой. Ну и куда уж без Марка Цукерберга, сыгравшего ключевую роль во второй части истории. Увидев потенциал Oculus Rift, Марк в 2014 году приобрёл Oculus VR за ~$2 млрд. Причем в этой книге он не герой истории, а катализатор перемен - после сделки Oculus из стартапа превратился в подразделение корпорации Facebook, что принесло как ресурсы для развития, так и новые вызовы ...
В продолжении я расскажу основную канву истории и поделюсь финалом, который объясняет почему в России не очень широко известно про изобретателя Лаки Палмера, но хорошо известно про Джона Кармака и его участие в истории Oculus.
#Software #Hardware #Engineering #Management #Leadership #Startup #Strategy
❤7👍6🔥4
[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
Продолжая рассказ про книгу "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
Telegram
Книжный куб
[1/2] The History of the Future: Oculus, Facebook, and the Revolution That Swept Virtual Reality (Oculus. Как создать лучшую в мире VR компанию и потерять все?) (Рубрика #Games)
С большим интересом я проглотил эту документалку о стремительном взлете стартапа…
С большим интересом я проглотил эту документалку о стремительном взлете стартапа…
🔥4❤3👍3🤔1
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
Недавно прочитал статью про эволюцию 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
Building Nubank
10 years of engineering at Nubank: Lessons from scaling to 122+ million customers - Building Nubank
From first lines of code to massive architectural shifts, learn what it takes to scale engineering, culture, and innovation to 122+ million customers
❤8👍5🔥5
High growth startups: Uber and CloudKitchens with Charles-Axel Dein (Рубрика #Engineering)
Посмотрел интересное интервью Charles-Axel Dein, что он дал Gergely Orosz в подкасте Pragmatic Engineer. Гость был 20м инженером в Uber, а сейчас техлид в стартапе CloudKitchens. Также он автор легендарного репозитория Professional Programming Reading List (15 лет собирает полезные статьи, сейчас 48K⭐ на GitHub). Его интересно послушать, так как он застал этот период гипер-роста в Uber и в подкасте рассказывает много историй и выученных уроков из того времени. Если их сократить, то звучат они так
🚀 Команда на взлёте
- Гиперрост = лавинообразное расширение команд. В раннем Uber hiring был в режиме нон-стоп
- Искали экспертов-генералистов с широким набором навыков: во время гиперроста ценятся адаптируемые люди, а не узкие "винтики". Каждый инженер вовлечён не только в код, но и в продукт: “Programming is only a part of our work... We are highly involved in product decision-making”
- Чтобы масштабироваться организационно, Uber даже провёл реорг и разделил инженеров на platform-команды (инфраструктура) и продуктовые команды (продукт) – это решение, "определившее культуру на годы вперёд"
- В CloudKitchens Déin применяет тот же принцип: собирать сильные автономные команды, готовые к быстрому росту.
⚙️ Архитектура и масштаб
- Суперрост Uber бросил вызов технике. Монолитная Python-кодовая база (~450k строк) перестала тянуть и за ~5 лет её распилили на 1000+ микросервисов
- Собственные датацентры тоже трещали по швам; спустя 9 лет Uber затеял большую миграцию в облако
- Параллельно строили внутренние платформенные решения (например, observability) для мониторинга и деплоя, чтобы каждая продуктовая команда не изобретала велосипед
- Итог: архитектура эволюционирует рывками, и к этому нужно быть готовым.
🔥 Инциденты и автоматика
- Молниеносный рост = неизбежные сбои в продакшене. Charles рассказал, как важна отлаженная oncall-культура: быстро реагировать и учиться на пост-моим («blameless» разборы фейлов – наше всё).
- В CloudKitchens усвоили урок того, что не стоит автоматизировать всё подряд слепо. Сначала надо сделать вручную и убедиться, что процесс вообще имеет смысл – sanity check! Иначе автоматизация может сама привнести баги (designer errors). Проще говоря, manual first, automation second.
🤕 Burnout vs Imposter Syndrome
- Работа в режиме hypergrowth выматывает, стоит беречь энергию и не загонять себя в хронический burnout
- В быстрорастущих командах норма чувствовать себя некомпетентным. Вместо того чтобы паниковать, стоит использовать это чувство как драйвер роста - раз ты ощущаешь дискомфорт, значит реально растёшь вне зоны комфорта.
🔜 Продуктивность и рост
- Чтобы успевать в хаосе гиперроста, нужны личные лайфхаки. Charles - фанат методологии GTD (Getting Things Done) и приложения Things для таск-менеджмента: эти инструменты помогают держать фокус и не тонуть в делах
- Кроме того, он непрерывно учится: уже 15 лет пополняет свой список чтения для программистов (тот самый repo на 48K⭐) и поглощает тонны инфы
- Также он советует прокачивать CS-базис: понимание, как работают компиляторы, операционные системы и прочий tech fundamentals. Такие фундаментальные скиллы остаются ценными при любом стеке и любом цикле хайпа.
💯 Карьерные инсайты
- Hypergrowth-компания ценит инженеров, которые делают больше, чем просто писать код. Главное - ownership и гибкость мышления: топ-инженеры берут ответственность, думают о продукте и подтягивают команду, а не только фичи выкатывают&
- На интервью лучше не читерить, а показать свой реальный скилл пусть с небольшими огрехами, чем идеальные, но чужие решения.
Если суммаризировать, то hypergrowth компании - это хаос, скорость, риски и огромные возможности:)
#Architecture #Engineering #Management #VC #Startup #Software #Leadership
Посмотрел интересное интервью Charles-Axel Dein, что он дал Gergely Orosz в подкасте Pragmatic Engineer. Гость был 20м инженером в Uber, а сейчас техлид в стартапе CloudKitchens. Также он автор легендарного репозитория Professional Programming Reading List (15 лет собирает полезные статьи, сейчас 48K⭐ на GitHub). Его интересно послушать, так как он застал этот период гипер-роста в Uber и в подкасте рассказывает много историй и выученных уроков из того времени. Если их сократить, то звучат они так
- Гиперрост = лавинообразное расширение команд. В раннем Uber hiring был в режиме нон-стоп
- Искали экспертов-генералистов с широким набором навыков: во время гиперроста ценятся адаптируемые люди, а не узкие "винтики". Каждый инженер вовлечён не только в код, но и в продукт: “Programming is only a part of our work... We are highly involved in product decision-making”
- Чтобы масштабироваться организационно, Uber даже провёл реорг и разделил инженеров на platform-команды (инфраструктура) и продуктовые команды (продукт) – это решение, "определившее культуру на годы вперёд"
- В CloudKitchens Déin применяет тот же принцип: собирать сильные автономные команды, готовые к быстрому росту.
- Суперрост Uber бросил вызов технике. Монолитная Python-кодовая база (~450k строк) перестала тянуть и за ~5 лет её распилили на 1000+ микросервисов
- Собственные датацентры тоже трещали по швам; спустя 9 лет Uber затеял большую миграцию в облако
- Параллельно строили внутренние платформенные решения (например, observability) для мониторинга и деплоя, чтобы каждая продуктовая команда не изобретала велосипед
- Итог: архитектура эволюционирует рывками, и к этому нужно быть готовым.
- Молниеносный рост = неизбежные сбои в продакшене. Charles рассказал, как важна отлаженная oncall-культура: быстро реагировать и учиться на пост-моим («blameless» разборы фейлов – наше всё).
- В CloudKitchens усвоили урок того, что не стоит автоматизировать всё подряд слепо. Сначала надо сделать вручную и убедиться, что процесс вообще имеет смысл – sanity check! Иначе автоматизация может сама привнести баги (designer errors). Проще говоря, manual first, automation second.
- Работа в режиме hypergrowth выматывает, стоит беречь энергию и не загонять себя в хронический burnout
- В быстрорастущих командах норма чувствовать себя некомпетентным. Вместо того чтобы паниковать, стоит использовать это чувство как драйвер роста - раз ты ощущаешь дискомфорт, значит реально растёшь вне зоны комфорта.
- Чтобы успевать в хаосе гиперроста, нужны личные лайфхаки. Charles - фанат методологии GTD (Getting Things Done) и приложения Things для таск-менеджмента: эти инструменты помогают держать фокус и не тонуть в делах
- Кроме того, он непрерывно учится: уже 15 лет пополняет свой список чтения для программистов (тот самый repo на 48K⭐) и поглощает тонны инфы
- Также он советует прокачивать CS-базис: понимание, как работают компиляторы, операционные системы и прочий tech fundamentals. Такие фундаментальные скиллы остаются ценными при любом стеке и любом цикле хайпа.
- Hypergrowth-компания ценит инженеров, которые делают больше, чем просто писать код. Главное - ownership и гибкость мышления: топ-инженеры берут ответственность, думают о продукте и подтягивают команду, а не только фичи выкатывают&
- На интервью лучше не читерить, а показать свой реальный скилл пусть с небольшими огрехами, чем идеальные, но чужие решения.
Если суммаризировать, то hypergrowth компании - это хаос, скорость, риски и огромные возможности:)
#Architecture #Engineering #Management #VC #Startup #Software #Leadership
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
High growth startups: Uber and CloudKitchens with Charles-Axel Dein
What does it take to do well at a hyper-growth company? In this episode of The Pragmatic Engineer, I sit down with Charles-Axel Dein, one of the first engineers at Uber, who later hired me there. Since then, he’s gone on to work at CloudKitchens. He’s also…
❤9👍5🔥2
Как устроена инженерия в 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
После воспоминаний про былые дни в 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
❤9👍5🔥4
Про 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
После изучения подхода 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
Telegram
Книжный куб
Extreme DevOps Automation - доклад от Revolut на QCon 2025 (Рубрика #PlatformEngineering)
Интересный доклад c QCon 2025 от Sérgio Amorim про работу их DevOps команды. Суть в том, что у ребят из Revolut практичный подход к своей платформе разработки - они…
Интересный доклад c QCon 2025 от Sérgio Amorim про работу их DevOps команды. Суть в том, что у ребят из Revolut практичный подход к своей платформе разработки - они…
❤14👍8🔥4
[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
Когда я изучал как устроена инженерия в 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
Telegram
Книжный куб
Как устроена инженерия в Uber (Рубрика #Engineering)
После воспоминаний про былые дни в Uber от Charles-Axel Dein я заинтересовался тем, а как сейчас устроена инженерная часть Uber и собрал примерно такую информацию.
Инженерное крыло компании насчитывает…
После воспоминаний про былые дни в Uber от Charles-Axel Dein я заинтересовался тем, а как сейчас устроена инженерная часть Uber и собрал примерно такую информацию.
Инженерное крыло компании насчитывает…
❤6🔥4⚡2
[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
Продолжая рассказ про 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
Telegram
Книжный куб
[1/2] From Predictive to Generative - How Michelangelo Accelerates Uber’s AI Journey (Рубрика #PlatformEngineering)
Когда я изучал как устроена инженерия в Uber, я наткнулся на отличную статью с разбором эволюции ML/AI платформы Michelangelo. Мне показалось…
Когда я изучал как устроена инженерия в Uber, я наткнулся на отличную статью с разбором эволюции ML/AI платформы Michelangelo. Мне показалось…
❤3🔥2👍1
Сегодня узнал, что визы в Португалию уже готовы. Блиц, блиц - скорость без границ - визовый центр сделал их как раз к плановому возвращению из Португалии:)
1👏7👍2👎2😢1
Forwarded from Книжный куб (Alexander Polomodov)
WebSummit Lisbon (Рубрика #Conference)
В начале лета мы с женой сгонять на WebSummit в Португалию и купили early-bird tickets. Дальше мы купили билеты на самолет, забронировали отель и подали визу. Сегодня ночью мы должны были вылетать, но ... визовый центр Португалии вместе с консульством не смогли за четыре с половиной месяца рассмотреть заявление на визу и ответить да/нет. Правда, полторы недели назад нам пришлось забрать паспорта для полета на Мальдивы с детишками, но нам сказали вернуть паспорта 5 ноября обратно в визовый центр, чтобы успеть получить штампики 7 ноября. Сегодня 7 ноября, все сроки возврата по билетам и брони прошли, а паспортов нет ... В итоге, поездка на WebSummit сорвалась, денег не вернуть, настроение испорчено. Я отношусь к этому философски - примерно по этой же схеме мы с женой и детьми уже год ждем визу в Канаду, где тоже не могут ответить да/нет, правда, там электронная виза и паспорта не забирают.
В общем, летать походу надо в страны Глобального Юга, а не в те, где тебя мурыжат с визами ... иначе ты играешь в какую-то рулетку с непредсказуемым итогом.
#Conference
В начале лета мы с женой сгонять на WebSummit в Португалию и купили early-bird tickets. Дальше мы купили билеты на самолет, забронировали отель и подали визу. Сегодня ночью мы должны были вылетать, но ... визовый центр Португалии вместе с консульством не смогли за четыре с половиной месяца рассмотреть заявление на визу и ответить да/нет. Правда, полторы недели назад нам пришлось забрать паспорта для полета на Мальдивы с детишками, но нам сказали вернуть паспорта 5 ноября обратно в визовый центр, чтобы успеть получить штампики 7 ноября. Сегодня 7 ноября, все сроки возврата по билетам и брони прошли, а паспортов нет ... В итоге, поездка на WebSummit сорвалась, денег не вернуть, настроение испорчено. Я отношусь к этому философски - примерно по этой же схеме мы с женой и детьми уже год ждем визу в Канаду, где тоже не могут ответить да/нет, правда, там электронная виза и паспорта не забирают.
В общем, летать походу надо в страны Глобального Юга, а не в те, где тебя мурыжат с визами ... иначе ты играешь в какую-то рулетку с непредсказуемым итогом.
#Conference
👍6💯4🦄2
[1/2] Про Nubank (Рубрика #Business)
После изучения истории Lucas Cavalcant (distingueshed engineer @ Nubank) про развитие разработки в Nubank мне стало интересно, а какая у них глобальная стратегия и как IT поддерживает эту стратегию. В принципе, при текущем развитии технологий поиска и особенно перевода узнать это не составило труда (я не знаю португальский, но зато его знаю LLM ).
В феврале 2025 года Nubank рассказывал про такую стратегию из трех актов
1️⃣ Лидирующая розничная банковская сеть в Латинской Америке.
Nubank стремится построить крупнейший и самый любимый розничный банк в ЛатАм за счёт масштабирования клиентской базы и повышения лояльности. Уже в 2024 году Nubank достиг Net Promoter Score 84 среди клиентов с высоким доходом в Бразилии, что свидетельствует о высоком уровне удовлетворенности. В Бразилии Nubank стал третьим по количеству клиентов финансовым институтом страны, активно привлекая новые сегменты (например, запуск премиальной программы Ultravioleta для состоятельных клиентов).
2️⃣ Выход за пределы финансовых услуг
Компания расширяет продуктовый портфель за рамки классического банкинга, создавая экосистему сервисов. В 2024 году Nubank запустил новые услуги: NuTravel – встроенный сервис планирования путешествий, и NuCel – виртуального мобильного оператора. Эти инициативы расширяют адресный рынок Nubank и повышают вовлечённость клиентов. Например, маркетплейс Nubank за 2024 год привлёк свыше 1 млн покупателей. Такие сервисы дополняют банковские продукты и удерживают пользователей внутри экосистемы Nubank.
3️⃣ Глобальная модель цифрового банка, управляемого AI
Nubank объявил целью стать глобальной AI-ориентированной банковской платформой, активно внедряя искусственный интеллект для повышения эффективности и персонализации продуктов. Это подразумевает, что AI будет лежать в основе как клиентского опыта, так и внутренних операций Nubank. Например, компания инвестирует в генеративный AI для клиентского сервиса и персонализированных финансовых советов. Например, летом 2024 года Nubank купил стартап Hyperplane, что специализируется на foundation models (базовых больших моделях) по финансовым данным и позволяет обучать сотни моделей на первичных данных банка (first-party data) для разных задач - риск, коллекшн, маркетинг и др.
Если говорить про инженерное крыло, то в августе 2025 года случилась перестановка - новым CTO стал Eric Young, ветеран отрасли (экс-VP Engineering Snap, Google, Amazon) с опытом масштабирования инфраструктуры для сотен миллионов пользователей. CTO определяет техническую стратегию Nubank, включая архитектуру, платформенные инвестиции и внедрение инноваций (например, AI). До прихода Янга CTO обязанности выполнял Витор Оливейра, который проработал в компании 10 лет. Кстати, в продолжении я расскажу про тезисы Витора об инженерии в Nubank из подкаста "Hippsters Ponto Tech #459".
#Software #Engineering #Management #Processes
После изучения истории Lucas Cavalcant (distingueshed engineer @ Nubank) про развитие разработки в Nubank мне стало интересно, а какая у них глобальная стратегия и как IT поддерживает эту стратегию. В принципе, при текущем развитии технологий поиска и особенно перевода узнать это не составило труда (
В феврале 2025 года Nubank рассказывал про такую стратегию из трех актов
1️⃣ Лидирующая розничная банковская сеть в Латинской Америке.
Nubank стремится построить крупнейший и самый любимый розничный банк в ЛатАм за счёт масштабирования клиентской базы и повышения лояльности. Уже в 2024 году Nubank достиг Net Promoter Score 84 среди клиентов с высоким доходом в Бразилии, что свидетельствует о высоком уровне удовлетворенности. В Бразилии Nubank стал третьим по количеству клиентов финансовым институтом страны, активно привлекая новые сегменты (например, запуск премиальной программы Ultravioleta для состоятельных клиентов).
2️⃣ Выход за пределы финансовых услуг
Компания расширяет продуктовый портфель за рамки классического банкинга, создавая экосистему сервисов. В 2024 году Nubank запустил новые услуги: NuTravel – встроенный сервис планирования путешествий, и NuCel – виртуального мобильного оператора. Эти инициативы расширяют адресный рынок Nubank и повышают вовлечённость клиентов. Например, маркетплейс Nubank за 2024 год привлёк свыше 1 млн покупателей. Такие сервисы дополняют банковские продукты и удерживают пользователей внутри экосистемы Nubank.
3️⃣ Глобальная модель цифрового банка, управляемого AI
Nubank объявил целью стать глобальной AI-ориентированной банковской платформой, активно внедряя искусственный интеллект для повышения эффективности и персонализации продуктов. Это подразумевает, что AI будет лежать в основе как клиентского опыта, так и внутренних операций Nubank. Например, компания инвестирует в генеративный AI для клиентского сервиса и персонализированных финансовых советов. Например, летом 2024 года Nubank купил стартап Hyperplane, что специализируется на foundation models (базовых больших моделях) по финансовым данным и позволяет обучать сотни моделей на первичных данных банка (first-party data) для разных задач - риск, коллекшн, маркетинг и др.
Если говорить про инженерное крыло, то в августе 2025 года случилась перестановка - новым CTO стал Eric Young, ветеран отрасли (экс-VP Engineering Snap, Google, Amazon) с опытом масштабирования инфраструктуры для сотен миллионов пользователей. CTO определяет техническую стратегию Nubank, включая архитектуру, платформенные инвестиции и внедрение инноваций (например, AI). До прихода Янга CTO обязанности выполнял Витор Оливейра, который проработал в компании 10 лет. Кстати, в продолжении я расскажу про тезисы Витора об инженерии в Nubank из подкаста "Hippsters Ponto Tech #459".
#Software #Engineering #Management #Processes
Telegram
Книжный куб
10 years of engineering at Nubank: Lessons from scaling to 122+ million customers (Рубрика #Architecture)
Недавно прочитал статью про эволюцию NuBank за 10 лет от Lucas Cavalcant, Distinguished Software Engineer and Senior Architect. Эта история эволюции…
Недавно прочитал статью про эволюцию NuBank за 10 лет от Lucas Cavalcant, Distinguished Software Engineer and Senior Architect. Эта история эволюции…
🔥5❤4🗿2
[2/2] Про Nubank (Рубрика #Business)
Продолжая рассказ про Nubank, я хотел кратко изложить тезисы Витора Оливейра, который рассказывал про технологии в Nubank в подкасте "Hippsters Ponto Tech #459" (правда, подкаст на португальском) в апреле 2025 года, а уже в августе 2025 года его сменил Eric Young (экс-VP Engineering Snap, Google, Amazon), что, как по мне, дало ясный знак инвесторам на то, что Nubank готов масштабировать свою инженерную ветку для глобальной экспании, о которой было рассказано в предыдущем посте.
1️⃣ Тесты как “первая линия обороны” Nubank
- В Nubank большой фокус на тестировании: юнит-тесты, интеграционные, multi-service-тесты и эксперименты с genAI генерацией тестов
- Обоснование в том, что для крупного финтеха это не “nice to have”, а "must have", чтобы защитить чувствительные финансовые данные клиентов и держать высокую планку по стабильности, безопасности и приватности
2️⃣ Эволюция архитектуры: от JVM-стека к cloud-first
- Исторически Nubank строился вокруг JVM-стека (Clojure + Kafka), что задавало определённый стиль архитектуры и инженерной культуры (подробнее про историю можно глянуть в посте "10 years of engineering at Nubank")
- Сейчас у ребят стратегия cloud-first, но не "cloud at any cost": они осознанно балансируют между облаком и on-prem, учитывая три критерия: стоимость, контроль и сущность бизнеса
3️⃣ Ключевые инженерные принципы
Витор подчеркнул фундаментальные принципы, которые направляют технические решения
- Иммутабельность - immutable инфраструктура и сервисы
- Стандартизация - однообразие подходов вместо зоопарка технологий
- Continuous Delivery - непрерыная поставка и безопасные релизы
- Минимизация сложности - сознательное сопротивление "архитектурному энтузиазму", который раздувает систему
4️⃣ Компания как система - это не только про технологии
- Nubank смотрит на себя как на целостную систему, где культура и люди не менее важны, чем код и кластеры
- Важно уметь масштабировать команды и процессы под глобальное развитие (новые рынки, разные регуляции, распределённые команды), а не просто "накидывать микросервисы"
- Витор упоминает Conway’s Law: как структура коммуникаций влияет на архитектуру, и почему без правильного оргдизайна хорошую архитектуру не получить
5️⃣ Generative AI - осторожный, прагматичный подход
- Nubank уже использует gen AU, но очень аккуратно: они не гонятся за хайпом, а ищут конкретные, измеримые проблемы, где ИИ реально улучшает эффективность
- У ребят есть отдельные бюджеты и команды, которые экспериментируют с AI-подходами в тестировании и других задачах, системно отсеивая то, что “не взлетает”.
- Главный фильтр: безопасность и приватность данных
6️⃣ Главная мысль выпуска примерно такая
Зрелый финтех строится не вокруг модной технологии, а вокруг
- Строгой инженерной дисциплины (тесты, стандарты, CD)
- Осознанных архитектурных решений (JVM-ядро, cloud-first, но с пониманием ограничений)
- Системного взгляда на организацию и культуру
- Осторожного, прагматичного внедрения AI, где безопасность и ценность важнее демонстраций "магии"
P.S.
Интересно потом будет сравнить эти тезисы Витора с выступлениями Eric Young, нового CTO, что вышел только в конце лета.
#Software #Engineering #Management #Architecture #Processes #SRE #DevOps #Leadership
Продолжая рассказ про Nubank, я хотел кратко изложить тезисы Витора Оливейра, который рассказывал про технологии в Nubank в подкасте "Hippsters Ponto Tech #459" (правда, подкаст на португальском) в апреле 2025 года, а уже в августе 2025 года его сменил Eric Young (экс-VP Engineering Snap, Google, Amazon), что, как по мне, дало ясный знак инвесторам на то, что Nubank готов масштабировать свою инженерную ветку для глобальной экспании, о которой было рассказано в предыдущем посте.
1️⃣ Тесты как “первая линия обороны” Nubank
- В Nubank большой фокус на тестировании: юнит-тесты, интеграционные, multi-service-тесты и эксперименты с genAI генерацией тестов
- Обоснование в том, что для крупного финтеха это не “nice to have”, а "must have", чтобы защитить чувствительные финансовые данные клиентов и держать высокую планку по стабильности, безопасности и приватности
2️⃣ Эволюция архитектуры: от JVM-стека к cloud-first
- Исторически Nubank строился вокруг JVM-стека (Clojure + Kafka), что задавало определённый стиль архитектуры и инженерной культуры (подробнее про историю можно глянуть в посте "10 years of engineering at Nubank")
- Сейчас у ребят стратегия cloud-first, но не "cloud at any cost": они осознанно балансируют между облаком и on-prem, учитывая три критерия: стоимость, контроль и сущность бизнеса
3️⃣ Ключевые инженерные принципы
Витор подчеркнул фундаментальные принципы, которые направляют технические решения
- Иммутабельность - immutable инфраструктура и сервисы
- Стандартизация - однообразие подходов вместо зоопарка технологий
- Continuous Delivery - непрерыная поставка и безопасные релизы
- Минимизация сложности - сознательное сопротивление "архитектурному энтузиазму", который раздувает систему
4️⃣ Компания как система - это не только про технологии
- Nubank смотрит на себя как на целостную систему, где культура и люди не менее важны, чем код и кластеры
- Важно уметь масштабировать команды и процессы под глобальное развитие (новые рынки, разные регуляции, распределённые команды), а не просто "накидывать микросервисы"
- Витор упоминает Conway’s Law: как структура коммуникаций влияет на архитектуру, и почему без правильного оргдизайна хорошую архитектуру не получить
5️⃣ Generative AI - осторожный, прагматичный подход
- Nubank уже использует gen AU, но очень аккуратно: они не гонятся за хайпом, а ищут конкретные, измеримые проблемы, где ИИ реально улучшает эффективность
- У ребят есть отдельные бюджеты и команды, которые экспериментируют с AI-подходами в тестировании и других задачах, системно отсеивая то, что “не взлетает”.
- Главный фильтр: безопасность и приватность данных
6️⃣ Главная мысль выпуска примерно такая
Зрелый финтех строится не вокруг модной технологии, а вокруг
- Строгой инженерной дисциплины (тесты, стандарты, CD)
- Осознанных архитектурных решений (JVM-ядро, cloud-first, но с пониманием ограничений)
- Системного взгляда на организацию и культуру
- Осторожного, прагматичного внедрения AI, где безопасность и ценность важнее демонстраций "магии"
P.S.
Интересно потом будет сравнить эти тезисы Витора с выступлениями Eric Young, нового CTO, что вышел только в конце лета.
#Software #Engineering #Management #Architecture #Processes #SRE #DevOps #Leadership
Telegram
Книжный куб
[1/2] Про Nubank (Рубрика #Business)
После изучения истории Lucas Cavalcant (distingueshed engineer @ Nubank) про развитие разработки в Nubank мне стало интересно, а какая у них глобальная стратегия и как IT поддерживает эту стратегию. В принципе, при текущем…
После изучения истории Lucas Cavalcant (distingueshed engineer @ Nubank) про развитие разработки в Nubank мне стало интересно, а какая у них глобальная стратегия и как IT поддерживает эту стратегию. В принципе, при текущем…
🔥5❤4👍1