Кратко

  • Ion Stoica — профессор UC Berkeley, директор Sky Computing Lab и соучредитель Conviva, Databricks и Anyscale; Databricks указывает его должность как исполнительного председателя.
  • В его исследованиях состояние распределённых систем снова и снова переносится за более простые интерфейсы: от Core-Stateless Fair Queueing и Chord до предложений ресурсов Mesos, цепочек происхождения Spark, Ray и SkyPilot.
  • Эти системы создавали команды студентов, преподавателей, инженеров и участников проектов с открытым исходным кодом; Stoica выступал то соавтором, то научным руководителем, директором лаборатории или соучредителем компании.
  • Абстракции снижают нагрузку на разработчиков и операторов, но не делают сети, ускорители, облака, цены или управление единообразными; успех порождает новые плоскости управления и зависимости.

Распределённая система начинается со спора о том, где должно находиться состояние

Распределённые вычисления часто описывают через их механизмы: кластеры, планировщики, системы хранения, облака и ускорители. За этими продуктами стоит более устойчивый проектный вопрос: какая часть системы должна что помнить и какие участники могут действовать, не видя целого?

Когда всё состояние хранится в одном месте, решения легче понимать — пока принимающий их компонент не оказывается перегружен или недоступен. Распределение состояния способно повысить масштабируемость и устойчивость, но создаёт несогласованность, издержки координации и сложные режимы отказа. Если скрыть проблему за интерфейсом, программистам станет проще, однако скрытая работа не исчезнет: она перейдёт к плоскости управления.

Если смотреть через это противоречие, исследования Ion Stoica отличаются редкой последовательностью. В Core-Stateless Fair Queueing оценки потоков переносились к краю сети, а сведения передавались в пакетах, чтобы магистральным маршрутизаторам не требовалась таблица для каждого соединения. Chord отображал узлы и ключи на кольцо, позволяя участнику находить данные без глобального каталога. Internet Indirection Infrastructure использовала идентификаторы рандеву, отделяя связь от фиксированного адреса назначения. Mesos предлагал ресурсы прикладным фреймворкам, вместо того чтобы заставлять один планировщик понимать каждую нагрузку.

Ray предоставлял задачи и акторы, а размещением и восстановлением после сбоев управлял ниже уровня приложения.

Назначение и зрелость этих систем различаются. Одни стали широко изучаемыми протоколами, но не универсальной инфраструктурой. Другие превратились в проекты с открытым исходным кодом. Несколько систем легли в техническую основу компаний. Общим было стремление создать небольшой масштабируемый контракт на границе, где прямая координация иначе обходилась бы слишком дорого.

Эта преемственность делает Stoica полезной фигурой для анализа современной инфраструктуры, но одновременно создаёт ловушку приписывания заслуг. Профессор, руководивший проектом, соавтор алгоритма, директор лаборатории, финансировавший команду, и основатель, помогавший создать компанию, выполняют разные задачи. Spark неотделим от Matei Zaharia и сообщества AMPLab. Среди основных авторов Ray — Philipp Moritz, Robert Nishihara и более широкая команда RISELab. Databricks перечисляет семь соучредителей. Лаборатории Berkeley давали проекты, студентов, сотрудников, код и институциональную культуру, которые не принадлежали одному человеку.

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

Ранние исследования справедливости показали цену переноса состояния к краю сети

Stoica получил докторскую степень в Carnegie Mellon University в 2000 году; до этого он учился в Бухаресте. Его аспирантские исследования касались проблемы, знакомой каждому создателю общей инфраструктуры: справедливость проще обеспечить, когда система отслеживает каждого пользователя, но такое отслеживание может помешать масштабированию.

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

Dynamic Packet State и Core-Stateless Fair Queueing исследовали другое распределение обязанностей. Пограничные устройства оценивали скорость потока и помещали сведения в пакеты. Магистральные маршрутизаторы могли использовать эту метку для вероятностного отбрасывания пакетов, не поддерживая полную таблицу потоков. Ядро не было буквально лишено состояния: оно сохраняло общую конфигурацию и выполняло алгоритм. Состояния не было применительно к отдельным потокам.

Этот подход иллюстрирует закономерность, которая повторяется на всём профессиональном пути Stoica. Сложность не устраняется, а переносится на границу, где, как предполагается, больше контекста или ресурсов. Пограничный узел должен классифицировать трафик и давать достоверные оценки. Пакеты должны нести сведения в понятной ядру форме. Если пограничный узел сообщает ложные или неточные данные, приближённое решение ядра может оказаться неверным. Инкапсуляция и шифрование способны усложнить само определение потока.

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

Эта работа не стала универсальной архитектурой качества обслуживания в публичном интернете. Её значение отчасти заключается в методе: определить состояние, из-за которого механизм становится дорогим, найти место, где его можно представить дешевле, и точно указать, какая точность или степень доверия теряется при переносе.

В последующих системах те же рассуждения применялись к ключам, ресурсам кластера, происхождению данных и задачам ИИ. Единица менялась, архитектурный инстинкт сохранялся.

Chord свёл меняющуюся одноранговую систему к кольцу

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

Chord, представленный на SIGCOMM в 2001 году командой, куда входили Stoica, David Karger, Frans Kaashoek, Robert Morris и Hari Balakrishnan, предложил намеренно лаконичный ответ. Узлы и ключи хешировались в одном пространстве идентификаторов, располагались на логическом кольце, а каждый ключ назначался следующему узлу. Участник хранил сведения о непосредственном преемнике и логарифмический набор дальних указателей — «пальцев». Поиск проходил через всё более близкие идентификаторы, пока не достигал узла, отвечающего за ключ.

Согласованное хеширование ограничивало объём данных, которые требовалось перемещать при изменении состава участников. Процедуры стабилизации восстанавливали сведения о преемниках и указателях после таких изменений. Система не давала каждому участнику представления обо всей сети; она предоставляла достаточно структурированных знаний для эффективной маршрутизации запроса.

Chord стал классическим учебным примером: механизм достаточно компактен для анализа и одновременно достаточно содержателен, чтобы показать реальность распределённых систем. Расстояние между идентификаторами не равно сетевой задержке. Логически близкий узел может физически находиться далеко. Репликация, управление доступом, согласованность хранения и защита от злоумышленников остаются за рамками базового протокола поиска. Приложению всё равно приходится определять смысл ключа и способ обработки недоступных или противоречивых данных.

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

Его непреходящий урок касается ограниченного знания. Участник способен ориентироваться в большой меняющейся системе, если наложенная сеть задаёт устойчивую связь между именами и ответственностью. Кольцо действует как управляющая абстракция над машинами, которые остаются ненадёжными и неравномерно соединёнными.

Позднее эта идея в иной форме появилась в облачных плоскостях управления. Приложения редко знают каждый хост. Они полагаются на планировщик, сервис метаданных или каталог объектов, сопоставляющий логический запрос с текущими ресурсами. Chord явно поставил задачу такого сопоставления в период, когда главной темой была децентрализация. Более поздние системы централизовали части плоскости управления ради производительности, сохранив столь же узкий интерфейс для приложений.

Internet Indirection Infrastructure ослабила связь адреса с конечной точкой

Обычная интернет-маршрутизация направляет пакеты к адресу назначения. Такая модель становится неудобной, когда получатель перемещается, одни данные должны получить несколько адресатов или сервис выбирает из нескольких возможных конечных точек. Internet Indirection Infrastructure, или i3, исследовала уровень над IP, где отправители обращались к идентификаторам, а получатели устанавливали триггеры, связывавшие эти идентификаторы с текущими местоположениями.

Точка рандеву отделяла имя, используемое приложением, от адреса, который в данный момент мог принимать трафик. Один и тот же механизм позволял выразить мобильность, многоадресную рассылку, anycast и композицию сервисов. Получатель мог сменить местоположение, обновив триггер, и каждому отправителю не требовалось узнавать новый адрес.

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

i3 не заменила обычную интернет-маршрутизацию в широком масштабе. Это не означает провала исследования. Результат показывает устойчивое различие между выразительным механизмом и институтом, который можно внедрить. Публичному уровню рандеву нужны операторы, стимулы, безопасность и пути перехода. В существующем интернете уже были распределение адресов, DNS, сети доставки контента и специализированные обходные решения, за каждым из которых стояли заинтересованные участники.

Работы Stoica над Chord и i3 показали, что новые точки управления можно создавать поверх сети без замены каждого маршрутизатора. Они также показали, что новой точкой управления нужно управлять. Программное обеспечение может распределять идентификаторы, но кто-то всё равно эксплуатирует узлы, устанавливает правила против злоупотреблений и оплачивает мощности.

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

Berkeley сделал сообщества открытого кода частью исследовательского метода

Stoica пришёл в University of California, Berkeley, где его работа стала частью лабораторной модели, объединявшей руководство преподавателей, создание систем под началом студентов, рецензируемые исследования и раннюю публикацию открытого кода. По мере смены исследовательских программ менялись названия лабораторий — AMPLab, RISELab, а теперь Sky Computing Lab, — но сам метод оставался узнаваемым.

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

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

Известность Stoica в нескольких проектах может заслонять такую структуру. Он был научным руководителем и соавтором в академической истории Spark, но первоначальную работу возглавлял Matei Zaharia, который затем стал одной из ключевых технических и корпоративных фигур. Ray возник благодаря работе Philipp Moritz, Robert Nishihara и более широкой команды. У Mesos было несколько ведущих разработчиков. Точное описание не умаляет роли Stoica — оно показывает, чем в действительности занимается руководство лабораторией.

Модель Berkeley породила и особый тип компаний. Databricks и Anyscale начинали не с сокрытия протокола и продажи доступа к нему. Они формировались вокруг систем с открытым исходным кодом, которые пользователи уже могли запускать самостоятельно. Коммерческая возможность заключалась в том, чтобы упростить эксплуатацию, интеграцию и поддержку этих систем в крупном масштабе.

Такая схема создаёт устойчивое противоречие. Открытый код может расширить внедрение и сформировать общую техническую основу. Управляемая платформа способна финансировать разработку и снижать нагрузку на клиентов. У компании есть стимул добавлять вокруг открытого ядра собственные средства управления, интеграции и экономическую модель. Академическая лаборатория ценит публикации и универсальность; компания — надёжность, отличие от конкурентов и выручку.

Профессиональный путь Stoica проходит через эту точку соединения. Его значение связано не столько с превращением статей в стартапы, сколько с тем, что лаборатория раз за разом выбирала абстракции, способные жить за её пределами, а затем создавала институты для их переноса в промышленную эксплуатацию.

Chord, Spark, Mesos и Ray распространялись не только через код, но и через словарь. Кольца, происхождение данных, предложения ресурсов, задачи и акторы дали инженерам понятия для описания распределённого поведения. Систему проще внедрить, если команды могут рассуждать о ней, не изучая предварительно каждый внутренний компонент.

Университетская работа играет в этом процессе центральную роль. Статьи определяют механизмы и предположения. Курсы и семинары превращают их в общие модели мышления. Студенты переносят идеи в компании, проекты с открытым исходным кодом и последующие исследования. Поэтому влияние Stoica как профессора и директора лаборатории выходит за пределы написанного им кода или титулов основателя.

Однако словарь способен превратиться в догму. Аккуратная схема побуждает забыть об условиях, при которых работает абстракция. Кольцо Chord может скрывать физическую задержку. Происхождение данных Spark — стоимость повторного вычисления. Акторы могут выглядеть как обычные объекты, хотя сообщения задерживаются, а отказы распределены. Хорошее обучение показывает не только интерфейс, но и места, где абстракция даёт течь.

Избрание Stoica в National Academy of Engineering в 2024 году отмечает совокупность его работ в области распределённых и облачных систем. Эта честь не перераспределяет заслуги его соавторов. Она отражает роль исследователя, помогшего сделать несколько сложных системных границ достаточно понятными, чтобы другие могли на них опираться.

Возможно, это самая долговечная форма влияния на инфраструктуру. Продукты переименовывают, а компании расширяют сферу деятельности. Ясная абстракция сохраняется, потому что поколения инженеров могут использовать и критиковать её, а также замечать момент, когда её предположения перестают выполняться.

Conviva проверила, могут ли исследования распределённых систем улучшить видеосеанс

Stoica стал соучредителем Conviva в 2006 году — раньше последующих компаний Berkeley в области данных и ИИ. Бизнес решал задачу на пересечении сетей, измерений и пользовательского опыта: качество потокового видео зависит от цепочки, которую ни один участник не видит целиком. Соединение зрителя, маршрут доставки контента, поведение проигрывателя, устройство и поставщик контента могут влиять на остановки и время запуска.

Платформа измерений может собирать данные сеанса и помогать сервису выбирать или корректировать доставку. Концептуальная связь с исследованиями Stoica не означает, что конкретный алгоритм Chord или i3 превратился в продукт. Она заключается в необходимости достаточно быстро преобразовать распределённые наблюдения в управляющее решение, способное повлиять на впечатление пользователя. Система должна делать выводы по неполным данным и работать в сетях, которыми не владеет.

Создание Conviva показало ранний путь от академического системного мышления к коммерческому сервису. Клиенты покупали не статью о распределённом состоянии, а видимость, анализ и практические действия для потокового вещания. Компании требовалось поддерживать конвейеры данных, интеграции и модели под реальным трафиком, а затем объяснять результаты командам, отвечавшим за контент и доставку.

Граница авторства и здесь важна. Conviva — компания со множеством инженеров и руководителей, и её нынешние продукты нельзя приписать одному основателю. Финансовые показатели и частная форма собственности компании отделены от личного послужного списка Stoica. Существенен более узкий хронологический и институциональный факт: ещё до того, как Spark или Ray стали основой компаний, он помог построить бизнес, превращавший сетевые данные в прикладной сервис.

Этот опыт, вероятно, укрепил урок, заметный и в последующих работах. Инфраструктура приобретает ценность, когда меняет единицу, которой способен управлять клиент. Поставщик потокового видео не хочет разбираться в каждом маршруте пакета. Ему нужны достоверная оценка пользовательского опыта и способ его улучшить. Абстракция успешна, когда превращает сложное распределённое поведение в операционный выбор, не притворяясь, что лежащая в основе неопределённость исчезла.

Mesos превратил планирование в переговоры о ресурсах

Когда дата-центры стали объединять разнородные нагрузки в общих кластерах, перед центральным планировщиком возникла недостижимая цель. Он мог попытаться понимать приоритеты, правила размещения и модели выполнения каждого фреймворка — либо предоставить ресурсы и позволить специализированным фреймворкам самостоятельно принимать больше решений.

Mesos выбрал второй путь. Агенты сообщали master об имеющихся ресурсах. Master предлагал ресурсы фреймворкам. Фреймворк принимал часть предложения и запускал задачи согласно собственному планировщику. После завершения работы или изменения распределения ресурсы возвращались.

Эта двухуровневая модель превращала master в посредника, а не в универсальный мозг приложений. Hadoop, MPI и другие фреймворки могли совместно использовать кластер, не отказываясь от собственной логики планирования. Оператор кластера сохранял контроль над правилами через распределение, квоты и механизмы справедливости. Фреймворки отвечали за выбор задач, подходящих под предложение.

Разделение повышало расширяемость, но создавало новые проблемы. Фреймворк мог неудачно разместить задачи или неэффективно удерживать ресурсы. Предложения могли дробить кластер на части, не подходившие крупным заданиям. Справедливость между разными типами ресурсов требовала правил. Master и агентам всё равно были нужны отказоустойчивость и надёжное состояние.

Mesos повлиял на более широкую сферу оркестрации, хотя контейнерные платформы и другие планировщики создали иные модели управления. Его вклад проще понимать как архитектурный довод, а не как утверждение о победе одного проекта: общая инфраструктура может масштабироваться, если отделить распределение ресурсов от специализированного планирования приложений.

Тот же довод виден в ранних работах Stoica. Центр хранит достаточно состояния для обеспечения общего контракта, но не представляет каждый поток или нагрузку во всех прикладных подробностях. Интеллект переносится на уровень с большим контекстом. Согласованность системы определяется интерфейсом между уровнями.

Для операторов урок практичен: абстракция не устраняет правила, а определяет, кто их реализует. Предложение ресурсов даёт фреймворку свободу и делает его поведение частью эффективности кластера. Оператору нужно наблюдать не только за центральным распределителем, но и за решениями каждого фреймворка, принимающего его предложения.

Mesos помог утвердить представление о кластере как о платформе для платформ. Spark использовал такую среду, дав приложениям обработки данных ещё одну, более высокоуровневую абстракцию.

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

Абстракция полезна тем, что отделяет общее распределение от планирования конкретных нагрузок. При этом она может представить правила техническими, хотя те выражают власть внутри организации. Квота отражает бюджеты и обязательства. Класс приоритета определяет, какую работу можно прервать. Резервирование защищает будущую ёмкость ценой её текущего использования.

Современные планировщики наследуют ту же проблему, даже если меняется интерфейс. Автоматическое размещение должно показывать цель и исключения, а не выдавать свой выбор за единственно эффективный.

История систем Stoica показывает, что масштабируемость часто достигается переносом решений на границу. Управление требует назвать решение, которое остаётся в центре. Кто-то всё равно определяет, кому достанется предложение.

Spark представил потерянные промежуточные данные как вычисление, которое можно повторить

До Spark системы обработки данных часто записывали промежуточные результаты на диск, создавая надёжную границу между этапами. Такой подход позволял восстанавливаться после сбоев, но делал итерационные алгоритмы и интерактивный анализ дорогими. Устойчивые распределённые наборы данных Spark, или RDD, представляли разделённые коллекции через преобразования и цепочки происхождения. При потере раздела система часто могла заново вычислить его из прежних данных, вместо того чтобы реплицировать каждый промежуточный результат.

Идея соединила отказоустойчивость с моделью программирования. Разработчики могли описывать преобразования распределённой коллекции, пока среда выполнения отслеживала происхождение её разделов. Хранение рабочих данных в памяти ускоряло нагрузки, неоднократно обращавшиеся к одному набору. Система по-прежнему выполняла перераспределение данных, читала хранилища и сталкивалась с перекосами; перемещение данных не стало бесплатным.

Spark возник из работы Matei Zaharia с сообществом Berkeley AMPLab, включая Stoica и многих других участников. Последующее развитие SQL, потоковой обработки, машинного обучения и широкой платформы данных обеспечивало гораздо более крупное открытое сообщество. Назвать Spark изобретением Stoica означало бы стереть вклад людей, которые возглавляли и сопровождали систему.

Его роль важна на институциональном уровне. Лаборатория поддерживала проект, помогала формулировать системные вопросы и связывала исследование с пользователями. Когда в 2013 году появилась компания, Stoica стал одним из семи соучредителей Databricks. Databricks предложила управляемый путь организациям, которым были нужны возможности Spark без самостоятельной сборки всего эксплуатационного стека.

Позднее коммерческая платформа далеко вышла за пределы первоначальной статьи о RDD. В продукт вошли управление данными, архитектура lakehouse, машинное обучение, сервисы ИИ, безопасность и облачная интеграция. Нынешний масштаб компании нельзя использовать как точную меру вклада одной статьи или одного основателя.

Тем не менее Spark обозначил поворот в профессиональном пути Stoica. Абстракция теперь касалась прежде всего не сетевых пакетов или однорангового поиска, а объекта данных, который видит программист, и плана восстановления, который видит среда выполнения. Цепочка происхождения позволила скрыть отказ машины за детерминированной историей преобразований.

Такой перенос создал и новый контроль. Среда выполнения решала вопросы размещения, выполнения и повторного вычисления. Управляемый сервис мог выбирать версии, интеграцию с хранилищем и стоимость. Упрощение программирования усилило зависимость от уровня, который это упрощение обеспечивал.

Alluxio показал, как местоположение данных может взять верх над вычислительной абстракцией

Tachyon, позднее получивший название Alluxio, возник в системной среде Berkeley как распределённый уровень хранения, призванный сделать данные доступными разным вычислительным фреймворкам. Его архитектура использовала память и происхождение данных для ускорения доступа, связывая приложения с нижележащими системами хранения. Проект и компания развивались силами собственных команд и по собственным правилам, но относятся к более широкой истории лабораторного мышления о плоскостях управления.

Планировщик кластера может разместить задачу на свободной машине. Размещение окажется неудачным, если данные находятся в другом месте, а сеть становится узким местом. Абстракция данных способна уменьшить такое трение, предоставляя общее пространство имён и управляя кэшированием или перемещением. Она не делает все системы хранения одинаковыми и не устраняет выбор между согласованностью и долговечностью.

Проект показывает, как одна абстракция выявляет потребность в другой. Mesos распределял вычислительные ресурсы между фреймворками. Spark делал распределённые коллекции программируемыми. Общий уровень данных решал проблему стоимости перемещения рабочих наборов между движками и хранилищами. По мере роста стека росло и число плоскостей управления, способных расходиться в решениях о локальности, вытеснении и восстановлении.

Для операторов это напоминание о том, что использование ресурсов нельзя оптимизировать по одному уровню за раз. Планировщик может показывать высокую загрузку CPU, пока задания ждут данные. Кэш в памяти может повысить скорость, занимая ёмкость, нужную другой нагрузке. Цепочка происхождения восстановит потерянный раздел, но повторное вычисление может прочитать удалённое хранилище и вызвать всплеск сетевого трафика.

Stoica не следует называть единственным создателем Alluxio. Проект важен здесь концептуально: портфель Berkeley неоднократно находил недостающий интерфейс между системами, которые были по отдельности программируемыми, но совместно работали неэффективно. Каждый новый уровень упрощал использование целого и добавлял ещё один сервис с состоянием, чьими отказами и правилами требовалось управлять.

Databricks превратила внедрение открытого кода в коммерческую обязанность по эксплуатации

