Обещание WASM


WASM — это будущее

Скажу прямо: WASM — это будущее современных вычислений.

Возможно, не в его нынешней форме. Может быть (скорее всего) под другим названием. Но он определенно показывает путь к тому, как будут создаваться, поставляться и интегрироваться программные приложения завтрашнего дня.

Напиши один раз, запускай где угодно!

Серьезно, обещание Java было чудесным:

«Напиши один раз, запусти где угодно!».

Но не до конца выполнила 🙁

Затем мы приняли контейнеры Linux: «Наконец-то — пиши один раз, запускай где угодно!».
Вроде как… если это Linux, если вы используете stdlib, если вы берете с собой все свои зависимости, если вы понимаете тонкости контейнерной оркестровки…

Не поймите меня неправильно — контейнеры по-прежнему великолепны. Они представляют собой идеальные строительные блоки для создания и запуска эффективных распределенных систем.
Но у контейнеров есть и своя доля проблем:

Почему контейнеров Linux недостаточно.

Контейнеры плохи в совместном использовании

Контейнерные архитектуры предполагают полную автономность и инкапсуляцию зависимостей или — как говорят — «архитектуру «ничего не делить». (Правда, ядро все еще используется совместно контейнерами на одном хосте, но кто заглядывает так глубоко в стек?)
Проблема в том, что ценность информационных систем заключается в обмене информацией. А обмен информацией по сети неэффективен, сопряжен с ошибками и громоздок.

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

Контейнеры раздуты.

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

Как результат — в Интернете полно руководств о том, как сделать ваши образы меньше. Есть контейнеры без дистрибутивов. Есть даже умное (кто-то сказал ИИ?) программное обеспечение для анализа ваших контейнеров и уменьшения их размера.
Все это выглядит немного перевернутым с ног на голову. Технология построена на упаковке множества лишних вещей, и теперь нам нужно еще больше технологий, чтобы убрать этот беспорядок. Почему бы не сделать все правильно с самого начала, упаковывая только то, что нам нужно?

Контейнеры застряли в парадигме Cloud Native

Контейнеры родились в облаке, и поэтому их использование имеет смысл только на серверах. Да, мы пробовали использовать их на границе и в IoT с разным уровнем успеха, но это всегда кажется излишеством. И, конечно, контейнерам нет места на мобильных устройствах или в браузере (или в блокчейне, если уж на то пошло).

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

Обещание универсального двоичного кода

WebAssembly был изобретен для повышения производительности Javascript в браузере.
Я не буду углубляться в то, зачем нужна WebAssembly и как она работает. На эту тему было написано довольно много замечательных постов. Я приведу ссылки на некоторые из них в конце этой статьи.

Я просто хочу сосредоточиться на том, почему WASM звучит так захватывающе.
Дело в том, что идея универсальной цели компиляции никогда не теряла своей привлекательности. Да, похоже, что индустрия на какое-то время разочаровалась, но теперь мы вновь обрели надежду. Умные люди быстро поняли, что эффективность и производительность WASM может сослужить нам хорошую службу на множестве платформ (т.е. не только в браузерах). На сегодняшний день — различные усилия талантливых инженеров по всему миру направлены на то, чтобы сделать модули WASM пригодными для использования:

  • в качестве бессерверных функций (https://github.com/deislabs/wagi)

  • на границе (будь то CDN или граничные устройства) (https://blog.cloudflare.com/webassembly-on-cloudflare-workers/, https://wasmedge.org/)

  • в автомобильных вычислениях

  • в качестве смарт-контрактов (https://www.parity.io/blog/wasm-smart-contract-development/)

  • на серверах (внутри WASM-совместимых исполняющих систем) — https://wasmer.io/

  • в сетевых прокси-серверах (https://antweiss.com/blog/extending-envoy-with-wasm-and-rust/)

  • по расписанию в Kubernetes (https://krustlet.dev/)
    (доказывая, что оркестровка контейнеров быстро становится слишком маленькой и неохватной нишей — оркестровка будущего должна будет поддерживать гораздо большее разнообразие)

  • в машинном обучении (https://github.com/WebAssembly/wasi-nn)

  • еще…

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

Обещание универсальной расширяемости

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

Сделать свой инструмент или платформу, будь то с открытым или закрытым исходным кодом, легко расширяемой — все еще сложная задача. Должны ли мы сказать нашим участникам, чтобы они писали на Lua, Groovy или Python? Должны ли они принимать/возвращать JSON или protobuf? Должны ли мы изобрести свой собственный DSL? Должны ли они упаковывать расширения как образы OCI?

WASM несет в себе огромный потенциал единой истории расширяемости для всех платформ и языков.

  • Нужно передать некоторые метрики в Prometheus? Больше не нужно изучать (или расширять) существующие клиентские библиотеки для конкретного языка — используйте универсальный модуль WASM.

  • Необходимо структурированное протоколирование? — используйте существующий модуль WASM.

  • Нужно реализовать новый протокол на вашем языке? — может быть, кто-то уже создал для этого модуль WASM?

Продолжение следует…

WASM еще не достиг своей цели. Сейчас это довольно горячая неразбериха из взаимно несовместимых режимов выполнения, форматов пакетов и загадочных процессов сборки. Для начала — мы все ждем, когда WebAssembly Interface Types обретет форму.

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

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

Вот как я вижу будущее WASM. Но красота будущего в том, что у каждого оно может быть свое — а какое у вас?

=======================

P.S Как и обещал, несколько ссылок на отличные обзорные материалы по WebAssembly/WASM/WASI.

Высокоуровневые цели на официальном сайте

WASM в документации Mozilla

Rust и WASM

Как думать о WASM

Системный интерфейс Web Assembly от Линна Кларка

Web Assembly и неуловимый универсальный двоичный файл Алон Закай

Оцените статью
Procodings.ru
Добавить комментарий