[6/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Проектирование масштабируемых систем (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3, 4 и 5) и обсудим как ребята подходят к проектированию масштабируемых приложений.

Централизация vs децентрализация
Инфраструктура планетарного масштаба исторически ассоциируется с децентрализованными архитектурами (BGP, BitTorrent, и т.п.). Они хорошо масштабируются без SPOF (single point of failure). Однако опыт Meta показал, что в пределах датацентра, где ресурсы относительно надёжны и управляются одной организацией, централизованные контроллеры зачастую упрощают систему и при этом обеспечивают достаточную масштабируемость. А часто это еще позволяет принимать более глобально оптимальные решения, чем множество локальных агентов. Поэтому Meta сознательно отошла от многих изначально распределённых дизайнов в сторону управляемых централизованно. Например,
- Внутренняя сеть ЦОД (Fabric) по-прежнему использует протокол BGP для совместимости, но маршрутизацией управляет центральный контроллер, который при перегрузках или обрыве линков переоптимизирует пути трафика взамен медленной сходящейся динамики BGP
- В магистральной глобальной сети (WAN) Meta изначально применяла децентрализованный протокол резервирования полосы (RSVP-TE), но затем перешла на центральный контроллер, рассчитывающий оптимальные пути для потоков между датацентрами и заранее прокладывающий резервные каналы на случай типовых отказов. Это позволило значительно эффективнее использовать пропускную способность каналов и упростило управление сетью.

В общем случае подход Meta можно сформулировать таким инсайтом

Insight 9 : In a datacenter environment, we prefer centralized controllers over decentralized ones due to their simplicity and ability to make higher-quality decisions. In many cases, a hybrid approach - a centralized control plane combined with a decentralized data plane-provides the best of both worlds.

В качестве примера подробнее разбирается гибридный service mesh под названием ServiceRouter (попытка получить “лучшее из двух миров”). ServiceRouter обслуживает миллиарды вызовов в секунду между микросервисами, распределёнными по миллионам программных маршрутизаторов уровня L7. В традиционных решениях service mesh (например, Istio) каждое приложение сопровождается локальным прокси, через который проходят все исходящие и входящие вызовы. В ServiceRouter Meta от этой схемы отказались (как упоминалось, ~99% запросов идут без sidecar-прокси). Вместо этого
- Control plane централизован - он агрегирует всю информацию о сервисах и глобальных метриках сети, вычисляет оптимальные правила маршрутизации и сохраняет их в RIB (outing Information Base), построенной поверх распределенной базы данных Delos с Paxos протоколом (то есть она распределена и отказоустойчива). Таким образом, центральные контроллеры ServiceRouter ответственны только за вычисление глобальных решений, а непосредическая работа по маршрутизации лежит на data plane.
- Data plane в виде отдельных L7 routers децентрализован - они автоматически подтягивают из RIB нужные им сведения (кэшируют небольшой необходимый поднабор) и работают автономно, без постоянного участия центрального координатора

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

В последнем посте из серии мы поговорим про будущие направления развития инфраструктуры и архитектуры Meta (это одна из самых интересных частей)

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[7/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Будущие направления развития (Рубрика #Infrastructure)

Этот пост финальный в рассмотрении крутой обзорной статьи от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3, 4, 5 и 6). Здесь мы обсудим как автор видит дальнейшее развитие инфраструктуры, архитектуры и проникновение AI в системы компании. Отмечу, что эта часть была мне очень интересна - сложить пазл о том, как развивалась история это одно, а сделать качественное предсказание - это уже задачка со звездочкой.

AI и новая архитектура дата-центров
AI-нагрузки уже стали главным потребителем ресурсов Meta: к концу десятилетия они займут более половины мощностей ЦОД. В отличие от классических веб-сервисов, обучение моделей требует сотен терабайт данных, мощных GPU и сверхбыстрых сетей. Это ведёт к смене парадигмы — от scale-out (много дешёвых узлов) к scale-up, когда создаются крупные AI-кластеры, напоминающие суперкомпьютеры. Meta выстраивает полный стек под AI: от PyTorch и моделей до собственных чипов (MTIA), сетевых решений, хранилищ и систем охлаждения. Всё проектируется комплексно, чтобы работать синхронно. В будущем датацентры наполовину станут «машинами для обучения ИИ» - это изменит всю их архитектуру.

Эра специализированного железа
После эпохи унификации серверов начинается обратный процесс: расцвет кастомных ASIC и ускорителей. Гиперскейлеры могут позволить себе проектировать собственные чипы для AI-тренинга, компрессии, шифрования, видео-кодирования, In-Network-/In-Storage-Processing и т.д. Meta ожидает, что ЦОДы превратятся в гетерогенные кластеры из множества типов оборудования. Главный вызов - научить софт эффективно использовать столь разнородные ресурсы. Для этого потребуются новые уровни абстракций и оркестрации. Но выигрыш в энергоэффективности и стоимости на миллионах серверов окупит усилия.

Краевые датацентры и метавселенная
Meta прогнозирует бурный рост инфраструктуры на «краю» сети — мини-ЦОД, близких к пользователям. Это нужно для AR/VR, облачного гейминга и IoT, где критична задержка <25 мс. Компания строит модель Global Data-center-as-a-Computer: приложения будут автоматически выполняться там, где ближе пользователь, без участия разработчика. Архитектура станет многоуровневой - крупные регионы + сеть микро-ЦОД, объединённых общей системой оркестрации.

Прорыв в средствах разработки
Meta ожидает качественного скачка продуктивности инженеров за счет двух факторов
1. Массовое внедрение AI-ассистентов (Copilot, GPT-4 и др.), которые автоматизируют генерацию кода, поиск багов и рефакторинг и так далее
2. Появление вертикально интегрированных платформ, где разработчик описывает только бизнес-логику, а инфраструктура скрыта под капотом.
Пример - внутренний проект FrontFaaS, ускоряющий создание веб-интерфейсов. Похожие фреймворки появятся и в других доменах, радикально повышая индивидуальную продуктивность.

Совместное развитие
Автор подчёркивает: за 20 лет гиперскейлеры задали темп всей индустрии, и ИИ лишь ускорит этот процесс. Чтобы инновации распространялись быстрее, нужно делиться опытом. Meta призывает публиковать открытые проекты и исследования — как она делает сама. Статья служит именно этой цели: показать, из каких «кирпичиков» строится инфраструктура Meta и какие принципы могут вдохновить инженеров по всему миру.

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

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сравнение подходов 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

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

[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

State of Devops Russia 2025 (Рубрика #Devops)

Несколько дней назад были опубликованы результаты большого опроса про состояние DevOps в России. Наступили выходные, я его дочитал и решил написать тезисный разбор. Кстати, если этот разбор понравится, то можно его сравнить с глобальным DORA отчетом за 2025 год, о котром я уже писал. Но вернемся к этому опросу

- Производительность команд выросла: суммарная доля высокоэффективных команд (профили Elite и High) увеличилась на 6% по сравнению с прошлым годом, и ключевые показатели эффективности (частота релизов, скорость доставки, время восстановления, процент неудачных изменений) улучшились. Напомню, что в стандартном подходе все компании бьются на 4 кластера: low, medium, high, elite на основе 4 метрик DORA (deployment frequency, lead time for changes, change failure rate, mean time to restore).
- DevEx дает эффект: у высокоэффективных команд налажены быстрые и качественные циклы обратной связи, ниже когнитивная нагрузка и выше автономность инженеров (подробнее про модель DevEx я уже писал)
- Гибридная модель потребления: оркестраторы рабочих нагрузок не используют только ~15% опрошенных, остальные предпочитают c отрывом K8s (~51% разворачивают его on-prem, ~25% гибридно, еще 25% в облаке или нескольких). Данные треть хранит on-prem, треть гибридно, а треть в облаке.
- Повышение использования IDP: внутренние платформы разработки превращаются в обязательный атрибут крупных компаний с активной разработкой. Более 45% респондентов уже используют IDP для управления доступами и поиска необходимой информации. Главная цель развития внутренних платформ на 2025 год – максимальная автоматизация рутинных задач. Крупный бизнес рассматривает IDP как способ унификации процессов разработки и усиления контроля безопасности
- Информационная безопасность стала приоритетом: большинство команд теперь интегрируют её в процессы разработки (77% используют инструменты ИБ)
- Инструменты AI получили массовое распространение: ~71% опрошенных говорят, что применяют AI/ML в работе (чаще всего для генерации кода), при этом более половины уже отмечают рост продуктивности благодаря AI
- Продолжается импортозамещение: растёт использование российских OS и K8s-дистрибутивов вместо зарубежных аналогов
- Ситуация на рынке труда для devops инженеров изменилось: hh-индекс конкуренции (отношение резюме к вакансиям) вырос с 7,7 до 14,9 за год, то есть на одну позицию претендует больше инженеров

Исследование State of DevOps Russia 2025 проведено командой «Экспресс 42» (консалтинговое подразделение компании Flant) и стало пятым ежегодным отчётом о развитии DevOps в России. В опросе участвовало более 3300 специалистов из России и стран СНГ. Респонденты представляли широкий спектр отраслей и ролей в ИТ - среди них были как инженеры и DevOps-специалисты, так и руководители разных уровней из крупных, средних и небольших компаний. В общем, результаты можно с достаточной уверенностью считать репрезентативными для оценки текущего состояния DevOps практик.

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment