Когда я думаю о Васме – а я начинаю часто думать о Васме – я представляю его как те волшебные капсулы для выращивания, которые были у вас в детстве: просто налейте воду на одну из капсул, и она увеличится во много раз больше своего размера, в разнообразие форм и цветов.
Аналогичным образом, Wasm — или WebAssembly, как его формально называют — начинался с «маленького» формата двоичных инструкций для виртуальной машины на основе стека, изначально предназначенной для браузера. Это по-прежнему так, но по мере того, как разработчики «льют на него воду», я ожидаю, что мы будем наблюдать, как он растет и меняет форму самыми разными способами — не в последнюю очередь как способ один раз написать приложения и развернуть их на растущем количестве оборудования. и программные платформы, которые управляют (иногда буквально) нашей жизнью.
Аппаратная часть, условно говоря, переживает особенно большой бум. Не так давно было время, когда Intel относилась к аппаратным процессорам так же, как Kleenex к тканям лица. Сегодня мир аппаратного обеспечения многоязычен. Arm, RISC-V, Apple M1/M2, AWS Graviton, Ampere, Fujitsu и другие присоединились к процессорам Intel и AMD в качестве целей разработки для множества новых вариантов использования: от лампочек до автомобилей, корпоративных приложений и особенно веб-серверов. которые склеивают все воедино в современном мире. Все эти аппаратные архитектуры, не говоря уже о устаревшем оборудовании, которое все еще скрывается, должны будут сосуществовать бок о бок в течение многих лет.
Есть также много разных языков. Java и .NET, конечно, позволили разработчикам написать приложение один раз и запускать его где угодно, но с некоторыми накладными расходами и ограничениями. При использовании Java и .NET существует неявное понимание того, что вся ваша экосистема программного обеспечения будет написана на Java и .NET. Хотя .NET поддерживает несколько разных языков, он никогда по-настоящему не стал многоязычным интерпретатором по умолчанию для какого-либо языка. В Java и .NET всегда существовало четкое разделение между ОС, которая управляла многоязычными процессами (Python, Ruby, Perl, C, C++ и т. д.), и виртуальной машиной, которая управляла написанными и развернутыми процессами. в пределах экосистема программного обеспечения (Java, .NET).
Были попытки расширить виртуальную машину Java (JVM) с помощью JRuby, Jython и других, но они так и не прижились. Операционная система всегда служила этой цели посредством стандартизированных библиотек C, которые используются почти во всех языках, но никогда не было легко совместно использовать библиотеки между языками, например Python и Ruby. Возможно, всегда был нужен какой-то универсальный двоичный формат!?!?
Где подходит Васм
Консорциум Всемирной паутины (W3C) впервые анонсировал Wasm, то есть WebAssembly, еще в 2015 году и опубликовал его в 2018 году. Изначально разработанный исключительно для использования в браузере, скрытый Wasm вызывает интерес как потенциальное средство преодоления барьеров во всем мире. различные аппаратные и программные среды. Первоначальное видение Wasm представляло собой инструмент безопасности, который позволял разработчикам безопасно использовать в браузере скомпилированные языки, такие как C, C++ или Rust, и в то же время не позволял коду завладеть компьютером пользователя.
С тех пор это видение превратилось во что-то похожее на Java или .NET, но для каждого языка, что позволяет разработчикам компилировать любой язык в двоичный файл, который может работать на любой платформе через интерпретаторы Wasm, будь то в браузере, на рабочем столе или напрямую. на сервере, на периферии или даже в качестве платформы плагинов в других частях программного обеспечения. Целью стала настоящая мобильность в широком спектре вариантов использования. Хотя его еще нет.
Существуют определенные варианты использования, которые Wasm идеально подходит для сегодняшнего дня, включая браузерные приложения и плагины. Но Wasm начинает расширяться, чтобы иметь возможность компилировать такие вещи, как Python, в двоичный файл Wasm, который затем можно запускать в интерпретаторе Wasm. Теперь вы можете запускать мои программы на Python, поскольку интерпретатор Python скомпилирован в этот формат, и теперь этот интерпретатор Python может работать на любом оборудовании, имеющем интерпретатор Wasm. Более того, мы наблюдаем развитие Wasm таким образом, что та же самая программа Python может использовать библиотеки других языков, которые работают в интерпретаторе Wasm. Мы наблюдаем стремление к расширению мобильности одновременно как со стороны аппаратного, так и со стороны программного обеспечения.
На данный момент самым популярным языком, используемым в Wasm, является Rust. Люди компилируют Rust в эти двоичные файлы Wasm и используют их повсюду. Мы видим это в вышеупомянутых плагинах, а также в очень специфических случаях использования, таких как Envoy, популярный сетевой прокси, и Krustlet, программа, разработанная для замены Kubernetes Kubelet. Вместо контейнеров OCI Krustlet будет просто запускать двоичные файлы Wasm.
Помимо Rust, мы начинаем видеть людей, использующих C, C++, Ruby и Python, так что со стороны программного обеспечения также формируется поддержка полиглотов. Кроме того, мы также видим, что такие инструменты, как Podman и CRI-O, развиваются, чтобы использовать контейнеры OCI и Wasm вместе, вместо замены OCI. Обычно в контейнерах OCI двоичные файлы в образе контейнера запускаются непосредственно в ядре базового хоста контейнера. Это имеет ограничение: двоичный файл в контейнере должен быть скомпилирован для аппаратной архитектуры.
Но crun, среда выполнения контейнера, обычно используемая Podman и CRI-O, включает в себя экспериментальную функцию, которая обнаруживает двоичные файлы Wasm. внутри образ контейнера и запускает эти двоичные файлы на интерпретаторе Wasm, установленном на хосте. Совместное использование контейнеров Wasm и OCI также может обеспечить дополнительный уровень безопасности, а также возможность запуска одних и тех же контейнеров на любом количестве базовых аппаратных архитектур и версий операционной системы.
Блокаторы Васм
Хотя у Wasm есть большой потенциал, все еще есть некоторые блокировщики.
Во-первых, необходимо расширить языковую поддержку, но, как уже отмечалось, по мере нашего разговора добавляются API-интерфейсы для все большего и большего числа случаев использования (сетей катастрофически не хватает) в рамках большего количества языков.
Возможно, более серьезная проблема заключается в том, что Wasm, очень специфичная архитектура набора команд, в настоящее время не совместима с POSIX, поэтому вы не можете использовать ее для выполнения многих стандартных действий, которые ожидают разработчики (подумайте о таких вещах, как открытие файла или сетевая розетка). Ребята из Wasm добавляют сверху дополнительный API под названием WASI, который позволит Wasm выполнять некоторые из этих общих вычислительных операций, но до тех пор, пока это не произойдет, использование Wasm будет ограничено.
С учетом вышесказанного, это похоже на то, что произошло с Node.js и JavaScript, когда мы перенесли их использование в браузере на серверную часть. В течение следующих пяти лет мы могли бы наблюдать такую же эволюцию с Wasm и WASI.
Будущее Васма
Сейчас ведется много дискуссий вокруг потенциала Wasm, не говоря уже о миллионах долларов венчурного капитала, инвестируемых в компании, работающие над развитием этой технологии. Я считаю, что деньги потрачены не зря, потому что я могу представить себе время в самом ближайшем будущем, когда разработчик, работающий на рабочей станции или ноутбуке Mac, Windows или RHEL, сможет скомпилировать приложение для периферии, Интернета вещей, облака или автомобиля. платформу, и они сделают это с помощью Wasm. Сегодня этот рабочий процесс требует кросс-компиляции или эмуляции, что неудобно и/или снижает производительность.
Разработчик не хочет кросс-компилировать код; они просто хотят скомпилировать его, запустить локально, протестировать, переместить куда угодно, и чтобы он просто работал. Теоретически Васм может это сделать.
Wasm также поможет сделать контейнеры еще более портативными и мощными.
Используя crun, мой коллега Джузеппе Скривано провел два доказательства концепции (PoC), показав, как двоичный файл Wasm можно запустить из контейнера Docker/OCI, используя Podman/crun в качестве автономного контейнера в Linux или используя CRI-O/crun. в Кубернетесе. В любом случае среда выполнения контейнера была достаточно умной, чтобы обнаружить двоичный файл Wasm и запустить его с помощью интерпретатора Wasm. (На момент написания этой статьи crun в настоящее время поддерживает WasmEdge, Wasmer и Wasmtime.)
PoC Джузеппе демонстрирует, что Wasm может позволить вам запускать один и тот же образ контейнера на любом оборудовании, которое вы хотите, или, по крайней мере, везде, где есть интерпретатор Wasm. Это удобно избавит от необходимости компилировать и создавать разные образы контейнеров, скажем, для RISC-V, Arm или x86. Сегодня мы вынуждены это сделать: если нам нужно, чтобы двоичный файл работал на трех разных аппаратных архитектурах, нам придется скомпилировать и собрать его три раза, создать три разных образа контейнера и отправить их все на сервер реестра. PoC Джузеппе показывает, что с помощью Wasm разработчик может создать только один раз и развернуть где угодно (одна из наших мечтаний о контейнерах).
Если бы мы могли это сделать, это была бы буквально история о гибридных облаках. Представьте себе кластер Kubernetes с некоторыми RISC-V, некоторыми Arm, некоторыми Intel, и все они работают на множестве разных узлов. Я мог бы отключить приложение и запустить его там, где оно работает лучше, быстрее, дешевле или ближе всего к потребителю…
Потенциал Wasm довольно впечатляющий, и я думаю, что мы сможем его достичь, особенно если ребята из Wasm смогут решить проблемы с языком и особенно с POSIX. POSIX существует в операционных системах уже более 20 лет, и нельзя игнорировать двадцатилетнюю историю устаревшего программного обеспечения.
Сообщество WebAssembly хорошо осведомлено о траектории Wasm, которую люди видят и желают. Они работают над API, которые уберут некоторые блокировщики и расширят Wasm таким образом, чтобы сделать его более полезным для большего числа случаев использования. Благодаря всему этому Wasm станет более универсальной архитектурой, которую организации смогут использовать для поддержки и оптимизации модели гибридного облака.
В Red Hat Скотт Маккарти является старшим главным менеджером по продуктам RHEL Server, возможно, крупнейшего в мире подразделения программного обеспечения с открытым исходным кодом. Области фокуса включают облако, контейнеры, расширение рабочих нагрузок и автоматизацию. Тесно работая с клиентами, партнерами, инженерными командами, отделами продаж, маркетинга, другими продуктовыми командами и даже с сообществом, Скотт объединяет личный опыт с отзывами клиентов и партнеров, чтобы улучшить и адаптировать стратегические возможности Red Hat Enterprise Linux.
Скотт — ветеран стартапов в области социальных сетей, ветеран электронной коммерции и опытный государственный исследовательский технолог с опытом работы в различных компаниях и организациях: от стартапов из семи человек до технологических компаний со штатом в 12 000 человек. Кульминацией этого стал уникальный взгляд на разработку, поставку и обслуживание программного обеспечения с открытым исходным кодом.
—
Форум новых технологий предоставляет место для изучения и обсуждения новых корпоративных технологий с беспрецедентной глубиной и широтой. Выбор является субъективным и основан на выборе технологий, которые мы считаем важными и представляющими наибольший интерес для читателей InfoWorld. InfoWorld не принимает маркетинговую информацию для публикации и оставляет за собой право редактировать весь предоставленный контент. Все вопросы отправляйте по адресу newtechforum@infoworld.com.
