Книжный куб

Сравнение сетевых подходов Google и Meta к построению сетей и инфры (Рубрика #Architecture) В этом посте я решил сравнить подходы запрещенной в России Meta и Google к своей сетевой архитектуре. Суть в том, что обе эти компании в 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

Фильм "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

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

[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

[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

[1/4] 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

Конструктор Gravitrax (Рубрика #ForKids) Пару дней назад моему младшему сыну исполнилось 5 лет, поэтому последние пару дней он постепенно разгребает подарки от семьи, друзей, сокамерников по детскому саду и так далее. А сегодня вечером мы добрались до подарка наших друзей, который представляет собой этот конструктор Gravitrax. На самом деле сын со своей няней еще вчера собрали простую трассу, а сегодня мы всей семьей собирали одну из самых сложных, доступных в этом starter kit. Мы справились и насладились нетривиальным движением трех шариков - дети оценили подарок, поэтому скоро мы докупим еще деталей, чтобы строить трассы еще больше, быстрее и сложнее:) #Thinking #ForParents #ForKids

Code of Leadership #57 - Interview with Pavel Golubev, Principal DS at Microsoft, about DS & AI (Рубрика #AI) Интервью с Павлом Голубевым, principal data scientist в Microsoft, который как и я когда-то закончил Физтех. Но дальше Паша ушел в консалтинг и оптимизировал цепочки поставок, а дальше двинулся в сторону data science. В какой-то момент он оказался зарубежом, где успел поработать над аналогом Uber из Греции (Beat), EPAM, а потом перейти в Microsoft и заняться DS проектами для клиентов Azure в EMEA.  За 2 часа и 40 минут мы обсудили множество тем, среди которых следующие - Знакомство с Павлом: Principal DS в Microsoft NL, индустриальные решения (энергетика/производство) - Ранний путь: арабистика МГУ → первый разворот к аналитике - Переход в IT: Женева, математика/статистика/программирование, MATLAB - Возвращение в РФ: аналитика цепей поставок в Renault - Консалтинг «в поле»: ТЭЦ, ручные журналы, наблюдение за процессами - Рост компетенций: Python, курсы, ODS, статья на Хабре → новые офферы - Кейсы из консалтинга: DSS с PPR, смарт-контракты, оптимизация распределения еды - Reaktor и Ближний Восток: длинные продажи, «глянцевые» решения, специфика рынка - Спад рынка/пандемия: сокращения инвестиций, закрытие офиса в Дубае - Поиск в Европе: офферы, выбор Нидерландов («ruling»), переход в Beat - Beat в Латам: безопасность, антифрод, «пирамида фрода» и профайлинг нарушителей - Ошибки роста и крах Beat: Tesla, маркетинг, монолит, регуляторика → банкротство - Мост через Epam: менеджерские проекты, осознанный поиск более амбициозной роли - Microsoft: работа в Solutions Engineering, проекты, реструктуризации и переход в Principal Engineer из менеджерской ветки Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. P.S. Паша ведет интересный канал https://t.me/corporateAI #AI #DS #Career #Staff #Engineering #Software #Management #Leadership

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

[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

[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

[5/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Снижение затрат на оборудование (Рубрика #Infrastructure) В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3 и 4) и обсудим снижение затрат на инфру. All global datacenters as a computer Подход Meta к восприятию своей инфры отлично описывается очередным инсайтом

Insight 6 : Meta is evolving from the practice of “the datacenter as a computer” to the vision of “all global datacenters as a computer.” In this model, the infrastructure autonomously determines and migrates deployments across global datacenters in response to workload changes, eliminating the need for user involvement. We have successfully demonstrated this approach for databases, ML systems, and diverse services operating at the scale of O(100,000) servers and O(100,000) GPUs.

Hardware and software co-design Но при этому появляется потребность в совместном проектировании софта и железа для него - Graceful degradation: эффективная инфраструктура должна уметь адаптивно деградировать при экстремальных ситуациях, чтобы не держать постоянный избыточный запас мощности про запас. В Meta система Defcon умеет отключать функциональность по уровням приоритетности, освобождая ресурсы для ключевых сервисов - Экономия на proxy в service mesh: в индустрии распространена архитектура service mesh с sidecar proxy per service, который перехватывает и маршрутизирует запросы. Meta разработала свою систему ServiceRouter (~1% RPC-запросов проходят через proxy, а 99% - маршрутизируются напрямую с помощью встроенной в каждый сервис библиотеки). Это экономит 100k+ серверов - Многоуровневое хранение данных: чтобы оптимизировать расходы на хранение, данные разделяются на категории по частоте доступа и допустимой задержке -- Горячие данные (соцграф, ленты, кеши) хранятся в высокопроизводительных системах (RAM + SSD) -- Тёплые данные (фото/видео пользователей, кликстрим) хранятся в распределенной файловой системе Tectonic на обычных HDD-дисках (1 server ~36 HDD + 2SSD для metadata) -- Холодные данные (оригинальные видео высокого качества) архивируются на ультраплотных storage-серверах с большим числом медленных дисков (1 server ~216 HDD) - Локальные SSD вместо сетевых хранилищ: в индустрии облачных сервисов считается хорошей практикой выносить хранение отдельно на блочное устройство для простоты миграций и балансировки нагрузки. Но в Meta ради экономии и низкой latency предпочитают локальные SSD даже для stateful-сервисов, где это возможно. От этого возникают сложности, которые Meta решает централизованно через систему управления шардированием (Shard Manager), которая абстрагирует размещение фрагментов данных и обеспечивает автоматический ребаланс - Дешёвое оборудование с надёжностью через софт: в публичных облаках оборудование часто дублируется, потому что приложения клиентов могут быть не готовы к сбоям. Meta выбрала противоположный подход - использовать более простое и дешёвое железо, но заставить всё ПО быть устойчивым к отказам. В итоге, очередной инсайт звучит так

Insight 7 : To reduce hardware costs, we use software solutions to overcome the limitations of lower-cost hardware. Although this approach adds complexity to the software stack, we consider the trade-off worthwhile due to the significant cost savings.

In-house hardware design Для всего описанного выше Meta сама разрабатывает конструкции ЦОДов (Open Compute датацентры), а также значительную часть оборудования. Контроль над дизайном позволяет убирать всё лишнее и повышать эффективность (особенно эффективность использования электроэнергии, что сейчас является бутылочным горлышком для ДЦ)

Insight 8 : To reduce hardware costs and power consumption, Meta designs its own datacenters, servers, racks, and network switches, and shares these designs through open source.

В следующем посте мы поговорим про то, как инженеры в Meta проектируют свои системы. #Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[4/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Повышение продуктивности разработки (Рубрика #Infrastructure) В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2 и 3). Мы поговорим про то, какие аспекты позволяют быть разработчикам внутри Meta более продуктивными. Continuous deployment и автоматизация Одной из главных целей общей инфраструктуры Meta является ускорение работы разработчиков. В компании довели до экстрима подходы CI/CD, добившись практически полного автоматического выпуска обновлений. 97% сервисов Meta разворачиваются без ручного участия инженеров - изменения поставляются через автоматические пайплайны деплоя (более 30к пайплайнов следят за обновлениями). Около 55% сервисов используют реально непрерывный деплой, остальные ~42% - развёртываются роботами по расписанию (как правило, ежедневно или еженедельно). Например, фронтенд-платформа Meta (serverless-функции, обслуживающие пользовательские запросы) релизится каждые три часа, а она работает на 500к+ серверов и ее код ежедневно меняют 10к+ разработчиков. Конфигурация как код и мгновенные изменения В Meta разграничение между “кодом” и “настройками” практически стёрто - конфигурационные изменения обрабатываются теми же конвейерами, что и программный код. Каждый день более 100к изменений конфигураций автоматически применяется на продакшене с помощью внутренней системы управления настройками. Они затрагивают порядка 10к различных сервисов и 1M+ запущенных процессов по всему миру (настройки параметров балансировки нагрузки, включение feature flags, настройки A/B тестов, ...). Практически каждый инженер Meta, пишущий код, также вносит правки в “живые” конфиги: - Они хранятся в репе как код - Проходят peer-review - Раскатываются через CD pipelines - Агенты по принципу publish-subscribe раскатывают изменения на сервисы - Приложения применяют новые параметры на лету, без перезапуска процессов Из этого следует четвертый инсайт статьи

Insight 4 : Even for a large organization with O(10,000) services, it is feasible to adopt continuous deployment at extreme scales and speeds. Specifically, 97% of our services adopt fully automated deployments without manual intervention, and 55% deploy every code change instantly.

Инструменты для качества и быстрого отката Стремление “выпускать сразу” неизбежно повышает риски сбоев, поэтому в Meta разработаны многоуровневые средства для безопасного развертывания. Перед полным выкатом новый код проходит автоматические тесты и канареечные прогоны. В случае обнаружения проблем хорошо отлажены механизмы мгновенного отката до предыдущей стабильной версии. Serverless functions как основа разработки Более 10 000 разработчиков Meta используют FaaS ежедневно, а это устраняет необходимость в управлении инфраструктурой: код автоматически масштабируется и разворачивается и оптимально использует инфру. Использование FaaS интегрировано в IDE (облегчен доступ к социальному графу и бэкенд‑системам). FaaS - это stateless архитектура, которая опирается на внешние кэш‑системы и базы данных, что обеспечивает предсказуемое поведение и простоту горизонтального масштабирования.У Meta есть две FaaS платформы: - FrontFaaS для обработки пользовательских запросов (PHP, Python, Erlang, Haskell) с low latency - XFaaS для обработки асинхронных, событийных функций с резкими пиковыми нагрузками. Они оптимизируются через глобальный балансировщик, отложенное выполнение и квот‑троттлинг, чтобы избежать оверпровижининга. Эту часть обобщает пятый инсайт

Insight 5 : Serverless functions have become the primary coding paradigm for product development at Meta. More than 10,000 Meta engineers write code for serverless functions, exceeding the number of engineers writing regular service code by 50%.

В следующем посте мы поговорим про то, как Meta уменьшает свои затраты на инфраструктуру. #Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

State of Developer Ecosystem 2025 от JetBrains (Рубрика #DevEx) Наконец-то дошли руки прочитать отчет по результатам ежегодного опроса от JetBrains. Этот ежегодный отчет входит в список тех, что я отслеживаю и в которых рассказывается интересная инфа про developer productivity и влиянии AI на него (вот тут я рассказывал про эту подборку). Но если возвращаться к самому отчету JetBrains, то вот основные моменты, которые показались мне интересными (кстати, результаты интересно сравнивать с прошлогодним отчетом, доступным здесь) 🤖 ИИ – новая норма 85% разработчиков регулярно используют AI-инструменты (против ~80% год назад). 62% применяют хотя бы одного AI-ассистента при кодинге, хотя 15% всё ещё работают без ИИ. 68% опрошенных ожидают, что скоро знание ИИ станет обязательным требованием работодателей. Разработчики охотно доверяют нейросетям рутинные задачи (например, генерацию шаблонного кода, перевод между языками, автодокументацию), но творческие и сложные задачи предпочитают выполнять самостоятельно. Среди главных опасений, связанных с ИИ: непостоянное качество кода, риски безопасности и приватности, а также возможная деградация собственных навыков. ⚙️ Языки и технологии TypeScript продолжает стремительно расти и вместе с Rust и Go входит в тройку самых перспективных языков 2025 года (в 2024 вместо Go в лидерах был Python). Больше всего разработчиков хотят выучить Go и Rust как следующий язык. Одновременно PHP, Ruby и Objective-C продолжают терять популярность. Scala вновь выделяется как язык с самыми высокими зарплатами: среди разработчиков с самыми высокими доходами 38% используют Scala, при том что лишь 2% программистов называют её своим основным языком. 📊 Продуктивность и DX В 2024-м компании фокусировались на технических метриках эффективности (скорость сборки, деплой, время восстановления и пр.), но в 2025-м подход сместился. Теперь внимание уделяют общей продуктивности разработчиков и качеству их опыта (Developer Experience): важны не только инструменты и процессы, но и коммуникация, прозрачность целей, обратная связь в команде. 66% инженеров не верят, что текущие KPI отражают их реальный вклад. Руководство всё так же хочет снижать tech debt и улучшать сотрудничество, а разработчики ценят ясность задач и конструктивный фидбек — метрики успеха приходится переосмысливать. 🌍 Рынок и реальность Восприятие рынка труда сильно различается: 57% разработчиков в Японии считают его благоприятным, тогда как в Канаде 66% говорят о сложностях. Новичкам сложнее: 61% джунов оценивают рынок как трудный (против 54% среди сеньоров). С ростом опыта меняются и ежедневные проблемы: на смену чисто техническим задачам приходят вопросы координации (переключение контекста и пр.). Несмотря на все вызовы, программисты любят своё дело: 52% даже пишут код для удовольствия в свободное время (57% делают это под музыку, а 25% предпочитают тишину). И неизменный факт: котиков разработчики любят не меньше, чем собачек 😸🐶. #AI #Software #Engineering #Processes #Metrics #Management #Survey

[3/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Сквозная обработка пользовательских запросов (Рубрика #Infrastructure) В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1 и 2). Мы поговорим про обработку пользовательских запросов, которая спроектирована end-to-end для достижения нужного уровня качества (latency, scalability, reliability, ...) и стоимости. Глобальная сеть и точки присутствия (PoP) Чтобы минимизировать задержки, Meta динамически направляет запросы пользователя к ближайшему своему узлу. Когда пользователь открывает, например, facebook.com, DNS Meta возвращает IP ближайшего point of presence (PoP) - небольшого edge датацентра, который завершает входящее соединение от пользователя и проксирует трафик в основные регионы датацентров Meta по заранее установленным долгоживущим соединениям (внутри своей WAN сети). Это позволяет сократить время установления соединения и сбалансировать нагрузку между регионами CDN и кеширование статичного контента Если пользовательский запрос касается статического контента, то ответ может быть дан напрямую на уровне PoP, если там содержится свежий кеш. Meta также размещает кеш-серверы внутри сетей интернет-провайдеров при большом объёме трафика. Маршрутизация динамических запросов Если запрос не относится к статическому контенту (то есть требует генерации ответа на лету), PoP перенаправляет его во внутреннюю сеть Meta. Специальный балансировщик нагрузки в выбранном регионе ЦОД принимает входящий поток и распределяет запросы по фронтенд-серверам. В Meta фронтенд реализован как масштабируемый serverless слой: каждый пользовательский запрос обрабатывается отдельной фронтенд-функцией, которая может вызывать множество бэкенд-сервисов для составления ответа. Здесь появляется второй инсайт от автора статьи

Insight 2 : Meta’s global infrastructure consists of CDN sites, edge datacenters, and main datacenters. Because of the high volume of our internal cross-datacenter traffic, we have built a private WAN to connect our datacenters, rather than relying on the public Internet.

Асинхронная обработка и офлайн-вычисления Для задач, не критичных к мгновенному ответу, широко применяется асинхронная обработка. Фронтенд-функции могут ставить события в очередь, которые будут обработаны отдельно специальными фоновыми функциями без блокировки ответа пользователю. Такие event-driven функции запускаются параллельно, их выполнение оптимизировано под пропускную способность (throughput), а не задержки (latency), и они не влияют на время ответа основного запроса. В то же время всё, что происходит при обработке запросов, генерирует огромные объёмы данных, которые непрерывно сбрасываются в хранилище данных (data warehouse). Дальше офлайн-системы Meta используют накопленные данные для пакетных и стриминговых вычислений, которые потом используются онлайн-сервисами при обработке новых пользовательских запросов. Здесь появляется третий инсайт от автора статьи

Insight 3 : Using a data warehouse as an intermediate layer to decouple online and offline processing simplifies the architecture and enables independent optimizations.

Это является ключевым принципом устойчивости и эффективности при гипермасштабе. Топология и масштаб инфраструктуры Масштаб инфраструктуры примерно следующий - Регионов в компании десятки, в каждом регионе множество датацентров, в которых сотни тысяч серверов - PoPs сотни, в каждом из них от сотен до тысяч серверов - CDN site тысячи, в каждом из них типично десятки серверов, но иногда бывают и сотни - MSB (main switchboards) - штука для секционирования питания внутри датацентров, их дюжины в датацентрах, типично MSB обслуживает десятки тысяч серверов В следующем посте мы поговорим про подходы, что обеспечивают продуктивность инженеров Meta. #Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[2/6] Meta’s Hyperscale Infrastructure: Overview and Insights - Аспекты инженерной культуры (Рубрика #Infrastructure) В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta и поговорим про аспекты инженерной культуры, которая позволяет быть компании успешной. Если сокращать, то эти аспекты звучат так - Принцип "Move fast" - Открытость технологий - Research in production - Единая инфраструктура и стандартизация А теперь давайте поговорим про каждый пункт подробнее. Принцип "Move fast" С первых дней в Facebook закрепилась культура быстрого развития и итераций. Это выражается в агрессивной практике непрерывного развёртывания ПО - новый код доставляется в продакшн как можно скорее. Большинство продуктовых сервисов пишутся в виде serverless функций на простых языках вроде PHP, Python, Erlang, что упрощает и ускоряет цикл разработки и деплоя изменений. Команды могут легко менять приоритеты и запускать новые продукты без долгих бюрократических процессов. Открытость технологий Meta придерживается открытой инженерной культуры как внутри, так и вне компании. Внутри действует единый монорепозиторий для всего кода, причём в большинстве проектов нет жёстко закреплённых владельцев - любой инженер может внести улучшения непосредственно, что поощряет переиспользование решений и кросс-командный вклад.Внешне компания делится разработками с сообществом: Meta открыто публикует аппаратные дизайны через проект Open Compute и открывает исходный код ключевых систем (таких как фреймворк ИИ PyTorch, база данных RocksDB, библиотека рекомендаций ReAgent и др.) Research in production В Meta нет отдельной академической исследовательской лаборатории по системам, а все инновации рождаются прямо в продуктах. Команды инфраструктуры постоянно внедряют новые решения и затем оформляют опыт в научные статьи. Такой подход гарантирует, что исследования сфокусированы на реальных проблемах и проверены в боевых условиях, что повышает практическую ценность и надёжность предлагаемых решений. Интересно, что во многих классических компаниях в отличие от Meta сделано по другому. Там отдельные RnD лабы публикуют материалы о космических результатах, которые найдены на кончике пера и еще не доехали на продакшен, а может никогда не доедут (так как все понимают, что в продакшен окружении они просто не работают) Единая инфраструктура и стандартизация В Meta стараются избегать разрозненных групп технологий - вместо этого продвигается глобальная оптимизация. На уровне аппаратуры все сервисы работают на унифицированном парке серверов: для вычислительных (не AI) нагрузок выбран один тип стандартного сервера (ранее с 64 ГБ RAM, теперь 256 ГБ). В отличие от облачных провайдеров, предлагающих множество конфигураций под любые клиентские нужды, Meta может сама оптимизировать своё ПО под ограниченный набор оборудования, избегая распыления на зоопарк железа. То же с софтом: разные продукты, бывало, применяли разные хранилища (Cassandra, HBase и собственный ZippyDB), но со временем все консолидировались на одном решении - ZippyDB для хранения пар «ключ-значение». Для каждой распространённой потребности (деплой, конфигурации, service mesh, тестирование производительности и т.д.) используется единый инструмент, принятый повсеместно внутри компании. Стандартизация дополняется модульностью: Meta предпочитает строить системы из переиспользуемых компонентов, а не как монолиты. Все эти принципы демонстрируются через пример с запуском приложения Threads (конкурента Twitter/X) - 5 месяцев на разработкку небольшой командой и подготовка инфры за 2 дня до запуска, что прошел успешно. В конце этой части приводится первый инсайт

Insight 1 : Despite many challenges, it is feasible for a large organization to maintain a culture of moving fast, using a common infrastructure, and sharing a monorepo without strictly enforcing code ownership.

В следующем посте мы поговорим про подходы к собработке пользовательских запросов. #Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[1/6] Meta’s Hyperscale Infrastructure: Overview and Insights - Общее содержание статьи (Рубрика #Infrastructure) В январе 2025 года вышла интересная статья об инфраструктуре компании Meta, чья деятельность запрещенна в России. Статья представляет собой обзор гипермасштабной инфраструктуры компании Meta (ранее Facebook) - той самой планетарной вычислительной системы, которая обслуживает миллиарды пользователей Facebook, Instagram и других приложений. Автор, Чунцян Тан (Chunqiang Tang), старший директор и исследователь в Meta, обобщает ключевые уроки, извлечённые за годы развития этой инфраструктуры. Хотя немногие инженеры напрямую строят столь масштабные системы, принципы и технологии, возникшие в среде гиперскейлеров (таких как Meta, Google, Amazon и др.), со временем становятся полезными повсеместно. Статье акцент сделан на комплексном видении всей инфраструктуры от начала до конца( как разные компоненты связаны между собой), а также на отличиях подходов Meta от публичных облаков. Chunqiang Tang имеет богатый опыт: он пришёл в Meta из IBM Research и опубликовал множество работ по системам и инфраструктуре, а в Meta он руководит исследовательскими проектами в областях ускорения ИИ, облачных вычислений и высокопроизводительных систем. Статья состоит из следующих частей, которые мы рассмотрим дальше ⚙️ Engineering Culture - аспекты инженерной культуры, которые помогают компании двигаться быстро и эффективно ✈️ End-to-End User Request Flow - подходы к собработке пользовательских запросов так, чтобы обеспечить нужный уровень качества (latency, scalability, reliability, ...) 📈 Boosting Developer Productivity - принципы, которые позволяют повышать продуктивность инженеров 💰 Reducing Hardware Costs - за счет чего достигается снижение костов на инфру 🌐 Designing Scalable Systems - принципы проектирования систем внутри Meta, чтобы весь пазл принципов сложился 🚀 Future Directions - куда все будет двигаться дальше со стороны инфры, архитектуры и процессов разработки В следующем посте мы обсудим аспекты инженерной культуры Meta. #Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

Мальдивы 2025 Вот и закончился отпуск на Мальдивах, куда мы слетали вместе с друзьями. Выяснилось, что летать вместе семьями интереснее - дети начинают вместе тусить в детском клубе и не только, а у взрослых образуется побольше свободного времени для снорклинга, сейлинга, дайвинга и коктейлинга:))

Good News For Startups: Enterprise Is Bad At AI (Рубрика #AI) В этой серии подкаста ребята из Y Combinator обсуждали исследование "The GenAI Divide: State of AI in Business 2025" (см. мой разбор), результаты которого говорят о том, что 95% корпоративных AI-проектов проваливаются. Обсуждение строится на том, а в чем причины этих результатов и почему это на руку AI стартапам, а если точнее, то ребята обсуждают вопросы - Что на самом деле стоит за вирусной статистикой о "95% провалов" AI-проектов? - Почему внутренние IT-проекты даже в крупных компаниях зачастую буксуют? - Что усложняет внедрение сложных AI-систем в корпоративной среде? - Как небольшие AI-стартапы выигрывают конкуренцию у банков и консалтинга? - Почему устоявшиеся компании не могут создать работающий AI-продукт и что с этим делать? Мнения управляющих партнеров Y-Combinator примерно такое: - Броска фраза «95% провалов» искажена: она относится к внутренним решениям в корпорациях, которые не умеют учиться на обратной связи и адаптироваться. Иными словами, дело не в том, что "ИИ не работает", а в том, что большие компании не умеют его строить. Здесь авторы пинают Apple за их приложение-календарь, а уж если Apple делает хреновые решение, то и у обычных компаний и подавно будут проблемы. Большинство корпоративного ПО очень посредственное, а привлечение дорогих консультантов (E&Y, Deloitte) часто только создаёт "две проблемы вместо одной". - В крупных компаниях существуют организационные сложности: AI-проекту надо учитывать интересы множества команд, преодолевать политические барьеры и согласовывать требования между отделами. Добавьте устаревшие легаси-системы и дизайн "от комитетов" - внедрение AI превращается в долгий и трудный процесс - AI-стартапы побеждают там, где корпорации пасуют: маленькие команды быстро строят решения под конкретные задачи, сразу с заложенными AI-возможностями (AI-native) и оперативно доводят продукт до результата. Привели кейсы: стартап Tactile за считанные месяцы сделал для банков AI-систему принятия решений, тогда как Citi и JP Morgan потратили годы и миллионы на нерабочие аналоги - Сейчас для AI-стартапов идеальный момент: крупные фирмы жаждут внедрить ИИ и готовы рисковать с молодыми командами. Боязнь отстать заставляет корпорации быстрее принимать решения и скорее купить готовое AI-решение, чем пытаться сделать своё. Ребята из стартап-инкубатора нахваливали возможности для стартапов в каждом процессе: спрос на AI настолько опережает внутренние возможности компаний, что в каждой нише есть пространство для внешнего решения - Если возвращаться к гипотезам, которые могли бы объяснить провалы внедрение, то подкастеры выделили человеческий фактор: многие корпоративные инженеры не верят в ИИ, не пользуются новыми инструментами и даже рады ссылаться на исследования вроде MIT, подтверждающие их скепсис. Такая культура приводит к провалу проектов (самосбывающееся пророчество) и упущенным возможностям. В результате предприятия, где внутренние команды сдались, готовы звать на помощь стартапы. В общем, 95% неудач внедрения AI в корпорациях - это не повод не пробовать. Наоборот, у вас есть все возможности попасть в 5% успешных. Правда, партнеры одного из крупнейших стартап-инкубаторов говорят, что крупные компании, скорее всего, будут всё активнее обращаться к стартапам и покупать готовые AI-решения, поскольку внутренние команды не справляются:) Но я бы тут сделал скидку на конфликт интересов и трактовал это как возможности не только для стартапов, но и для самих корпораций нарастить свои внутренние возможности по использованию AI. #AI #Engineering #Software #Leadership #ML

[2/2] Hands-On Large Language Models (Рубрика #AI) Продолжая рассказ про эту книгу, скажу о том, что она состоит из трех частей и 12 глав (я пока прочитал четыре с половиной главы, поэтому про них расскажу подробнее). Но если кратко, то книга начинается с основ LLM, дальше авторы переходят к их использованию для решения задач, а заканчивают методами обучения моделей. Часть I: Понимание языковых моделей Первая часть закладывает фундамент, объясняя, что такое языковые модели и как они устроены. Глава 1. Здесь приведен обзор развития обработки языка - от "bags of words и классических представлений текста до появления методов вроде word embeddings и архитектуры трансформеров. Читатель узнает, что собой представляют большие языковые модели, и чем они отличаются от предыдущих подходов. В главе также обсуждается, почему LLM стали настолько полезными. Глава 2. Авторы погружаются в тему токенизации и эмбеддингов - ключевых понятий для представления текста в численной форме. Авторы подробно описывают, как работает токенизатор LLM (преобразуя текст в токены), сравнивают разные виды токенов (слова, подслова, символы, байты) и демонстрируют свойства обученных токенизаторов. Далее рассматривается, как модель превращает токены в векторные представления (эмбеддинги) и как эти эмбеддинги могут использоваться для представления слов, предложений и документов. Приводятся примеры, как с помощью эмбеддингов измерять семантическую близость текстов. В этой же главе объясняются традиционные алгоритмы построения эмбеддингов (например, word2vec) и более современные подходы, вплоть до того, как LLM сами формируют эмбеддинги во время работы. Завершает главу практический пример: обучение модели эмбеддингов для рекомендательной системы (например, рекомендация песен по схожести эмбеддингов). Глава 3. Авторы показывают внутренности трансформера, объясняя что происходит под капотом. Они рассказывают про forward-pass модели: как обрабатываются входные токены, как вычисляется матрица внимания (attention) и как на её основе модель выбирает следующий токен. Важная часть главы - интуитивное объяснение механизма Self-Attention (внимания), благодаря которому модель учитывает контекст слов при генерации. Также обсуждаются оптимизации: как модели обрабатывают несколько токенов параллельно, какой максимальный размер контекста поддерживается, и как кеширование ключей и значений ускоряет генерацию текста. Часть II: Использование предварительно обученных моделей Вторая часть посвящена практическим способам применения готовых языковых моделей и эмбеддингов в разных задачах обработки текста. Здесь авторы переходят от устройства моделей к их использованию "из коробки" для решения прикладных задач. Глава 4. Классификация текста Глава 5. Кластеризация и тематическое моделирование (BERTopic) Глава 6. Инженерия промтов (Chain of Thought, ReAct, Tree of Thought) Глава 7. Продвинутые техники генерации текстов и инструменты (LangChain и агенты, Memory, Tools) Глава 8. Семантический поиск и Retrieval-Augmented Generation (RAG) Глава 9. Мультимодальные модели (текст + картинки, CLIP, BLIP-2) Часть III: "Обучение и тонкая настройка моделей" Последняя часть книги посвящена тому, как создавать свои модели и адаптировать существующие LLM под конкретные задачи. Здесь материал становится более продвинутым Глава 10. Создание моделей эмбеддингов для текста Глава 11. Fine-tuning representation models для классификаций Глава 12. Fine-tuning генеративных моделей В заключительной части (Afterword) авторы подводят итоги проделанному пути и заглядывают в будущее развития больших языковых моделей. Они отмечают, какой колоссальный и широкомасштабный эффект LLM уже оказали на мир и что понимание принципов их работы открывает перед специалистами новые возможности. #Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems