Коммунальный подход и облака

Идея оптимизации использования ресурсов за счет их разделения появилась в 1957 году, когда Боб Бремер предложил делить время центрального процессора между несколькими задачами. В том же году под руководством Джона Маккарти была создана операционная система Compatible Time-Sharing System (CTSS), поддерживающая такой режим на мэйнфреймах IBM 704 и IBM 7090. С тех пор было создано множество разнообразных систем совместного использования ресурсов. Отличительная черта коммунальной модели состоит в том, что здесь распределение ресурсов осуществляется не напрямую, а опосредованно, в форме сервисов, плюс вводится специальная модель оплаты за эти сервисы, построенная на принципах pay-per-use («оплата по мере использования»). Оплата может осуществляться исходя из числа пользователей, объема использованных данных, времени использования серверов.

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

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

Предоставление инфраструктуры в качестве сервисов первоначально называли HaaS (Hardware as a Service), то есть «аппаратное обеспечение как сервис»; иногда еще говорят о «рабочем месте как сервисе» — WaaS (Workplace as a Service). Основное достоинство IaaS в возможности получать линейно масштабируемые ресурсы практически без ограничения и платить за них по мере использования. В основе IaaS лежат современные технологии виртуализации отдельных серверов и ЦОД в целом. Необходимость в переходе на нижний уровень в архитектуры IaaS возникает в том случае, если используется какое-то нестандартное ПО, то есть когда потребность не может быть удовлетворена на уровне SaaS. При оценке потенциала IaaS необходимо учитывать, что, несмотря на все слова об облачности и виртуальности, приложения работают на реальных физических серверах, а это значит, что надо учитывать, что эти серверы имеют определенные характеристики: большинство из них построено на платформе LAMP (Linux, Apache, MySQL и Perl/PHP/Python), и не для всех приложений это лучший выбор; предприятия уже имеют собственные ресурсы, которые надо загружать; могут иметь значение законодательные акты, действующие на той или иной территории.

Для обеспечения линейного масштабирования SaaS теоретически возможны два архитектурных подхода — multi-tenancy и multi-instance. Первое — это специальный прием программирования или архитектурное решение, поддерживающее использование одновременно несколькими клиентами одного экземпляра программы. В основе нового термина лежит слово tenant, который буквально означает «жилец»; действительно, для иллюстрации multi-tenancy ничего точнее, чем коммунальная квартира, в русском языке не найти, поэтому можно было бы называть такую архитектуру коммунальной, если бы это слово уже не было использовано для utility computing. В отличие от физической коммунальной квартиры виртуальная облачная квартира имеет раздвижные перегородки, и ее конфигурацию можно менять по мере необходимости. Multi-tenancy можно интерпретировать как технологическое решение, позволяющее нескольким пользователям независимо друг от друга разделять один и тот же ресурс, не нарушая при этом конфиденциальности и защиты принадлежащих им данных.

Альтернативой multi-tenancy является архитектура multi-instance (instance — «образец», «экземпляр»), позволяющая для каждого пользователя выделять его собственную часть облака для выполнения своих приложений. Преимущества такого подхода в большей надежности: падение одного экземпляра не влияет на другие, а данные строго разделены. Можно сказать, что архитектура multi-instance возвращает нас в исторический период «одно приложение — один сервер», но на качественно ином уровне, серверы являются виртуальными машинами. Виртуальность обеспечивает multi-instance масштабируемость, сопоставимую с коммунальной архитектурой.