В исследовательской статье можно описать механизм и оценить его на выбранных нагрузках. Компания должна обслуживать тысячи клиентов, чьи данные, требования безопасности и режимы отказа не похожи на испытательный стенд статьи. Databricks — самый ясный пример такого институционального расширения в профессиональном пути Stoica.

Компанию основала группа, куда входили Ali Ghodsi, Matei Zaharia, Ion Stoica и другие коллеги из Berkeley. В нынешних материалах Databricks называет Stoica соучредителем и исполнительным председателем. Эта должность отличается от роли генерального директора, сопровождающего проекта или автора каждого продукта. Она связывает его с корпоративным управлением и долгосрочной стратегией, но не делает оператором каждого сервиса.

Коммерциализация Spark требовала большего, чем размещение двоичного файла с открытым исходным кодом. Клиентам были нужны развёртывание кластеров, обновления, интеграция идентификации, доступ к данным, диагностика производительности, соответствие требованиям и предсказуемая поддержка. По мере расширения продукта компания создала платформу, чью ценность и привязку уже нельзя было свести к Spark.

Такова обычная экономика инфраструктурной компании с открытым кодом. Общий проект снижает стоимость внедрения и в принципе оставляет пользователям путь выхода. Управляемый сервис получает выручку, упрощая эксплуатацию и добавляя возможности, которые могут плохо переноситься в другую среду. Клиенты повышают продуктивность, принимая зависимость от поставщика.

Исследовательская тема Stoica помогает понять привлекательность модели. Полезная абстракция позволяет клиенту сосредоточиться на приложении, а не на машинах. Коммерческая платформа распространяет это обещание на закупки, безопасность и управление жизненным циклом. Скрытая система становится больше, а последствия решений поставщика — важнее.

Оценки стоимости и раунды финансирования плохо свидетельствуют о техническом вкладе. Они быстро меняются и относятся к компании, а не автоматически к одному основателю. Обоснованный вывод уже: Databricks показывает, что академическая управляющая абстракция может стать центром крупной корпоративной платформы, если организация берёт на себя работу по поддержанию её надёжности.

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

Ray сделал задачи и акторы единицами среды выполнения ИИ

Приложения машинного обучения породили модели выполнения, которые плохо укладывались в пакетный движок обработки данных. Обучение с подкреплением, моделирование, поиск гиперпараметров и обслуживание моделей могли сочетать короткие задачи, долгоживущие компоненты с состоянием и мелкие зависимости. Разработчикам требовался способ выразить такую смесь без создания отдельной распределённой системы для каждого проекта.

Ray предоставил две основные программные идеи. Удалённые функции становились распределёнными задачами. Классы могли становиться акторами — процессами с состоянием, которые получали вызовы методов и сохранялись между операциями. Хранилище объектов и управляющие компоненты работали с данными и планированием под этими интерфейсами. Приложение могло описать граф работы, пока среда выполнения размещала и восстанавливала выполнение по всему кластеру.

Архитектура не устраняла распределённость. Задачи можно было повторять только тогда, когда это допускала семантика приложения. Акторы могли отказывать вместе с состоянием, требовавшим восстановления. Объекты занимали память и передавались по сети. Решения планировщика зависели от ускорителей, групп размещения и локальности данных. Интерфейс Python сделал эти вопросы доступнее, но не лишил их значения.

Статья о Ray на OSDI в 2018 году была результатом работы команды Berkeley RISELab, среди основных авторов которой были Philipp Moritz и Robert Nishihara. Вокруг проекта сформировалось открытое сообщество, а несколько участников вместе со Stoica стали соучредителями Anyscale. Граница авторства важна, поскольку реализация и современная программа развития Ray далеко выходят за рамки работы одного научного руководителя.

Ray показывает очередное изменение местоположения состояния. Приложение называет задачи, акторы и объекты, а не машины. Компоненты глобального управления и локального планирования среды выполнения хранят достаточно сведений для размещения работы и восстановления после отказа. Программист отказывается от прямого управления хостами в обмен на более полезную единицу композиции.

Такой обмен привлекателен для ИИ, поскольку нагрузки быстро меняются, а парки ускорителей дороги. Он также рискован, потому что среда выполнения становится источником операционной истины. Ошибка планировщика, нехватка места в хранилище объектов или несовместимость версий может одновременно затронуть множество приложений. Наблюдаемость и дисциплина обновлений становятся частью модели программирования, даже если API о них не упоминает.

Значение Ray не в том, что он сделал распределённый ИИ простым. Он позволил программировать широкий класс распределённых приложений ИИ через общие понятия, сосредоточив сложную работу в среде выполнения, которую организациям необходимо научиться эксплуатировать.

Anyscale коммерциализировала Ray, не став самим сообществом Ray

Anyscale появилась в 2019 году как коммерческая компания вокруг Ray. Эти отношения напоминают путь от Spark к Databricks, но речь идёт о другой организации и другом рынке. Ray остаётся системой с открытым исходным кодом, у которой есть участники и пользователи вне компании. Anyscale предлагает управляемую эксплуатацию, корпоративную интеграцию и поддержку.

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

Управляемый Ray способен существенно снизить эксплуатационную нагрузку. Развёртывание кластеров, автоматическое масштабирование, управление образами, журналы и восстановление после сбоев требуют инженерной работы, которой многие прикладные команды не хотят владеть. Поставщик может стандартизировать эти задачи и применять опыт разных клиентов.

Сервис также добавляет управляющий уровень между пользователем и базовым облаком. Он определяет упаковку среды выполнения, поддерживаемые функции, обработку телеметрии и обновлений. Клиент может сохранять возможность самостоятельно запускать Ray и одновременно становиться зависимым от управляемых процессов, интеграций и эксплуатационных знаний, накопленных вокруг сервиса.

