Об исходном определении PaaS
15 апреля 2022 г.Платформа как услуга (PaaS) — это неправильно понятый, но все еще чрезмерно используемый облачный термин. Не помогает и то, что разные поставщики технологий/облаков определяют его по-разному. Существуют также мини-варианты PaaS, такие как PaaS приложений (услуги управляемых вычислений для размещения приложений), PaaS интеграции (для предоставления услуг интеграции между разрозненными приложениями и системами), PaaS связи (для предоставления услуг связи, таких как голос, SMS, электронная почта и т. д.) , и многие другие. Многие основные службы, такие как управляемые базы данных (DBaaS), также иногда называют разновидностью PaaS. Фактически каждый сервис, API и т. д., которые сокращают нагрузку на управление инфраструктурой или обеспечивают простую в использовании абстракцию от повторяющихся задач, теперь называются PaaS.
Однако в этой статье я хочу сосредоточиться на первоначальном определении PaaS — управляемой вычислительной среде, которая просто берет код (или созданные исполняемые файлы) от разработчиков и запускает его для них, устраняя необходимость в управлении виртуальными машинами. Это иногда называют приложением PaaS (aPaaS), и это область, которая прошла через несколько интересных циклов. Первоначально рекламируемое как «именно то, чем должно быть облако», оно утратило популярность, поскольку инфраструктура как услуга (IaaS) по-прежнему представляла собой самое простое и надежное средство как для подъемно-сдвижных рабочих нагрузок, так и для новых Приложения. Многие говорили, что PaaS имеет слишком строгие ограничения или требует слишком больших изменений в архитектуре приложений или рабочих процессах развертывания, не обеспечивает достаточного контроля над базовыми ресурсами и т. д.
Многие из нас могли видеть диаграммы, подобные этой, говорящие о вычислительном континууме с контролем на одном конце и удобством на другом. Вот как выглядела исходная версия:
Однако в последние годы в повествовании гораздо больше, чем PaaS, преобладают два новых, более горячих направления вычислений — Kubernetes и Serverless. Оба находятся по обе стороны от PaaS в вычислительном континууме. Kubernetes упрощает управление инфраструктурой. Бессерверные вычисления имеют несколько определений в зависимости от того, с каким поставщиком облачных услуг вы общаетесь, но наиболее распространенным является управляемое событиями, с оплатой по факту использования, автоматическое масштабирование вычислений, предоставляемое через модель «Функции как услуга» (FaaS). В результате обновленная версия континуума облачных вычислений выглядит следующим образом:
Некоторое время назад я даже красноречиво рассказывал о достоинствах безсерверных технологий здесь.
Однако реальность такова, что большинство этих технологий (Kubernetes, PaaS, Serverless) бывают разных видов и, в зависимости от вида, попадают в разные места континуума. Это означает, что континуум облачных вычислений теперь содержит несколько осей. Для простоты рассмотрим только два:
- Независимо от того, решает ли вычислительное решение инфраструктуру или рабочие процессы приложений.
- Должен ли базовый механизм управляться пользователем или облачным провайдером
Давайте также сделаем третье упрощающее (хотя и потенциально спорное) предположение, что такие вещи, как Serverless/FaaS, являются лишь подмножеством PaaS, по крайней мере, на основе исходного определения PaaS (сосредоточьтесь на приложениях, а не на инфраструктуре).
Имея это в виду, континуум начинает выглядеть так:
Давайте посмотрим на все эти остановки на континууме:
(1) IaaS: это просто. Виртуальные машины, которыми вам нужно управлять самостоятельно. Устанавливайте среды выполнения приложений, выполняйте исправления и т. д. самостоятельно. Они популярны даже среди разработчиков. О некоторых причинах я рассказываю здесь.
Примеры IaaS:
(2) VM Marketplace. В настоящее время большинство облачных провайдеров предлагают образы виртуальных машин, предварительно упакованные со стеками приложений, чтобы разработчики могли просто начать писать или развертывать код сразу после запуска экземпляров этих образов виртуальных машин. Я предпочитаю называть их «начальными шаблонами» для IaaS, а не PaaS. Они решают некоторые рабочие процессы приложений, но по-прежнему оставляют слишком много работы по обслуживанию инфраструктуры для разработчиков. Примеры:
(3) Kubernetes с собственным хостингом: Kubernetes позволяет вам лучше управлять своей инфраструктурой, но в нем отсутствует концепция «приложения». Управлять им самостоятельно может быть сложно, но многие специалисты предпочитают это делать. Призыв к этому может быть понятен, особенно для тех, кто в первую очередь выбирает инфраструктурно-ориентированную технологию, такую как Kubernetes.
(4) Управляемый Kubernetes: почти у каждого серьезного поставщика облачных услуг в наши дни есть управляемое предложение Kubernetes, которое выполняет определенный набор функций управления Kubernetes. Хотя большинство этих предложений не помогают с концепциями, ориентированными на приложения, они снижают нагрузку на работу самого Kubernetes. Примеры:
Одно распространенное заблуждение заключается в том, что контейнеры и Kubernetes идут рука об руку. Это не совсем правда. Хотя Kubernetes отлично подходит для контейнерных рабочих нагрузок, контейнеры полезны и в других контекстах. Я рассказываю об этой теме в этой статье.
(5) PaaS с собственным хостингом: это область, в которой я никогда не понимал необходимости. На мой взгляд, тот, кто ищет решение PaaS, уже принял решение сосредоточиться на разработке приложений, а не на управлении инфраструктурой. Если да, то зачем заниматься самостоятельным размещением решения PaaS, если вы по-прежнему отвечаете за базовую инфраструктуру? В любом случае, есть решения, которые сделают это за вас, также называемые DIY PaaS. Идея состоит в том, что «команда разработчиков платформы» выполняет некоторую первоначальную настройку (и, возможно, небольшое текущее обслуживание) для этой PaaS в своей собственной инфраструктуре (виртуальные машины или кластеры), а затем опыт, который все остальные (люди, создающие приложения в той же организация) получает от PaaS. Они просто могут сосредоточиться на своих приложениях. Примеры:
(6) Управляемая PaaS: это настоящая PaaS, которая действительно воплощает смысл «aaS». На мой взгляд, «как услуга» означает то, что я могу ожидать и потреблять как сущность, не беспокоясь о том, как эта сущность была построена или доставлена мне. Это то, что начинают предоставлять полностью управляемые предложения PaaS — свобода от управления инфраструктурой. Примеры:
(7) Управляемая PaaS в Kubernetes: подождите. Какая? Разве я не говорил ранее в этой статье, что Kubernetes — это инфраструктурно-ориентированная технология? Тогда зачем мне приводить это в дискуссию о полностью управляемых решениях PaaS, которые должны быть полностью посвящены приложениям? Что ж, правда в том, что любое серьезное управляемое решение PaaS должно быть построено поверх некоторого уровня оркестровки, который управляет несколькими экземплярами вычислений. И прямо сейчас Kubernetes является стандартом де-факто для оркестрации вычислений в нашей отрасли. Количество мыслей, ресурсов, внимания и энергии, которые он получает, гарантирует, что его качество продолжает улучшаться. Вот некоторые мысли экспертов:
Так что, хотя это может звучать как деталь реализации, которая может не волновать разработчиков, реальность такова, что управляемая PaaS, построенная на Kubernetes, всегда будет более гибкой и «готовой к будущему», чем альтернативы. Примеры:
(8) Управляемая PaaS с автомасштабированием: И да. Наконец, что касается масштаба. Чтобы решение действительно было ориентировано на приложение, оно должно иметь возможность масштабирования — как вверх, так и вниз — без необходимости беспокойства разработчика приложения о том, как добавить или удалить инфраструктуру. Некоторые бессерверные решения FaaS делают это сегодня, но тогда они ограничены моделью программирования функций, поэтому требуется немного больше работы, чтобы объединить существующие приложения. Нам нужно больше решений PaaS (даже классических aPaaS), чтобы двигаться в этом направлении. Я подозреваю, что даже здесь Kubernetes и многие связанные с ним проекты, такие как knative , окажутся надежными технологиями, на которые можно опираться. Примеры:
Надеюсь, эта статья даст вам более четкое представление о различных типах доступных вам вычислительных решений, а также примеры, а также о том, как думать о различных альтернативах в зависимости от вашего аппетита к управлению инфраструктурой.
*Также опубликовано [здесь]. *
Оригинал