Три проблемы разработчиков в области периферийных вычислений

Можно ли пользоваться всеми преимуществами Edge без существенного изменения методов разработки и развертывания приложений? Этот вопрос на портале TechBeacon обсуждает Уолт Ноффсингер, вице-президент Section по продуктам.

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

Типичные облачные развертывания основаны на простом расчете — определении, какое отдельное облако обеспечит наилучшую производительность для максимального числа пользователей, а затем подключении базы данных/хранилища и автоматизации сборки и развертывания с помощью CI/CD.

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

Стоит углубиться в эту тему с точки зрения разработчика. Вопрос относительно прост: можно ли пользоваться всеми преимуществами Edge без существенного изменения методов разработки и развертывания приложений?

Проблема разработки в данном случае может быть сведена к трем аспектам: переносимость кода, управление жизненным циклом приложений и привычные инструменты применительно к периферии.

Переносимость кода

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

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

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

Важно понимать, что, хотя выбор между частным облаком, публичным облаком и периферией может показаться архитектурным, они не являются взаимоисключающими. Централизованные вычисления могут быть зарезервированы, например, для хранения данных или интенсивных нагрузок, в то время как периферийные вычисления применяются для использования данных или повышения производительности в источнике. С точки зрения разработчика, это означает, что среда выполнения приложений должна быть переносимой на континууме «периферия-облако».

Достижение переносимости с помощью контейнеров

Как этого добиться? Контейнеризация — это ключ к обеспечению переносимости, но для ее достижения все же требуется тщательное планирование и принятие решений. В конце концов, переносимость и совместимость — это не одно и то же; переносимость — это бизнес-проблема, а совместимость — техническая. Рассмотрим следующие широко используемые среды выполнения:

• Node.js, используется многими крупными и малыми компаниями для приложений, выполняющих код JavaScript вне веб-браузера;
• Java Runtime Environment, необходимое условие для запуска Java-программ;
• .NET Framework, необходима для приложений Windows .NET;
• Cygwin, среда выполнения для приложений Linux, которая позволяет запускать их на Windows, macOS и других ОС.

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

Более того, вопросы переносимости, совместимости и интероперабельности относятся не только к частному и публичному облакам. Они также являются важными соображениями на всем edge-континууме, поскольку разработчики адаптируют глобальные, объединенные сети с решениями различных поставщиков для повышения доступности приложений и эффективности работы, избегая при этом привязки к поставщику.

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

Управление жизненным циклом приложений

В дополнение к переносимости кода, еще одна важная edge-проблема для разработчиков заключается в том, чтобы легко управлять системами и процессами жизненного цикла приложений. В жизненном цикле DevOps разработчики обычно сосредоточены на «планировании-кодировании-сборке-тестировании», а это только часть цикла.

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

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

Многие команды и организации обращаются к решениям по управлению, таким как GitOps и рабочие процессы CI/CD для своих контейнерных сред. Когда речь идет о распределенных периферийных развертываниях, эти подходы обычно необходимы, чтобы избежать увеличения накладных расходов команды.

Знакомый инструментарий

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

GitOps, способ реализации CD для нативных облачных приложений, помогает в этом. Он фокусируется на ориентированном на разработчика опыте эксплуатации инфраструктуры, использовании инструментов, с которыми разработчики уже знакомы, включая инструменты Git и CD. Эти наборы инструментов GitOps/CI/CD обеспечивают критически важную поддержку в условиях, когда разработчики переносят все больше сервисов на периферию, улучшая управление приложениями, интеграцию и согласованность развертывания.

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

Единообразие — это ключ

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

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

Например, новые решения должны позволять разработчикам использовать переносимость кода и простые, привычные процессы и инструменты управления жизненным циклом на распределенной периферии, предлагая при этом рабочие процессы на базе GitOps, нативные инструменты Kubernetes, интеграцию конвейеров CI/CD, RESTful API, автоматическую интеграцию SSL/TLS и полный набор средств наблюдения за периферией.

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