Роль Stoica как соучредителя связывает исследовательскую систему с этим коммерческим институтом. Она не доказывает его текущую ответственность за каждое продуктовое решение, а точные операционные должности следует сверять с актуальными страницами компании. Устойчивый факт состоит в том, что он помог создать компанию при переходе проекта к промышленному использованию.

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

Это противоречие не уникальный недостаток Ray, а экономическое следствие успешной абстракции. Когда интерфейс привлекает пользователей, организация может построить бизнес на устранении оставшейся под ним эксплуатационной боли. Клиенту приходится решать, какую её часть он готов забыть.

Надоблачные вычисления согласуют работу облаков, которые остаются разными

Sky Computing Lab переносит задачу абстракции за пределы одного кластера или поставщика. Теоретически облачные приложения могут выбирать регионы и компании по цене, доступности ускорителей, местоположению данных или устойчивости. На практике каждое облако предоставляет разные сервисы, средства идентификации, сети, квоты и тарификацию. Перенос работы может повлечь плату за исходящий трафик и долгую передачу данных.

Один из проектов этого направления — SkyPilot. Пользователь описывает задание и требования к ресурсам, после чего система помогает выбрать облако и регион, подготовить ресурсы и выполнить работу. Интерфейс может искать доступные ускорители и сравнивать стоимость на основе имеющихся сведений. Он уменьшает необходимость писать отдельную процедуру развёртывания для каждого поставщика.

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

Межоблачное размещение создаёт и новую границу доверия. Посреднику или инструменту нужны учётные данные для нескольких сред. Он принимает решения о стоимости и доступности, и лежащие в их основе предположения должны быть видимыми. Его отказ способен заблокировать нагрузки в нескольких облаках, которые иначе оставались бы независимыми.

Довод в пользу надоблачных вычислений наиболее убедителен, если считать их уровнем переговоров и переносимости, а не обещанием единого глобального облака. Пользователь с проверенными путями развёртывания может реагировать на дефицит и изменение цен. Если приложение зависит от закрытых сервисов, ограничения сохраняются, даже когда само пакетное задание переносимо.

Нынешняя исследовательская позиция Stoica связывает ранние работы по распределённому поиску и кластерному планированию с этой рыночной структурой. Единицей распределения теперь становится парк ускорителей, принадлежащий отдельным компаниям. Плоскость управления должна учитывать деньги, регулирование и правила организации наряду с CPU и памятью.

Эта задача с необычной ясностью показывает предел абстракции. Программное обеспечение может представить общий запрос, но не отменяет договоры, сетевые расстояния и ограничения энергоснабжения, из-за которых ресурсы различаются. Хорошая плоскость управления помогает пользователям рассуждать об этих различиях, а не скрывает их до появления счёта или сбоя.

vLLM и Chatbot Arena переместили лабораторию ближе к центру инфраструктуры ИИ

Нынешняя страница Stoica на сайте Berkeley перечисляет проекты, включая vLLM, Chatbot Arena, SkyPilot, Ray и Spark. Список показывает широту программы Sky Computing Lab, но не означает, что директор лично проектировал каждую систему.

vLLM решает задачи вывода больших языковых моделей, где память ускорителей и планирование определяют число запросов, которое способна обслужить система. Такие методы, как эффективное управление кэшем ключей и значений и непрерывное формирование пакетов, могут повысить использование ресурсов. У проекта есть собственные ведущие авторы, сопровождающие и сообщество. Его связь со Stoica институциональна: он относится к исследовательской среде под его руководством и более широкой попытке сделать дорогие ресурсы ИИ программируемыми.

Chatbot Arena использует сравнения человеческих предпочтений для оценки ответов моделей. Она создаёт общую доказательную базу на рынке, где поставщики часто публикуют выборочные тесты. Платформа также сталкивается с проблемами выборки, репрезентативности, злоупотреблений и управления. Рейтинг — наблюдение за определённой группой в конкретный период, а не вечная мера интеллекта или безопасности.

Вместе эти проекты показывают расширение вопроса о плоскости управления. Среда выполнения должна размещать работу. Движок вывода — распределять память и объединять запросы. Оценочная платформа — распределять человеческое внимание и защищать достоверность сравнений. Каждый проект через интерфейс превращает дефицитный ресурс в сервис.

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

ИИ повышает ставки, поскольку стоимость ресурсов особенно заметна. Даже небольшое улучшение использования может изменить число нужных оператору ускорителей. Ошибка планирования способна оставить дорогие машины без работы. Тест может перенаправить инвестиции. Теперь абстракции влияют не только на продуктивность разработки, но и на распределение капитала.

Поэтому нынешняя работа Stoica — продолжение прежней программы, а не внезапный поворот к ИИ. Машины изменились, но вопрос остался: какой интерфейс позволяет множеству пользователей совместно использовать дефицитную распределённую систему и какая скрытая власть определяет правила этого совместного использования?

Kubernetes разделил задачу управления, а не заменил Mesos или Ray

Современные обсуждения инфраструктуры часто представляют системы оркестрации соперниками в гонке за единственную победу. Полезнее сравнивать их единицы управления. Kubernetes планирует контейнеры и сервисы и управляет ими через декларативную модель кластера. Mesos предлагал ресурсы фреймворкам. Ray управляет прикладными задачами, акторами и объектами, часто работая на инфраструктуре, уже подготовленной Kubernetes.

