Мы много пишем об использовании облачных технологий — а корпоративному IaaS посвятили даже отдельный блог ^[1]. Однако мир технологий постоянно меняется, и появляются все новые подходы к построению инфраструктуры, в том числе с помощью виртуализации, облачных сервисов или контейнеров. Очень легко потеряться во всех доступных опциях и начать задаваться вопросом: «А нельзя ли делать то, что я делаю, более эффективным способом?»

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

• Инфраструктура как услуга (IaaS);
• Платформа как услуга (PaaS);
• Контейнеры как услуга (CaaS).

Когда дело касается веб-инфраструктуры, универсального решения не существует – ко всему требуется индивидуальный подход.

Начнем с начала: выделенные серверы

У истоков хостинг-инфраструктуры стоят дата-центры, заполненные серверами, коммутаторами, маршрутизаторами, массивами с данными и другим сетевым оборудованием. Любое другое решение (PaaS/IaaS/CaaS), о котором мы будем сейчас говорить, являет собой всю ту же картину – огромное количество серверов в огромной комнате, просто поверх всего этого оборудования инженеры добавили несколько уровней абстракции. Это упростило управление системой и автоматизировало некоторые задачи, которые должны были выполняться вручную.

Выделенные серверы, также известные как «голое железо», имеют свои преимущества и недостатки.

Преимущества:

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

Недостатки:

• Сложность управления – клонировать выделенный сервер ^[2] не так легко – для него нельзя создать образ, который потом просто будет работать в другом месте.
• Цена – в большинстве случаев вы платите за аппаратную часть, а также за её размещение, или просто арендуете её у хостинг-провайдера ^[2]. В любом случае, у вас не получится просто отключить сервер, если он вдруг стал вам не нужен – приходится тщательно планировать расходы.
• Все ваши процессы и приложения, запущенные на выделенном сервере, работают на одной операционной системе. Чтобы добиться хорошей масштабируемости, обычно нужно выполнять одну задачу на одном сервере – например, разделить веб-сервер и сервер баз данных. Сложно оптимизировать работу операционной системы, когда она должна справляться с множеством задач сразу.

Упрощаем жизнь: виртуализация

К сожалению, недостатки выделенного сервера сильно перевешивают его достоинства. С постоянно растущей скоростью развертывания и борьбой компаний за лидерство на этом рынке, виртуализация стала естественным шагом в эволюции дата-центров.

Что такое виртуализация

Если в двух словах, то виртуализация позволяет вам разбить выделенный сервер ^[2] на маленькие виртуальные серверы, которые имеют доступ лишь к части всех ресурсов физического сервера.

Вы можете взять физический сервер с двумя четырехядерными процессорами и 16 Гб оперативной памяти и превратить его в 8 виртуальных машин, где на каждую будет выделено одно ядро и 2 Гб оперативной памяти.

Примерами технологий виртуализации могут служить Xen, KVM, VMware и Hyper-V и еще многие другие.

Преимущества:

• Вы можете клонировать виртуальные машины, если вам нужно большее их количество при возросшей нагрузке;
• Можно сохранять образы виртуальных машин, чтобы можно было легко восстановить их.

Недостатки:

• Использование виртуализации означает рост накладных расходов и снижение производительности;
• Образы виртуальных машин, в большинстве своем, нельзя перемещать между хостинг-провайдерами;
• Работа с виртуальными машинами по прежнему требует «ручного» вмешательства, экспертизы и большого количества времени для управления.

Эволюция: виртуализация становится IaaS

В последнее время все чаще, когда люди говорят об облаке, то подразумевают инфраструктуру как услугу (IaaS)?

Так что же такое инфраструктура как услуга?

• Виртуализация чьего-нибудь аппаратного обеспечения, управляемого через API;
• Программный доступ к вычислительным мощностям и хранилищам, а также сетевым ресурсам и конфигурациям;
• Запуск новой машины, когда она нужна, и её отключение, когда работа с ней окончена – вы платите только за время использования;
• Ресурсы дата-центра – это средства обеспечения, предоставляемые в качестве услуги.

Компания Amazon стала первопроходцем в этой сфере, когда в 2006 запустила инфраструктуру Amazon Web Services (AWS) и веб-сервис EC2. С течением времени в разных странах мира появились свои игроки — вот тут ^[3], к примеру, представлен рейтинг провайдеров России.

Почему это так важно?

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

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

1. Разработчики получили «суперспособности»:

• Новую идею можно запускать незамедлительно;
• Если идея оказалась успешной, то очень легко расширять серверную базу;
• Если идея оказалась неудачной, то денежные потери будут минимальными.

Вот здесь ^[4] можно почитать о том, какие модели оплаты IaaS сейчас существуют на российском рынке.

2. Больше возможностей для автоматизации работы дата-центров:

• Полностью автоматизированная архитектура стала реальностью – появилась концепция инфраструктуры как кода;
• Автоматическое масштабирование ранее представлялось невозможным, однако сейчас веб-инфраструктура способна расширяться и сжиматься в соответствии с нуждами пользователя;
• Очень быстро произошла автоматизация различных частей дата-центра: хранилища, сетевые технологии и огромное количество других систем, которые требовали определенного набора навыков, стали управляться через API, что открыло новые горизонты возможностей обществу разработчиков.

Теперь, когда мы рассмотрели основные части IaaS, мы можем перейти к следующей теме – PaaS (платформа как услуга).

PaaS

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

Существует огромное количество PaaS-провайдеров: одним из самых популярных является Heroku. Интересный факт – Heroku полностью работает поверх AWS и связана с ним. Это может оказаться проблемой, если вы не хотите запускать свое приложение на серверах AWS.

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

Создать PaaS очень сложно

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

• Система сборки, которая компилирует код и хранит его для дальнейшего использования;
• База данных управления приложениями, которая следит за изменениями в Git, рабочими версиями и мета-данными приложения;
• Планировщик заданий кластеров, который работает с огромной группой серверов как с одним большим компьютером, запуская ваше приложение на нескольких машинах сразу, а также осуществляет слежение за выполнением задач;
• Балансировщик нагрузки, который управляет трафиком, идущим из интернета, и курсирующим между различными приложениями;
• Автоматизация работы DNS, которая создает записи автоматически при изменении приложений;
• И, вероятно, самый важный компонент, некая форма контейнеризации (FreeBSD Jail, Solaris Zones, Linux Containers), которая будет предотвращать вмешательство одного приложения в работу другого.

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

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

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

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

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

IaaS или PaaS, что же лучше?

Говоря простым языком, IaaS напоминает сдачу сервера в аренду на определённый промежуток времени. PaaS можно описать как нечто-более сложное: связанный набор инструментов, позволяющих запустить ваше веб-приложение и управлять им.
Давайте проведем сравнение по ключевым пунктам и ответим на поставленный вопрос.

Производительность

Очень маловероятно, что вы заметите значительные отличия в скорости работы типичного приложения на IaaS и PaaS. Однако PaaS ушла достаточно далеко от «железа» – это как сравнивать физическое и виртуальное аппаратное обеспечение – потери неизбежны.

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

Первый раунд: побеждает IaaS (с незначительным преимуществом).

Надежность

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

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

Второй раунд: побеждает IaaS.

Масштабируемость

Здесь PaaS предлагает несколько решений, очень похожих на автоматизированное масштабирование, которые обходят IaaS.

В типичной PaaS-системе увеличить или уменьшить число воркеров (workers) не сложнее, чем обработать простую команду. Это может быть полезно для запланированных событий с резким повышением трафика.

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

IaaS, AWS-платформа в частности, предлагает мощные инструменты для автоматизированного масштабирования, однако для этого требуется создание образов машин для каждого релиза, а также ручная настройка правил, по которым будет выполняться масштабирование.

Третий раунд: PaaS, хотя можно и лучше.

Управление жизненным циклом приложения (ALM)

Здесь у IaaS нет ни единого шанса – управление жизненным циклом является визитной карточкой любой PaaS-платформы.

Если вы пойдете дорогой IaaS, то придется использовать свое собственное решение для управления приложениями: слежение за инфраструктурой, изменениями приложения и увеличением количества инстансов. Существует большое количество качественных инструментов, однако PaaS дает их, так сказать, «из коробки».

Большинство (все?) PaaS-платформ предоставляют универсальный интерфейс для управления приложениями. Подкупает то, с какой легкостью вы можете дублировать целые среды. Вы можете запустить клона всей своей системы всего за пару минут.

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

Хотя многие PaaS-системы обеспечивают инструментарий для агрегации логов, мы часто сталкивались с ситуациями, когда предоставляемая информация не обладала достаточной «прозрачностью», потому поиск неполадок затягивался. Несчетное количество часов было потрачено на отладку приложения, которое отказывалось корректно размещаться – нам очень сильно хотелось подключиться по SSH и просмотреть лог-файлы.

Четвертый раунд за PaaS, но хотелось бы большей «прозрачности».

Стоимость

Стоимость, разумеется, зависит от того, какого провайдера вы предпочтете (и в какой стране он будет находиться).

Допустим, что для запуска приложения требуется 512 Мб оперативной памяти и 5 рабочих процессов. На Pivotal Web Services вам придется отдавать около $55 в месяц. Средний инстанс EC2 с 3,75 Гб оперативной памяти у зарубежных провайдеров обойдется в $40 в месяц.

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

Вот только стоимость некоторых платформ, например, Heroku, может быстро стать слишком большой (даже по меркам IaaS).

Пятый раунд: победитель не определен.

Итак, IaaS или PaaS

Получилось так, что в некоторых сферах выигрывает PaaS, а в других – IaaS. Такова реальность.

Основываясь на собственном опыте, можем сказать, что для приложений с критической рабочей нагрузкой больше подойдет IaaS – модель PaaS пока недостаточно развита и имеет определенное количество «слабых мест». Однако можно ожидать, что со временем PaaS-платформы «закалятся», станут стабильнее, а их операционная прозрачность вырастет.

Если вы можете позволить себе большую степень риска, то PaaS предлагает гибкие возможности по управлению приложениями, позволяющие значительно ускорить этот процесс, по сравнению с IaaS.

Контейнерные хостинг-платформы

Что такое контейнерные хостинг-платформы или контейнеры как услуга (CaaS)? Это все, что было описано в предыдущих секциях, но построенное на основе элементов, предоставляемых Docker.

Автоматизированная система сборки, кластерный планировщик, балансировщик нагрузки, автоматизация DNS и обнаружение сервисов – это то, что вам нужно, чтобы использовать контейнеры для хостинга ^[2] сложных многоуровневых приложений.

Вместо неудобных билдпаков (buildpacks) для создания приложений, вы получаете образы Docker. Образы легко собрать и протестировать перед развертыванием, поэтому вы всегда уверены, что все работает как надо. Теперь пользователи не ограничены предоставляемым провайдером набором инструментов и могут запускать все что угодно в образе Docker.

Однако выбор верной контейнерной хостинг-платформы Docker нелегкая задача. Вот несколько моментов, на которые стоит обратить внимание:

• Выбор огромен, однако когда ваши приложения готовы для работы с Docker, тестирование каждого из них становится тривиальной задачей;
• Использование решения, предлагаемого вашим хостинг-провайдером, например Triton или ECS, все-равно привязывает вас к нему [провайдеру], что нивелирует такое достоинство Docker, как переносимость;
• Многие CaaS-решения имеют систему управления, запущенную на их собственном оборудовании, и агента, который соединяется с API на ваших серверах – это грозит отключением вашего кластера;
• Решения, позволяющие вам запускать всю систему с брандмауэром, сложны и имеют миллионы жизненно важных элементов, потому для работы (обновления и управления) с ними потребуется своя команда;
• Простые решения с брандмауэром не обладают высокой доступностью;
• Вместо зависимости от хостинг-провайдера ^[2] вы получаете зависимость от CaaS-провайдера. Нельзя запустить все платформу, включающую систему управления, API и пользовательский интерфейс, на своем собственном оборудовании, без использования интерфейса управления SaaS. Начав платить, лучше продолжить это делать.

Заключение

Спасибо за то, что прочли этот исторический экскурс в развитие веб-хостинга от выделенных серверов до CaaS. Мы надеемся, что данный материал ответил хотя бы на некоторые ваши вопросы и дал понимание того, какую выгоду способны принести контейнеры.

Посты по теме:

• Как развиваются облака: 6 статистических фактов ^[5]
• Все по-новому: Как переход в облако меняет роль внутренней ИТ-службы ^[6]
• Зачем бизнесу облако: обзор реальных сценариев использования IaaS ^[7]
• Как оценить выгоду от переезда в облако ^[8]
• SaaS, PaaS, IaaS или своё «железо»: что используют отечественные ИТ-компании ^[9]

Автор: ИТ-ГРАД

Источник ^[10]