PaaS-сервисы для разработчиков ПО: движение навстречу друг-другу

Облачные PaaS-сервисы позволяют использовать платформенные компоненты для построения инфраструктуры и избежать при этом лишних затрат, предоставляя сервисы в том объеме и той конфигурации, что необходимы клиенту. Одна из категорий клиентов PaaS-сервисов — разработчики ПО, и в этой статье предлагаю поговорить о том, чем использование платформенных сервисов ценно именно для разработчиков, обсудить принципы разработки Cloud-native приложений (методику 12 факторов), а также я расскажу о том, что мы в Cloud X делаем для повышения эффективности процессов создания ПО. 

1. Одно приложение — один репозиторий в системе контроля версий.

2. Все зависимости должны быть явно объявлены и изолированы.

3. Конфигурацию, которая меняется между средами (пароли, URL баз данных, ключи), следует хранить вне кода.

4. Внешние сервисы (базы данных, очереди сообщений, кэш) рассматриваются как подключаемые ресурсы.

5. Этапы сборки, релиза и выполнения нужно строго разделять.

6. Приложение должно запускаться как один или несколько stateless‑процессов, которые не сохраняют внутреннее состояние между запросами.

7. Привязка портов должна происходить на уровне приложения, а не через внешний веб‑сервер для рантайма.

8. Масштабирование достигается за счёт горизонтального добавления процессов разных типов (веб, воркер, планировщик).

9. Процессы должны быстро запускаться и корректно завершаться по сигналу SIGTERM.

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

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

12. Задачи администрирования (миграции базы данных, скрипты обслуживания) должны выполняться как часть приложения — в той же среде и из той же кодовой базы.

Если вы еще не знакомы с этими принципами детально, их можно подробнее изучить в других публикациях на Хабре, например, в этом переводе. А в контексте управляемых сервисов мне хотелось бы сфокусироваться на факторах №4, №8 и №10.

№4 «Treat backing services as attached resources»

Итак, фактор № 4, который переводят как «Считайте сторонние службы (backing services) подключаемыми ресурсами», является ключевым для работы с управляемыми сервисами. То есть код приложения, если он соответствует методике двенадцати факторов, не должен делать различий между локальными и сторонними сервисами. Для приложения каждый из них является подключаемым ресурсом, доступным по URL‑адресу или по другой паре «расположение/учётные данные», хранящимися в конфигурации. Иными словами, каждое развёртывание приложения двенадцати факторов должно иметь возможность заменить локальную базу данных MySQL на любую управляемую третьей стороной (например, CX Managed Service for MySQL®) без каких‑либо изменений кода приложения; необходимо изменить только идентификатор ресурса в конфигурации.

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

На своей стороне мы делаем всё возможное для того, чтобы облачное приложение могло обращаться к нужным им сервисам единообразно. То есть доступ к экземплярам платформы организован таким образом, чтобы с ними можно было работать аналогично, как и с локальными ресурсами. Например, если вы уже используете OpenSearch для вашего проекта, развёрнутый на вашем «железе», то вы бесшовно можете перейти на использование OpenSearch, развёрнутого в облаке. В веб‑консоли каждого управляемого сервиса есть информация о подключении к экземпляру платформы: IP‑адреса, порты, информация о сертификатах в случае защищённого соединения.

На своей стороне мы делаем всё возможное для того, чтобы облачное приложение могло обращаться к нужным им сервисам единообразно. То есть доступ к экземплярам платформы организован таким образом, чтобы с ними можно было работать аналогично, как и с локальными ресурсами. Например, если вы уже используете OpenSearch для вашего проекта, развёрнутый на вашем «железе», то вы бесшовно можете перейти на использование OpenSearch, развёрнутого в облаке. В веб‑консоли каждого управляемого сервиса есть информация о подключении к экземпляру платформы: IP‑адреса, порты, информация о сертификатах в случае защищённого соединения.

№8 «Concurrency»