Эти системы могут пересекаться, но задают разные вопросы. Контейнерный оркестратор способен обеспечить работу головного узла Ray и парка рабочих узлов. Ray всё равно решает, где выполнять задачи приложения и как размещать акторы с состоянием. Облачный планировщик может выбрать регион ещё до запуска обеих систем. Они образуют иерархию плоскостей управления, а не цепочку однозначных замен.

Иерархия может быть продуктивной: каждый уровень специализируется. Но она же усложняет диагностику, поскольку медленная задача может быть следствием прикладного планирования, ограничений контейнера, нагрузки на узел, перегрузки сети или нехватки облачных ресурсов. Автоматические средства масштабирования на нескольких уровнях могут одновременно отреагировать на один сигнал и вместе превысить необходимый масштаб. При прохождении вниз по стеку запросы ресурсов могут переводиться неточно.

Работы Stoica помогают объяснить устойчивость такой многослойной архитектуры. Универсальному планировщику пришлось бы понимать распределение оборудования, жизненный цикл сервисов, семантику фреймворков и зависимости приложений. Разделение решений позволяет каждой системе развиваться ценой дополнительной координации.

При выборе платформы организации не должны ориентироваться на моду. Важнее определить, какому уровню принадлежит каждое решение и как будут обнаруживаться конфликты. Запуск Ray в Kubernetes может объединить зрелое управление инфраструктурой с прикладной средой выполнения, но требует от команд понимания обеих систем. Эксплуатационная нагрузка перемещается от написания планировщика к управлению границей между планировщиками.

Планирование ИИ одновременно распределяет капитал

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

Среда выполнения вроде Ray или движок вывода вроде vLLM могут повышать использование ресурсов, уплотняя работу, совместно используя состояние и приспосабливаясь к спросу. Межоблачный инструмент способен искать дефицитные ускорители. Такие решения распределяют не только машинное время: они определяют, какой поставщик получит расходы, куда переместятся данные и какие энергетические и сетевые ограничения будут задействованы.

Это придаёт данным о производительности политическое и коммерческое значение. Тест, выгодный одному ускорителю или планировщику, способен перенаправить закупки. Непрозрачный алгоритм размещения может отправить чувствительные данные в непредусмотренный организацией регион. Оптимизатор стоимости способен выбрать машину с меньшей почасовой ценой, но более медленной сетью, увеличив продолжительность задания и общие энергозатраты.

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

Традиция абстракций Stoica хорошо подходит такой среде, поскольку стремится создать узкий интерфейс для неоднородных ресурсов. Риск состоит в том, что интерфейс скроет именно тот дефицит, которым должны управлять руководители. Запроса «ускоритель» недостаточно, когда возможность выполнения определяют объём памяти, соединение, версия ПО и договор поставки.

Следующая долговечная система упростит запрос, сохранив возможность проверить компромиссы. Это сложнее автоматического планирования. Такой подход рассматривает инфраструктурное ПО не только как инструмент разработчика, но и как часть финансового и энергетического управления.

Восстановление после отказов — скрытый контракт, общий для всех систем

Абстракции в профессиональном пути Stoica по-разному реагируют на исчезновение компонента. Chord восстанавливает состояние маршрутизации после ухода узла. Spark может заново создать некоторые потерянные разделы по цепочке происхождения. Ray способен повторять задачи и воссоздавать акторы в заданных приложением условиях. Межоблачный инструмент запуска может попробовать другой регион при отсутствии ресурсов. В каждом случае интерфейс убедителен только при явной модели отказов.

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

Плоскость управления не может вывести всю семантику приложения. Она предоставляет механизмы — повторы, контрольные точки, реплики, правила перезапуска — и просит пользователей указать, какие операции их допускают. Это ещё один пример переноса состояния к участнику с большим контекстом. Среда выполнения знает, какой рабочий узел отказал. Приложение знает, допустимо ли повторить работу.

Операционная зрелость зависит от проверки этого контракта. Командам нужны внесение искусственных отказов, идемпотентные интерфейсы, надёжные контрольные точки и подтверждение того, что время восстановления соответствует бизнес-целям. Тест на исправных машинах мало говорит о системе, главное обещание которой — устойчивость.

Системы, связанные со Stoica, часто хвалят за скорость или масштаб. Их более глубокое общее достижение — превращение частичного отказа в программируемое событие вместо необъяснимого исключения. Сохраняется риск, что удобство API восстановления побудит пользователей предположить больше, чем приложение может безопасно обеспечить.

Абстракции дают течь через производительность, стоимость и безопасность

Успешная инфраструктурная абстракция позволяет разработчикам игнорировать подробности, пока те не становятся узким местом. Пользователи Spark могут работать с датафреймами и SQL, хотя производительность всё равно определяют перекосы, перераспределение и хранение. Пользователи Ray запускают задачи, но задержку по-прежнему определяют перемещение объектов и размещение акторов. Пользователи SkyPilot запрашивают GPU, однако экономичность задания всё равно зависит от квот, исходящего трафика и правил поставщика.

Такая утечка не доказывает ошибочность абстракции. Она показывает, что интерфейс достиг реальной границы. Проблема возникает, когда маркетинг выдаёт абстракцию за доказательство того, что граница больше не имеет значения.

Операционным командам нужна наблюдаемость под интерфейсом. Они должны видеть, какие ресурсы были выделены, почему выбрано конкретное размещение, куда перемещались данные и как повторы повлияли на стоимость. Плоскость управления, оптимизирующая один показатель, может ухудшить другой. Более быстрое планирование задач способно усилить сетевую конкуренцию. Повторное вычисление потерянных данных может сэкономить на репликации, но задержать критическое задание. Межоблачное размещение может снизить почасовую стоимость вычислений и увеличить плату за передачу.

