Не так давно вышел отчет по архитектурным трендам от InfoQ. Один из трендов — «design for portability» (проектирование с учетом портируемости/переносимости). О нем и поговорим.
Тренду, начало которому положили интерпретируемые языки, в первую очередь – Perl и Java, а затем серьезное ускорение придало появление облачных вычислений, инфраструктура как код, 12 факторов разработки облачных приложений и микросервисный архитектурный стиль.
Переносимость/портируемость означает способность программного обеспечения работать на разных платформах, операционных системах и устройствах без изменений в исходном коде и без потери в функциональности и производительности.
Авторы отчета вкладывают в «design for portability» именно «clean abstraction from the infrastructure», а именно: «whoever is designing and building the system can focus on what brings value, instead of having to worry too much with the platform details that they are going to be running on.» (как не зацепить моднейшее в наши дни слово «плтаформа» 🙂 )
Примеры технологий, которые приводят в InfoQ: server-side WebAssembly, Dapr и cloud-bound applications.
Чтобы понять чуть лучше с чего вдруг portability столько чести, ведь оно всегда было в числе архитектурных атрибутов качества не на последних местах, следует чуть подробнее раскрыть вышеприведенные примеры именно с точки зрения portability.
canadian history thesis topics dapoxetine tablets in pakistan https://assessmentcentertraining.org/exercises/essay-a-cold-day/58/ viagra thailand zoll count of monte cristo essays revenge essay cover page source link block quotes essays enter site college application essay samples questions https://willcoxwinecountry.org/linkedin/how-to-write-an-argument-thesis-statement/47/ kolko stoji viagra https://albionfoundation.org/perpill/buy-authentic-cialis/63/ follow site http://mlat.chapman.edu/annotated/gun-control-free-essay/62/ https://completecompetentcare.com/7736-bien-utiliser-le-viagra/ https://riversideortho.com/o-que-sildenafil-100mg/ https://independentfutures.com/overview/essay-about-different-types-of-business-organization/57/ fear and loathing in las vegas thesis https://oaksofwellington.com/dildoing-my-ass-on-viagra/ what belongs at the beginning of a narrative essay a word counter for essays https://iaace.com/annual/cheap-dissertation-abstract-proofreading-sites-ca/92/ https://elastizell.com/does-monster-drink-affect-sildenafil/ source site compare and contrast essay marijuana vs alcohol https://alexthornton.com/featured/can-you-take-more-than-one-5mg-cialis/16/ enter https://vivianschilling.com/film/catchy-titles-for-college-essays/61/ https://gretchenwegner.com/stories/dissertation-literature-review-writing-service/96/ alice in wonderland essay ideas WebAssembly (Wasm)
Это ни что иное, как стандарт байткода для стековых виртуальных машин. Суть в том, что код, написанный на различных языках вроде Java, Python, … компилируется в байткод WebAssembly и это байткод можно запустить как в браузере, так и на сервере. С точки зрения portability важно то, что WebAssembly обеспечивает одинаковое поведение на разных платформах, что и обеспечивает лучшую переносимость/портируемость приложений.
В общем, то, что в свое время подарила миру Java, но теперь еще и независимо от платформы и языка.
Dapr
А это серверный фреймворк для создания микросервисных приложений (к слову в дикой природе прод применений Dapr своими глазами пока не видел, ничего сказать не могу) предоставляющий набор инструментов и библиотек для решения распространенных задач, таких как управление состоянием, обработка сообщений, обеспечение надежности и безопасности, но самое главное – dapr предоставляет абстракции для распределенных приложений, которые позволяют разработчикам создавать приложения, не зависящие от определенных платформ.
С точки зрения задумки чем-то напомнило идею языка Ballerina. Широкого распространения он не получил, но идею встроить в сам язык высокоуровневые конструкций для интеграции поддерживаю, хоть она и требует более глубокого осмысления.
Cloud-bound applications
Очень странный термин. Он преподносится как следующий шаг после cloud native, то есть переход от проектирования решения для максимально эффективного использования возможностей облачной платформы к уходу от этого с концентрацией на потоках данных и интеграциях (то есть использованием всего и вся от облачного провайдера, – очередей, баз данных, оркестраторов). Странный для меня пункт, но может я его не так понял.
Описание cloudbound тут: https://www.infoq.com/articles/cloud-bound-applications/
Что для меня здесь странно – InfoQ помещают cloud bound как способ повысить portability, но использование в облаках всего того, что перечислено по ссылке – мощный vendor lock при том, что API вендоров мягко говоря не совместим.
В общем, если есть идеи, тут я поднял этот вопрос, можем обсудить.
Почему это важно?
В общем случае «designing for portability» означает, что среди важных для сервиса или решения атрибутов качества присутствует переносимость/портируемость. То есть, когда этот сервис или решение должны работать в разных средах выполнения, таких как облачные провайдеры, локальные серверы или контейнеры. Еще нередко переносимость/портируемость ходит по пятам за масштабируемостью, так как разные платформы могут предоставлять различные возможности по масштабированию, а в ряде случаев может возникнуть потребность в гибридных методах, когда сервис может быть развернут сразу в нескольких облаках.
Бонусом получаем защиту от vendor lock и более простую миграцию с платформу на платформу, если потребуется.
Архитектурные тактики
Для получения тех или иных архитектурных свойств существуют архитектурные тактики. Для портируемости в обозначенном контексте мы можем выделить следующие:
- Использование слоев абстракции между различными компонентами систем, например, – инфраструктура как код, определяющая инфраструктуру с помощью конфигурационных файлов, что упрощает воссоздание инфраструктуры в различных средах выполнения или у облачных провайдеров
- Использование стандартных интерфейсов взаимодействия
- Не использовать специфичные для конкретной платформы возможности
- Контейнеризация, упрощающая перемещение приложения между различными средами выполнения без необходимости учета платформенно-специфичных зависимостей
- Использование кросс-платформенных фреймворков и языков (сюда попадает WebAssembly)
- Разделение на сервисы с интеграцией по API или через очереди сообщений упрощает замену компонентов инфраструктуры и перемещение сервисов между различными средами выполнения
Когда портируемость избыточна?
С трендами есть такая беда, что они могут стать хайпом и начать использоваться где надо и где не надо. Если приложение предназначено только для одной конкретной среды выполнения и вряд ли будет переноситься на другие платформы в будущем, то портируемость здесь явно будет излишней.
С точки зрения обозначенного выше контекста, если вы точно знаете, что ваше приложение будет работать только в одной облачной среде и не планируете переносить его на другие облачные провайдеры, то создание портируемого архитектурного решения так же может быть не оправданным.
Однако, если такой уверенности нет, то заложить в архитектурное решение портируемость может быть весьма полезным, даже если в настоящее время она кажется избыточной. В этом портируемость схожа с интернационализацией и локализацией. Если не заложить вначале и когда-нибудь потребуется, то вот в том «когда-нибудь» реализация может оказаться весьма болезненной.
Как посчитать портируемость?
В зависимости от потребностей, можно посчитать различные численные выражения. В основном они нужны, чтобы поместить их в фитнес-функцию и отслеживать движение в сторону желаемых показателей.
Примеры таких измерений:
- Процент фичей, которые будут работать на различных платформах без каких-либо модификаций (10% означает, что придется в том или ином виде придется внести изменения в 90% функциональности, даже если это будет рефакторинг)
- Процент поддерживаемых платформ. Опять же, по определению, берем множество платформ и считаем на какой части из всего множества приложение работает на 100% без модификаций
- Процент согласованности поставки, конкретно – соответствия шагов поставки на разные платформы, включая используемые инструменты, настройки, зависимости, процесс тестирования и так далее.
Выводы
Портируемость безусловно важный атрибут качества, особенно в нынешней крайне гетерогенной среде. Одна прогнозировать, что какой-то атрибут качества войдет в тренд, это значит начать уделять ему внимание не потому что-то он нужен или не нужен, а потому что еще и тренд образовался, что порой ассоциируется с некоторыми лобби: «аккуратно закладываем тренд на портируемость, может еще на что-то, всегда рядом упоминая Dapr и тем самым постоянно подогревая интерес к нему», – примерно так выглядит этот маркетинговый ход 🙂
Поживем — увидим.
