[Перевод] Wasm vs Docker containers vs Kubernetes vs serverless: битва за первенство
В начале года на YouTube-канале DevOps Toolkit вышло видео с разбором WebAssembly. Автором ролика является Виктор Фарчич (Viktor Farcic) — developer advocate в Upbound, член CNCF Ambassadors, Google Developer Experts, CDF Ambassadors и GitHub Stars. Известен по серии книг «The DevOps Toolkit Series». Увлекается DevOps, контейнерами, Kubernetes, микросервисами, непрерывной интеграцией, доставкой и развёртыванием (CI/CD), а также разработкой на основе тестирования (TDD). Виктор — ведущий YouTube-канала DevOps Toolkit, автор блога TechnologyConversations.com и соведущий канала DevOps Paradox.
Мы перевели видео про WebAssembly в текстовый формат и адаптировали для лучшего понимания. В нём автор разбирает, что такое WebAssembly, стоит ли использовать его в браузерах и кластерах Kubernetes или вообще заменить Kubernetes и прочее. Также благодарим пользователя @nzeemin за помощь в формулировании терминологии WASM.
WebAssembly, или Wasm, претендует на звание очередной крутой технологии. Однако пока неясно, какими именно будут изменения и смогут ли воплотить в жизнь его разработчики и поклонники. Сегодня я хочу присмотреться к Wasm повнимательнее. Я разберу, что такое Wasm и как он появился для решения конкретной задачи, которая впоследствии была расширена. Также я сравню Wasm с Docker и Kubernetes, расскажу об его перспективах с serverless- и edge-устройствами и поделюсь своим мнением о том, стоит ли использовать эту технологию и где.
Браузеры понимают HTML, CSS и JavaScript. Этого обычно достаточно для создания простых веб-страниц с текстом, изображениями, формами и прочим. Но не всегда можно обойтись только этим набором. Представим, что разработчики десктопного приложения Photoshop хотят превратить его в веб-приложение. Стоит ли его переписывать на HTML, CSS и JavaScript? Для этого придётся проделать огромную работу, которая может себя не оправдать. Даже если полностью переписать такое приложение, мы столкнёмся с проблемой поддержки как настольной, так и веб-версии. Наконец, конечный результат может оказаться вовсе не таким, каким ожидался. JavaScript отлично подходит для многого, но это не лучший язык для всего. Могут возникнуть проблемы с производительностью и прочим, которые сложно решить с помощью JavaScript.
Теперь предположим, что готового настольного приложения нет, и мы начинаем новый проект с нуля. Возможно, пользовательский интерфейс будет заточен под браузер. Или может быть Go, Rust или Python подходят для этого проекта больше, чем JavaScript. Или мы хотим разработать игру, которая должна работать не только на PlayStation и Xbox, но и в браузерах. Я веду к тому, что HTML, CSS и JavaScript подходят для многих вещей, но не для всех. Нам нужен способ запускать в браузере приложения, написанные на других языках, и делать это без дополнительной установки или настройки. И такой способ — Wasm.
Что такое Wasm
Wasm позволяет запускать в браузерах приложения, написанные на других языках, без дополнительной установки или настройки конечными пользователями. То есть можно писать приложения на C, C++, Rust, Go, Python и других языках, компилировать их как исполняемые файлы Wasm и запускать в браузерах. В 2019 году эта технология стала официальным веб-стандартом, и с тех пор все основные браузеры поддерживают её. Скорее всего, вы уже пользовались этими приложениями, даже не подозревая об этом.
Спустя время после появления Wasm разработчики стали использовать эту технологию не только для браузеров, но и для серверов, edge-устройств и других мест. Сейчас Wasm-программы можно запускать практически везде.
Но зачем запускать Wasm на серверах и edge-устройствах, если с тем же успехом можно запускать исполняемые файлы Go, jar’ы Java или скрипты Python’а напрямую? Здесь есть несколько причин.
Кросс-платформенность
Исполняемые файлы Wasm можно запускать в любой операционной системе, будь то Windows, Linux или macOS. Также он работает на любой архитектуре, например Intel, ARM или AMD. Если сравнить исполняемые файлы Wasm с файлами Go, то последние можно скомпилировать для любой ОС или архитектуры, но один и тот же файл не будет работать во всех ОС или на всех архитектурах. То есть файл, скомпилированный для Linux или Intel, не получится запустить в Windows или на ARM.
Безопасность
Wasm — это самый безопасный способ запуска приложений. Его модули выполняются в «песочнице», изолированной от рантайма хоста и других модулей Wasm, поэтому вредоносный код не сможет получить доступ к конфиденциальным данным или ресурсам на устройстве пользователя. В свою очередь, проверка типов предотвращает неавторизованный доступ к памяти. Ещё в Wasm есть изоляция от сбоев, ограниченный набор инструкций, контроль, проверка целостности и так далее. В общем, эта технология безопасна и надежна, что делает её потенциально самым безопасным способом запуска приложений.
Размер
Wasm-файл часто меньше, чем файл, который мы получили бы, если бы скомпилировали тот же код нативно. Также wasm-файл сильно меньше образов контейнеров. Далее в тексте мы разберём, за счёт чего это происходит.
Скорость
Wasm-приложения работают быстрее, чем если бы приложение запускалось любым другим способом. При этом они сравнимы по скорости с нативными.
Примечание редакции
Авторы работы Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code имеют другое мнение насчет скорости Wasm. Они пришли к выводу, что Wasm-приложения в среднем на 45% медленнее нативных при запуске в Firefox, и на 55% — при запуске в Chrome.
Архитектура
Архитектура Wasm выглядит следующим образом:
Получается, что изначально у нас идут два слоя, которые независимы от того, как мы запускаем приложения:
Инфраструктура, серверы, виртуальные машины, edge-устройства и прочее на базе архитектуры Intel, AMD или ARM.
Операционные системы Linux, Windows или другие.
Далее идут слои, которые относятся непосредственно к Wasm:
WASI (WebAssembly System Interface), расположенный прямо над ОС. Он предоставляет стандартный набор вызовов API, позволяющих модулям WebAssembly взаимодействовать с базовой ОС. В результате модули получают доступ к файловой системе, могут работать с сетью и так далее.
Wasm runtime — среда для запуска модулей. Она выступает в качестве связующего звена между модулями и средой исполнения хоста и отвечает за загрузку модулей, их работу и предоставление им необходимых API.
Модули Wasm с приложениями, которые мы хотим запустить. Эти модули представляют собой исполняемые файлы, скомпилированные из кода, который написан на поддерживающих Wasm языках: Go, Rust, Python и так далее.
Эта схема похожа на то, как запускаются контейнеры. Поэтому разберём, зачем связываться с Wasm, когда есть Docker и Kubernetes.
Wasm vs Docker и Kubernetes
Проведём сравнение согласно характеристикам выше.
Кросс-платформенность
Образы контейнеров, или Docker-образы, собираются под конкретную архитектуру и ОС. Нужно выбрать, для какой операционной системы — Linux или Windows — будет собираться конкретный образ и на каком процессоре — Intel, AMD или ARM — он будет работать. На самом деле образы без проблем собираются для любой операционной системы и любой архитектуры, а большинство систем управления контейнерами умеют выбирать, какой образ запускать в зависимости от архитектуры и ОС хоста. При этом с Wasm таких сложностей не возникает.
Безопасность
Контейнеры работают поверх ОС и напрямую зависят от операционной системы. Они имеют доступ к ядру ОС и могут делать всё, что позволяет им ОС. В свою очередь, модули Wasm работают поверх WASI и могут обращаться только к тем вызовам API, которые предоставляет WASI. Wasm работает в «песочнице» и изолирован от среды исполнения хоста и других Wasm-модулей. То есть Wasm по умолчанию более безопасен, чем контейнеры.
Размер
Начнём с того, что в контейнеры упаковываются как само приложение, так и его зависимости. Они содержат всё, что нужно приложению. При этом модули Wasm содержат только приложение. В них нет ОС и других зависимостей. Поэтому неправильно сравнивать Wasm с контейнерами, в которые упаковывается куча всего. Его нужно сравнивать с образами контейнеров на основе Scratch, Alpine или Wolfie, которые содержат только необходимый минимум для запуска приложения.
С этой точки зрения Wasm лучше контейнеров, поскольку работать приходится только с модулем Wasm, который представляет собой исполняемый файл приложения.
Скорость
Сторонники Wasm утверждают, что исполняемые файлы Wasm запускаются значительно быстрее, чем контейнеры. И Wasm действительно запускается быстрее, чем контейнеры, но насколько быстрее — это зависит от того, что находится в образах контейнеров. Разница может быть незначительной, а может быть и существенной. Важно то, что модули Wasm работают на скорости, близкой к «родной», а контейнеры могут работать на скорости, близкой к «родной» или значительно медленнее.
Архитектура
Здесь изначально идут слои инфраструктуры и ОС, которые одинаковы для всех. Далее поверх ОС в Docker или другом ПО есть контейнерный движок. Можно считать, что это эквивалент WASI и рантайма Wasm. Потом идут контейнеры, запущенные из образов контейнеров. В отличие от модулей Wasm, эти контейнеры содержат исполняемые файлы, библиотеки, зависимости и всё остальное, что может понадобиться приложению. Как и модули Wasm, образы контейнеров содержат исполняемые файлы, собранные из кода, который написан на Go, Rust, Python или любом другом языке.
Вывод по сравнению
И хотя все эти различия реальны, они вовсе не так велики, как хотелось бы сторонникам Wasm. Конечно, контейнерные образы содержат больше, чем просто двоичный файл. Они созданы для конкретной архитектуры и операционной системы, запускаются и работают медленнее, чем модули Wasm, и, наконец, они менее безопасны. При этом нельзя точно сказать, что Wasm лучше, чем контейнеры, так как всё зависит от ситуации.
Размер
Образы контейнеров могут быть очень маленькими и почти такими же по размеру, как модули Wasm. Хотя один и тот же образ контейнера нельзя использовать в разных операционных системах и архитектурах, можно легко создать образы для всех операционных систем и архитектур. При этом большинство компаний и не собирались запускать одни и те же приложения на разных операционных системах и архитектурах, а если и собирались, то контейнерные движки прекрасно справляются с выбором подходящего образа в зависимости от хоста.
Скорость
Как и в случае с размерами, контейнеры способны работать почти так же быстро, как и модули Wasm.
Безопасность
Что касается безопасности, разница большая, только если сравнивать c Docker или контейнерными движками и забыть про экосистему. Wasm выигрывает у контейнеров по всем этим пунктам, но только если сравнивать с контейнерами по-отдельности. Однако это вовсе не означает, что следует переходить на Wasm. Об этом мы поговорим в конце.
Экосистема
Контейнеры не работают по-отдельности. Над ними есть целая экосистема — экосистема Kubernetes. Скорее всего, вы не запускаете контейнеры в production с помощью Docker. Разве что у вас совсем маленькая команда с парой приложений и без особых требований к масштабированию, безопасности, высокой доступности и так далее.
В ином случае вам понадобится нечто большее — например, управляемый сервис вроде Google Cloud Run, Azure Container Apps или любой другой подобный сервис от крупных и мелких облачных провайдеров. Или это может быть Kubernetes, и тогда возникает вопрос, стоит ли использовать контейнеры в кластерах Kubernetes или лучше перейти на Wasm.
Контейнеры работают в Kubernetes, но их нельзя сравнивать с Wasm. Это все равно что сравнивать яблоки с апельсинами. Kubernetes — это прежде всего экосистема. Можно выбрать managed-услуги на базе K8s или управлять им самостоятельно. В любом случае вы получите доступ к большому набору инструментов и сервисов, которые позволяют выполнять масштабирование, обеспечивают высокую доступность, безопасность и тому подобное.
CNCF (Cloud Native Computing Foundation) — пожалуй, самая крупная экосистема современности, и большинство её проектов связаны с Kubernetes. С их помощью можно строить платформы, которые делают практически всё.
Если и сравнивать Wasm с контейнерами, то только вместе с экосистемами. И здесь вопрос скорее в том, насколько проще с помощью Wasm сделать то, что можно сделать с помощью контейнеров. У Wasm есть своя экосистема, но она ни в какое сравнение не идёт с экосистемой Kubernetes — многое в Wasm сделать попросту нереально: либо совсем нет решений, либо их выбор ограничен, а сами решения незрелые. Но это не означает, что о Wasm следует забыть. Всё зависит от того, что вам нужно.
В итоге если для вас важны безопасность или скорость, то в некоторых случаях лучше использовать Wasm. Хотя даже тут не думаю, что стоит связываться с Wasm. Эта технология более быстра и безопасна, но контейнеры могут быть столь же безопасными, если учесть экосистему, построенную вокруг них. В Kubernetes есть политики, сканирование, admission-контроллеры и куча всего другого. Все эти инструменты способны сделать контейнеры даже более безопасными, чем Wasm-приложения. То есть всё сводится к тому, возникнет ли экосистема вокруг Wasm или сможет ли эта технология влиться в экосистему Kubernetes.
В обоих направлениях были достигнуты определённые успехи. Сегодня, например, модули Wasm можно запускать в кластерах Azure AKS. Пока это лишь бета, не готовая к production. И даже когда она станет готова к production, её возможности будут ограничены тем, что можно сделать с Wasm в Kubernetes. Впрочем, в будущем всё может измениться. Экосистема Wasm может вырасти и развиться до такой степени, что станет жизнеспособной альтернативой контейнерам в Kubernetes или будет бесшовно работать с контейнерами в K8s. Однако этот день пока не настал.
Wasm и serverless
Один из потенциально важных вариантов использования Wasm — serverless-сервисы. Вендоры могут создать Wasm-as-a-service на базе serverless-вычислений. Тогда можно будет запускать модули Wasm и не заботиться об инфраструктуре, операционной системе или чём-либо ещё. Это было бы здорово. Если бы я был вендором, который разрабатывает serverless-сервисы, то определенно рассматривал бы Wasm как потенциальное решение. К слову, такие попытки уже есть, например Fermion Cloud. Компании, создающие такие сервисы, смогут предоставлять более безопасные и быстрые решения по более низким ценам.
При этом с точки зрения пользователя не должно иметь значения, на чём основан сервис — на Wasm или контейнерах. Пользователи предоставляют код, а сервисы его выполняют. Всё остальное — это детали реализации, которые не должны иметь значения для конечного пользователя.
Например, Google Cloud Run основан на проекте Knative, но не работает в Kubernetes. Мы не знаем, на чём он работает, и большинству из нас это неважно, как большинству пользователей безразлично, какой гипервизор использует облачный провайдер для предоставления виртуальных машин. Для приложений, которые работают как managed-сервисы, важны функции и цена, а не то, что находится под капотом. Увы, managed-сервисы на базе Wasm ещё не появились. Возможно, это произойдёт в будущем. А сейчас у нас хватает сервисов, которые так же дёшевы и просты в использовании, как и те, что основаны на Wasm.
Wasm и edge
Edge может оказаться самым перспективным вариантом использования Wasm. Запускать приложения на edge-устройствах непросто, особенно когда речь идёт об ограниченных ресурсах, таких как процессор и память, о рисках безопасности и других потенциальных проблемах. Думаю, в этой области Wasm способен проявить себя.
Впрочем, сегодня перед Wasm, работающим на edge-устройствах, стоит та же проблема, что и перед Wasm, который работает в контейнерах, Kubernetes или serverless. Экосистема ещё не сложилась. Возможности ограничены и незрелы.
Стоит ли использовать Wasm
У Wasm достаточно преимуществ: размер, скорость, безопасность, переносимость и так далее. Но в зависимости от того, где вы используете эту технологию, она может столкнуться с высокой конкуренцией или оказаться недостаточно зрелой, из-за чего будет страдать от отсутствия экосистемы.
Выбор Wasm зависит от того, что вам нужно и где вы планируете его использовать. Для сложного веб-приложения, которое должно работать в браузере, Wasm может стать отличным выбором. Я бы не стал переписывать браузерные приложения на Wasm, но определённо рассмотрел бы эту технологию для новых проектов, которые проще реализовать на каком-нибудь другом языке, а не на JavaScript. Аналогичным образом, если вы, например, захотите перенести в браузер десктопное приложение, Wasm будет лучшим и единственным решением, если вы не планируете переписывать приложение с нуля. Так что Wasm в браузерах, когда приложения сложны или когда нужно портировать десктопные приложения, — это однозначное «да».
Ещё Wasm может подойти для замены контейнеров. Но пока экосистема отсутствует, хотя технология перспективна. Контейнеры, особенно если они работают в Kubernetes, опираются на огромный набор приложений, которые позволяют делать практически всё, что только можно себе представить. Некоторые запускают Wasm в HashiCorp Nomad, и это, на мой взгляд, ошибка. Отчасти потому, что Nomad плохо развивается, а отчасти потому, что это рискованный шаг — лицензия может измениться в любой момент. Nomad не является проектом фонда, который бы защитил тех, кто вкладывает в него свои силы и время.
Кто-то скажет, что Kubernetes слишком сложен, но он сложен только потому, что предлагает больше, чем любая другая платформа. И он вовсе не сложен, если ограничиться его базовыми функциями.
Итоги
Wasm может стать жизнеспособной альтернативой контейнерам. Для этого у него есть два пути:
Создать экосистему, способную бросить вызов Docker и Kubernetes.
Стать частью экосистемы Docker и Kubernetes.
Отдельные проекты уже идут по этим путям. Если они окажутся успешными, я буду первым, кто порекомендует Wasm.
Если Wasm станет жизнеспособной альтернативой контейнерам в K8s и сможет работать с остальными проектами в экосистеме, я с радостью напишу некролог контейнерам. Но пока всё обстоит иначе. Так что Wasm не замена контейнерам. Что касается managed serverless-предложений, как конечный пользователь могу с уверенностью сказать, что мне без разницы, что в основе этих сервисов. Однако я бы присмотрелся к Wasm, если бы был провайдером, который разрабатывает подобные сервисы. Так что пока я не решаюсь сказать «да». Пожалуй, тут больше подходит «возможно». Наконец, остаются edge-устройства. Здесь такие же сомнения, как и с контейнерами, — экосистема ещё не сложилась. Впрочем, перспективы Wasm в edge-экосистеме выражены лучше, так что, как и в случае с serverless, скажу «возможно».
Получается, я поддержал Wasm только в одном случае. Может показаться, что я негативно настроен к этой технологии, но на самом деле всё наоборот. Wasm захватывает воображение. Я возлагаю на него большие надежды и буду пристально следить за компаниями и проектами, которые работают в этой области. Возможно, эту технологию ждёт блестящее будущее и Wasm станет достойной заменой контейнерам в широком наборе сценариев использования, а то и сможет полностью заменить их.
Надеюсь, что так и будет, пока же предлагаю подождать и посмотреть, а также поделиться своим мнением в комментариях.
P. S.
Читайте также:
