По мере того, как браузерная WebAssembly (Wasm) становится все более интересной в качестве серверной технологии, разработчики переходят от «Хм, звучит интересно» к «Давайте посмотрим, что Wasm действительно может делать помимо браузеров, видеоигр и потоковой передачи контента».
В то же время сам Wasm начинает трансформироваться и меняться. Все это позволяет еще раз взглянуть на технологию WebAssembly. Когда вы оцениваете Wasm для новых целей, вам следует помнить о пяти вещах.
Интерфейс
Wasm изначально был разработан для браузера и не имел системного интерфейса для повышения общей безопасности. Авторы оригинального веб-ориентированного Wasm не хотели, чтобы приложения могли запрашивать ресурсы, во многом так же, как Java-апплеты ограничены в браузере.
Но бэкенд-разработчикам, использующим Wasm, нужен интерфейс, чтобы они могли портировать и использовать существующие программы и парадигмы программирования (например, Python, Ruby, веб-серверы и т. д.). Введите расширение системного интерфейса WebAssembly, также известное как WASI, набор API-интерфейсов, подобных POSIX, которые обеспечивают функциональные возможности ОС, такие как файловые системы, сети и криптография. WASI улучшает выполнение и переносимость существующего программного обеспечения, а также новых программ, написанных с использованием общих существующих парадигм (с использованием файлов, портов и т. д.).
Между теми, кто считает, что Wasm должен оставаться чистым, и теми, кто хочет системный интерфейс, похожий на POSIX, возникло много споров. На самом деле, это горячо обсуждаемый вопрос в апстрим-сообществе. Некоторые в сообществе внутренних серверов предложили своего рода компромисс, предполагая, что те, кто хочет использовать Wasm, как это было изначально задумано, должны делать это, но интерфейс может быть добавлен сверху для тех, кто этого хочет. Мне? Я думаю, что WASI необходим для успеха серверной части.
Производительность
В некоторых бенчмарках Wasm демонстрирует впечатляющую производительность. Wasm, без сомнения, быстр и эффективен, но к эталонным показателям следует относиться с долей скептицизма. Например, в недавнем эталонном тестировании Vercel производительность Wasm была превосходной. В разделе электронных цифр, который требует больших вычислительных ресурсов, Wasm оказался намного быстрее, чем Java. Но грязный секрет в том, что использование родного компилятора Rust, написанного на C и работающего на «голом железе», по-прежнему примерно в четыре раза быстрее, чем Wasm. Кроме того, в некоторых других подтестах Vercel Java намного быстрее, чем Wasm.
Конечно, полная производительность приложения будет зависеть от небольшого количества различных тестов, но важно отметить, что Wasm не является беспроигрышным с точки зрения производительности. Это будет особенно верно, если поверх Wasm будет наложено больше элементов, таких как WASI. Кроме того, следите за сборкой мусора и тем, как это может повлиять на производительность.
Безопасность
Как отмечалось ранее, возможности Wasm ограничены по соображениям безопасности системы. Делая его менее строгим, например, добавляя интерфейс WASI, вы увеличиваете поверхность атаки. Вполне вероятно, что чем популярнее становится Wasm, тем больше к нему будет добавлено, что приведет к большему количеству мест для человеческих ошибок или злонамеренных действий. Особую озабоченность вызывает мультиарендность. Является ли Wasm более безопасным, чем контейнеры? Меньше виртуальных машин? Создает ли Wasm безопасную зону между ними? Поддержание этого баланса между функциональностью и безопасностью будет иметь решающее значение в будущем. Разработчики, рассматривающие возможность расширения использования Wasm, должны быть в курсе (и участвовать) в дебатах.
Портативность
Одним из главных преимуществ Wasm является его кроссплатформенная переносимость. Wasm — это нейтральный двоичный формат, который можно запихнуть в контейнер и запустить где угодно. Это ключевой момент в нашем все более многоязычном мире аппаратного и программного обеспечения. Разработчики ненавидят компилировать в несколько разных форматов, потому что каждая дополнительная архитектура (x86, Arm, Z, Power и т. д.) добавляется к вашей тестовой матрице, а взрыв тестовых матриц — очень дорогая проблема. QE является узким местом для многих команд разработчиков.
С Wasm у вас есть возможность писать приложения, один раз компилировать их, один раз тестировать и развертывать на любом количестве аппаратных и программных платформ, охватывающих гибридное облако, от периферии до центра обработки данных и общедоступных облаков. Разработчик на Mac может скомпилировать программу в двоичный файл Wasm, протестировать ее локально, а затем уверенно распространить ее на все машины, на которых она будет развернута.
На всех этих машинах уже будет установлена среда выполнения Wasm, проверенная в бою для этой конкретной платформы, что делает бинарные файлы Wasm чрезвычайно переносимыми, как и Java. И когда вы скомпилируете программу в этот двоичный файл Wasm, вы можете отправить ее в реестр контейнеров, загрузить ее на другой компьютер, на котором установлена среда выполнения Wasm, а затем запустить ее где угодно — будь то хост M1 или M2 Mac или система x86 или что-то еще.
Когда вы смотрите на то, как набирают обороты Arm и RISC, вы понимаете, что наш полиглотский мир станет еще более полиглотным только в ближайшие пять лет, если не раньше. Контейнеры плюс Wasm выглядят как большая кроссплатформенная победа.
Васм и Кубернетес
Еще одна область споров вокруг Wasm заключается в том, следует ли запускать двоичные файлы Wasm изначально, вместе с контейнерами или внутри контейнеров. Прелесть в том, что это действительно не имеет значения, пока мы все принимаем формат OCI Container Image. Независимо от того, запускаете ли вы двоичный файл Wasm изначально в среде выполнения Wasm или если эта среда выполнения Wasm работает в контейнере OCI (помните, что это всего лишь причудливые процессы), вы можете создать один образ, который затем можно развернуть на нескольких архитектурах.
Один образ экономит место на диске и время компиляции и, как отмечалось ранее, предотвращает выход вашей тестовой матрицы из-под контроля. Преимущество запуска Wasm в контейнере заключается в том, что вы получаете глубокую защиту с очень небольшим влиянием на производительность. Преимущество запуска бинарных файлов Wasm рядом с контейнерами еще предстоит изучить, но в любом случае мы сможем сохранить ценность экосистемы Kubernetes. Если вы хотите запланировать контейнеры Wasm, это будет легко, потому что все они будут жить в реестре OCI, и вы сможете вытащить их в Kubernetes (или Podman или Docker) и запустить их.
Заключение
Мы знаем, что Wasm хорошо работает в браузере. Теперь пришло время узнать, как Wasm может работать на стороне сервера. Я думаю, что мы все еще изучаем то, чем может стать Wasm, но, в частности, меня больше всего воодушевляет кроссплатформенный потенциал. Может ли Wasm в сочетании с контейнерами действительно обеспечить максимальную мобильность? Я думаю, что это возможно, но нам, как технологам, придется подождать и посмотреть, и направить его туда, куда нам нужно.
Wasm все еще появляется — и в основном непроверенный — на бэкэнде. Будет важно продолжать следить за прогрессом Wasm и думать о том, какую пользу он может принести каждой из наших организаций. Будет ли производительность действительно такой же хорошей, как у «голого железа»? Сохранит ли Wasm достаточную безопасность даже с новым системным интерфейсом, чтобы обеспечить мультиарендность? Давайте узнаем вместе в ближайшие месяцы и годы!
В Red Hat Скотт Маккарти является старшим главным менеджером по продукту для RHEL Server, возможно, крупнейшего в мире бизнеса программного обеспечения с открытым исходным кодом. Скотт является ветераном стартапов в социальных сетях, опытным специалистом в области электронной коммерции и опытным технологом-исследователем в правительстве, с опытом работы в различных компаниях и организациях, от стартапов из семи человек до технологических компаний с 12 000 сотрудников. Это привело к уникальному взгляду на разработку, поставку и обслуживание программного обеспечения с открытым исходным кодом.
—
New Tech Forum представляет собой площадку для изучения и обсуждения новых корпоративных технологий с беспрецедентной глубиной и широтой. Выбор субъективен и основан на выборе технологий, которые мы считаем важными и представляющими наибольший интерес для читателей InfoWorld. InfoWorld не принимает маркетинговые материалы для публикации и оставляет за собой право редактировать весь предоставленный контент. Присылайте все запросы на newtechforum@infoworld.com.