Фактор № 8 утверждает: «Масштабируйте приложение с помощью процессов». При этом следует учитывать и выраженное в количестве запущенных процессов масштабирование, и разнообразие типов процессов в зависимости от характера рабочих нагрузок. Де‑факто стандартом области для обеспечения эластичности приложения, то есть его автоматического подстраивания под рост и спад нагрузок, стал Kubernetes® и запуск приложений в его подах. Отдельно отмечу, что масштабирование приложения без масштабирования самого кластера Kubernetes® может не дать желаемого результата, ведь рост ограничен возможностями кластера.

CX Container Platform за счёт возможности автомасштабирования кластера лишён этого ограничения. CX Container Platform не только поддерживает все возможности «ванильного» Kubernetes®, но и является платформой контейнеризации, разработанной с учётом корпоративных требований к безопасности, управлению и мониторингу. А значит, использование CX Container Platform в качестве среды запуска ПО упрощает автоматическое масштабирование под нагрузкой (Horizontal Pod Autoscaler) на основе CPU, памяти или сторонних метрик, вертикальное масштабирование контейнеров без остановки, а также обеспечивает полный контроль над развёртыванием, обновлением и откатом приложений с помощью декларативных манифестов (последнее, к слову, также упрощает для разработчиков следование принципу № 3, определяющему требование строгого разделения конфигурации приложения и его кода).

№10 «Dev/prod parity»

Фактор № 10 переводится как «Паритет окружений разработки и промышленного использования». И это тоже очень важный момент, потому что обычно существуют значительные различия между средой, в которой разработчик вносит и проверяет изменения ПО, и средой, где приложение запущено и к нему имеют доступ конечные пользователи. Разница может быть не только в том, что это физически разные среды — они могут отличаться и по программному составу. И в этом есть логика: иногда разработчики выбирают лёгкие сторонние службы в своём локальном окружении, в то время как в рабочем окружении должны быть использованы более серьёзные и надёжные сторонние сервисы.

Например, нередко разработчики используют SQLite локально и PostgreSQL в рабочем окружении. Часто для кэширования при разработке достаточно оказывается собственной памяти процесса, а «в бою» происходит переход на Redis.

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

Возможность выбрать число серверов в составе экземпляра и их вычислительные характеристики позволяет адаптировать создаваемую платформу под задачи и оптимизировать затраты на использование. Например, вы можете создать небольшую (и недорогую) инсталляцию OpenSearch для DEV‑стенда и мощный экземпляр OpenSearch для продуктивной среды. При этом важно, что механизм работы приложения с системой будет единым, то есть вы сможете достичь желаемого паритета окружений разработки и промышленного использования.

Более того, вы можете создать десятки или даже сотни одинаковых экземпляров платформ для проведения тестирования (например, используя Terraform для автоматизации развёртывания) на 1–2 дня, провести требуемые исследования — и удалить все ресурсы. Если такие сервисы есть у провайдера, для вас раскрывается преимущество облака, когда не нужно иметь мощности «про запас». То есть платить нужно будет только за те дни, когда ваши экземпляры были созданы и работали.

Заключение

Моя команда много работает над тем, чтобы управляемые сервисы Cloud X были максимально полезны разработчикам современного программного обеспечения. Мы заботимся о том, чтобы схема работы была выгодной и удобной, а все предлагаемые услуги соответствовали запросам разработки. Для этого мы своевременно обновляем версии предоставляемых платформ, позволяем использовать удобные инструменты, такие как развёртывание прямо в контейнерах в Kubernetes, и так далее. Всё это способствует сокращению time‑to‑market, то есть ускорению вывода на рынок любых новых функций или даже новых продуктов. Отсутствие необходимости тестировать приложения на разных средах и устранять баги из‑за несоответствия конфигураций, возможность провести любые тесты и выкатить в прод новую разработку «прямо сейчас» упрощают и удешевляют процесс создания облачного ПО.