Таким же образом проявляются ограничения управления. Открытый API может скрывать закрытый планировщик. Управляемый сервис способен предоставлять переносимый код, сохраняя у себя телеметрию и опыт, необходимые для его качественной эксплуатации. Фонд может управлять проектом, тогда как большинство сопровождающих финансирует несколько работодателей. В конечном счёте пользователям нужно знать, кто способен менять интерфейс, прекращать поддержку поведения или отдавать приоритет одной нагрузке.

Системы Stoica ценны отчасти потому, что делают эти границы достаточно явными для изучения. Mesos отделил предложения ресурсов от решений фреймворков. Ray отделяет задачи и акторы от базового кластера. Надоблачные вычисления отделяют запрос нагрузки от поставщика, выбранного для её выполнения. Каждое разделение создаёт место, где можно назначить ответственность.

Следующий инженерный шаг редко состоит в устранении этого места. Его нужно измерять, раскрывать правила и предоставлять пользователям путь выхода. Абстракция снижает когнитивную нагрузку. Подотчётность не даёт этому упрощению превратиться в слепую зависимость.

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

Master Mesos, координаторы Spark, управляющие компоненты Ray и межоблачные средства запуска имеют разные архитектуры, но каждый становится частью границы доверия. Им нужны аутентифицированная связь, облачные учётные данные с минимальными правами, защищённые метаданные и восстановление, не принимающее устаревшее или поддельное состояние.

Открытость кода может облегчить проверку. Управляемая эксплуатация способна последовательно применять исправления и мониторинг. Ни то ни другое не гарантирует безопасной конфигурации. Платформа может предоставлять защищённую среду выполнения через служебную учётную запись с чрезмерно широкими правами. Пользователь способен изолировать рабочие узлы, оставив планировщик единым путём между арендаторами.

Модель безопасности должна следовать за абстракцией. Если единицей работы является задача, идентификация и правила должны задаваться на её уровне, а не слепо наследоваться от кластера. Если посредник выбирает среди облаков, его учётные данные не должны давать неограниченные права в каждом из них.

Работы Stoica обычно обсуждают через масштабируемость и программируемость. Но тот же перенос состояния создаёт концентрированные цели для атак. Чем лучше абстракция управляет распределённой системой, тем тщательнее нужно ограничивать её собственные полномочия.

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

Проекты, связанные со Stoica, охватывают несколько моделей управления. Apache Spark следует процессам сообщества Apache Software Foundation. Ray — проект с открытым исходным кодом, собственными сопровождающими и коммерческой экосистемой. После публикации у исследовательского прототипа может не остаться устойчивого института. Databricks и Anyscale — компании, отвечающие перед клиентами, сотрудниками и инвесторами.

Эти модели решают разные задачи. Фонд может сохранять нейтральное управление проектом и дисциплину выпусков, но не обещает соглашения об уровне обслуживания. Компания способна предоставлять поддержку, реагировать на угрозы безопасности и вести продуктовую программу. Она также может менять цены, комплектовать функции и отдавать приоритет клиентам, приносящим выручку. Университет может исследовать рискованные идеи и публиковать методы, но гранты и циклы обучения студентов не гарантируют долгосрочного сопровождения.

Профессиональный путь Stoica проходит через все три модели. Это даёт ему необычное влияние и требует точного описания ролей. Основатель может владеть долей и занимать должность в совете, не сопровождая открытый репозиторий. Профессор может руководить исследованием, реализацию которого ведут студенты. Исполнительный председатель способен влиять на стратегию, не будучи генеральным директором.

Финансовый успех компании — не личный баланс и не доказательство всеобщего превосходства алгоритма. Оценки частных компаний изменчивы. Выручка зависит не только от технических достоинств, но и от продаж, интеграции и рыночных условий. Публичные сведения позволяют установить факт создания компании и нынешнюю должность, не прибегая к предположениям о богатстве.

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

Постоянной формулы нет. Границей приходится управлять отдельно в каждом проекте. Профессиональный путь Stoica показывает, почему маршрут от исследования к компании способен породить долговечную инфраструктуру и почему его нельзя принимать за простую передачу собственности от лаборатории основателю.

Влияние Stoica основано на границах, на которых могли строить другие сообщества

Перечень Chord, Mesos, Spark и Ray рискует превратить профессиональный путь в список известных названий. Полезнее архитектурная связь: каждая система находила место, где сложность распределения можно было представить меньшим контрактом.

Справедливое обслуживание без состояния о потоках в ядре просило край сети нести сведения, которые ядро не могло позволить себе хранить. Chord использовал согласованное размещение и частичное состояние маршрутизации вместо глобального каталога. Mesos предлагал ресурсы, а не предписывал выполнение каждой задачи. Spark записывал происхождение данных вместо репликации каждого промежуточного результата. Ray предоставлял задачи и акторы вместо машин. SkyPilot выражает потребности нагрузки, а затем согласует их с поставщиками.

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

Вклад Stoica меняется от проекта к проекту, а команды заслуживают конкретного признания. Его долговечная роль — исследователь и создатель институтов, помогавший превращать такие границы в проекты, лаборатории и компании. National Academy of Engineering избрала его в 2024 году за более широкий вклад в распределённые и облачные системы; честь принадлежит человеку, а системы остаются коллективными достижениями.

Современная инфраструктура ИИ делает те же вопросы дороже. Ускорители, сети и энергию нельзя бездумно тратить. Плоскость управления, дающая приложениям более простое представление, может улучшить использование ресурсов и ускорить разработку. Она же способна стать местом сосредоточения власти одного поставщика, планировщика или платформы.

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