Автор: Дэвид М. Фишман
Как-то на заре моей карьеры, задолго до OpenStack, я отправил по email шутку команде разработчиков. Шутка заканчивалась фразой: ни один человек с трехзначным IQ не будет спорить о том, что лучше – Emacs или VI, или наоборот. Что меня удивило, так это ответ, который я получил, что-то вроде:
«Эй, это прозвучало очень оскорбительно и бестактно. Не могу поверить, что ты мог прислать такое по email!»
Если вы пережили разделение DevOps, вам известно, что разработчики могут защищать свой выбор инструментов разработки более агрессивно, чем рассерженная лягушка с солнечным ожогом. Связано ли это с расстройством ввиду недостаточной зрелости или причиной тому самоуверенность, как бы то ни было, это может быть одним из самых серьезных барьеров на пути внедрения облака и еще большим на пути внедрения OpenStack.
Являются ли культурные различия и организационные модели причиной или следствием балканизации IT – вопрос спорный (некоторые моменты дискуссии затронуты в нашем блоге здесь). Как бы то ни было, моя цель – рассмотреть, как данную проблему раскола открыто решает OpenStack, делая выбор платформы как услуги (PaaS) разработчиком в большей степени функциональным решением и в меньшей – обязательством на 99 лет.
Огромный прогресс, который мы наблюдали на пути *aaS-ификации за последние 10 лет, образовал значительную пропасть между разработчиками приложений и той инфраструктурой, на которой эти приложения работают. Между тем, в среде OpenStack есть соблазн думать, что проблема решена путем выражения элементов построения инфраструктуры через прикладной программный интерфейс ReST.
Но это как раз выворачивает проблему наизнанку. Интерфейсы к облачным компонентам на базе сервисов не образуют среду, готовую к использованию приложений, не говоря уже о среде, которая служит надежным хостом и основой для работы постоянно меняющегося множества приложений. Простое оглашение списка прикладных программных приложений ReST не убедит разработчиков в том, что «Cattle» станут «Pets». Каким именно образом мы ожидаем от владельцев серверов/приложений класса Pets превращения «котов» и «собак» в «мясомолочные комбинаты»? Pet-приложения работают на Pet-серверах.
Имея собственный набор устройств, команды разработчиков будут диктовать инфраструктурные ограничения для собственного набора приложений, и операционные команды будут иметь дело с теми же несоответствиями и разрозненностью, которые мешают им в работе сегодня. Инициатива OpenStack должна принять тот факт, что именно разработчикам приложений нужно понять ту роль, которую им придется играть в процессе перехода на облачную среду. Нам нужно помочь разработчикам осознать, почему они не могут просто продолжать вести себя, как прежде, и думать об инфраструктуре исключительно как о чем-то, на что можно возлагать вину за отвратительное функционирование и перебои в работе.
Чтобы разобраться с проблемой, давайте пойдем в обратном направлении: что нужно разработчикам для того, чтобы их приложения успешно работали в среде инфраструктуры как услуги (IaaS)? Преодоление образовавшейся пропасти подразумевает, что инициатива OpenStack должна предложить абстракции для решения реальных проблем разработчика таким способом, который целесообразен для разработчика. Для этого у OpenStack есть несколько проектов, призванных помочь PaaS-разработчикам в создании среды, в которой они смогут преуспеть.
На сегодняшний день в экосистеме OpenStack бытует мнение о том, что нужно применить ту же «агрессивную модуляризацию», которая лежит в основе проекта OpenStack, к решению проблемы органичного соединения PaaS и IaaS. Такая модуляризация охватывает 3 основных измерения:
-Превращение исходного кода во что-то, что сможет работать в облаке.
-Поиск приложений, которые можно использовать или потреблять повторно.
-Обобщение топологии развертывания, включая аппаратные ресурсы и конфигурации, а также исполняемые программные компоненты.
Если вы являетесь сторонником PaaS, то можете сказать: «Минуточку, PaaS именно это и делает. Точка». И это не глупый ответ, как и не достаточное основание для того, чтобы усомниться в трехзначном IQ. Но придержите свое неверие на мгновение.
Когда я начал заниматься программированием, немногим позже того, как люди научились добывать огонь и изобрели колесо, исходный текст был чем-то, что я компилировал (или надеялся скомпилировать; Visual Basic имел большой успех). Сегодня целью является не компилятор, а облако, и на выходе получаются не двоичные, а пакетные данные.
Безусловно, это упрощенное представление. Важнейшее значение имеют инструменты сборки, такие как Jenkins, которые работают из дерева исходного кода и выдают код, готовый к применению. В наиболее перспективных методах разработки облака Jenkins помогает запустить процесс непрерывной интеграции и непрерывной разработки, также известный как CI/CD (механизмы CI/CD в данном посте подробно не рассматриваются). Развертывание не будет успешным, если некорректно осуществлена упаковка в библиотеки и компоненты; для поддержания приложений в актуальном состоянии важную роль играет стандартизация.
Проектом OpenStack, который отвечает за эту область решения проблемы, является Solum. Несмотря на то, что некоторые позиционируют Solum как замену сегодняшним PaaS-технологиям, его нельзя отнести к разряду «или-или». Вместо того, чтобы быть просто общедоступной PaaS, целью Solum является предоставление услуг, которые делают возможным функционирование PaaS в рамках OpenStack.
По сути, если Solum получится таким, как задумано, он предоставит инструментарий, который позволит любому имеющемуся приложению, в том числе другой PaaS, генерировать артефакт, который можно будет развернуть на облаке OpenStack. Задумка в том, что Solum будет знать, для чего нужен «такой-то развертываемый элемент» в конкретном облаке. Иными словами, Solum мог бы предоставить противоядие от привязки к PaaS.
Примерно на один уровень выше в стеке повторно используемый код – фантазия настолько же древняя, как я сам. Облачные технологии оказали в этом содействие. Но нужно сделать так, чтобы повторно используемые готовые к развертыванию приложения было проще найти и использовать. Зачем ломать голову, пытаясь понять, как развернуть сервер Tomcat, когда можно просто нажать для этого кнопку?
«Каталог услуг» является общеизвестным понятием в мире библиотеки инфраструктуры информационных технологий ITIL (хотя большинство разработчиков приложений считают, что ITIL – это не их проблема), примерно таким же интересным, как, скажем, протокол SNMP. Каталог, который организует готовые к использованию облачные приложения, не только избавляет от необходимости заново изобретать колесо для вашего облачного приложения; но и обеспечивает механизм для распределения проверенных прикладных компонентов. Магазины приложений – это каталоги, которые сделали мобильные телефоны тем, чем они являются сегодня (интересный взгляд на проблему поиска приложений представлен на Quixey.)
Безусловно, у вас нет необходимости часто объединять приложения на смартфоне; чего нельзя сказать об облаке, где это обычное явление. При этом, несомненно, хорошо, когда не приходится сталкиваться с проблемой развертывания базы данных в формате JSON с нуля или разбираться с тем, как подогнать СУБД Microsoft SQL Server под гостевую ОС Windows, работающую на KVM в OpenStack. Наличие унифицированного списка описателей по требованиям, функциональным возможностям, правам доступа и т.д. и установление правил по всем этим аспектам приложения одинаково критично как для обнаружения, так и для управления и технического обслуживания. Такой каталог предоставляется усилиями проекта Murano в составе OpenStack.
Классическое определение упаковки подразумевает что, с ее помощью определяются ресурсы и взаимосвязи. В контексте облака ресурсами и взаимосвязями является распределенная инфраструктура. В упрощенном представлении IaaS определяет VM с некоторой памятью и сетевым адресом, по которому вы «устанавливаете» приложение, как если бы оно работало на паре компьютеров Mac Mini и через маршрутизатор за вашим столом.
Конечно, все это не так хорошо работает в распределенной среде с множеством ресурсов инфраструктуры. В облаке вам нужна возможность «говорить» инфраструктуре, что, ваше приложение нуждается, скажем, в двух сетях:
-У сети A есть серверы Apache, IP-адреса которых назначаются протоколом DHCP.
-У сети B есть база данных и прослушиватели на портах X, Y, и Z.
-Маршрутизатор между ними с политиками доступа, определенными таким-то образом…
Если вы когда-либо пытались развернуть приложение на разных физических ресурсах, вам могут быть знакомы такие зависимости. Их точное указание (а также последовательное соблюдение) и отладка при возникновении проблем не являются необязательными или тривиальными.
Согласно определению, проект по оркестровке облачных приложений на базе OpenStack, или Heat, созданный по образцу AWS CloudFormation, призван решить данную проблему. Это декларативный язык, который должен ответить на вопрос: «Что нужно вашему приложению?» Heat создает эквивалент контрольного списка действий к выполнению, который затем преобразуется механизмом Heat в соответствующие графы зависимостей, последовательность вызовов IaaS и т.д., тем самым способствуя самоорганизации лежащих в основе инфраструктуры примитивов в должным образом сконфигурированную среду выполнения. Почему Heat? Несомненно, одним из его преимуществ является отсутствие привязки к AWS при развертывании на OpenStack. Но другой плюс заключается в том, что при изменении инфраструктуры вы сможете воспользоваться преимуществами новых компонентов.
Итак, после подобного «анализа разрыва» не будет ли проще выполнить развертывание на PaaS и всё? Для организаций, которые очень четко представляют будущее ландшафта своего ПО, это было бы просто отлично. Тех, кто может бросить взгляд назад на годы технического долга (накопленного в результате былой уверенности в будущем плана развития ПО), это может заставить подумать о PaaS.
Удобство PaaS-решений заключается в том, что они обеспечивают единую, комплексную инфраструктуру. Можно начать с исходного кода, а об упаковке, каталогизировании и развертывании пусть позаботится PaaS; попробуйте переместить то, что уже собрано в PaaS, с одной IaaS на другую, и это может оказаться не так уж и просто. У каждой PaaS есть свой способ контейнеризации приложения, иногда не более чем путем конфигурации отдельного образа VM, на котором будет работать приложение, и предоставления ему свободы в вашей инфраструктуре.
Перемещение приложения с одной PaaS на другую – тоже задача не из легких. Это как если бы вы вытащили картридж из одного принтера и попытались использовать его в другом, даже если у обоих принтеров один и тот же производитель.
Было бы преувеличением предположить, что работа на OpenStack является такой же функционально полной, как на стандартной PaaS (не говоря уже о размещаемых PaaS типа Heroku; опыт работы разработчика на Heroku довольно приятный).
Но именно такие нефункциональные качества, как производительность, масштабируемость, безопасность и др. должны сделать OpenStack более привлекательной альтернативой. И, если вы представите облако, на котором может вместе работать множество различных приложений в той или иной степени операционной гармонии, то вам стоит подумать о PaaS (хорошо, это последний раз, когда я использую эту фразу). Если каждое приложение будет отвечать за собственное хранение данных, вычисления и потребление сетевых ресурсов, то это может с легкостью породить облачный хаос.
Заглядывая вперед, можно сказать, что инициатива OpenStack пытается найти способы упростить взаимодействие и эксплуатационную совместимость между естественным многообразием инструментов PaaS, чтобы вы смогли объединять приложения из различных PaaS в единообразной инфраструктуре OpenStack. На период выхода релиза Juno и следующего за ним релиза цели таковы:
— Начиная с процесса сборки, проект Solum предоставит набор инструментов для каждой PaaS. Он представит API, который будет брать исходный код из PaaS и генерировать образ, который будет работать с параметрами упаковки/временем исполнения, совместимыми с OpenStack. Проект Solum будет получать инструкции по сборке от PaaS и применять их для направления выходных данных PaaS в контейнер/ гостевую ОС/ виртуальную машину/ образ и т.д.
— У каждой PaaS имеется внутренний, закрытый каталог услуг. В нем задаются важные детали того, как приложение пользуется каждой представленной услугой на основе таких базовых параметров, как строка подключения. Напротив, подход OpenStack, выраженный в проекте Murano через обобщенную структуру каталогов, позволяет объединять приложения и услуги независимо от изначальной среды разработки. Вы получаете гораздо больший выбор в каталоге благодаря объединению различных PaaS или порождению услуг из других источников, тем самым избегая привязки (в действительности, стратегия Murano также нацелена на включение в каталог ряда стандартов упаковки приложений, таких как TOSCA, Parallels APS, или даже шаблонов Heat.
— Каталог Murano может запустить генерацию шаблона Heat во время развертывания для распределения ресурсов IaaS OpenStack, необходимых для запуска набора приложений. По мере изменения инфраструктуры и добавления новых возможностей в IaaS OpenStack устранение привязки инфраструктуры к приложению означает, что инфраструктура может более оперативно адаптироваться под меняющиеся требования и компоненты платформы.
В соответствии с изначальной ориентированностью на инфраструктуру инициатива OpenStack сегодня может предложить больше на стороне развертывания, чем на стороне разработки в образовавшемся разрыве между PaaS и IaaS. Но принять это как желаемое положение дел – всё равно, что игнорировать течь по левому борту лодки только потому, что вы находитесь на палубе по правому борту. И наблюдаются признаки того, что сообщество PaaS готово всерьез воспользоваться данной возможностью, как показывают недавние обсуждения платформы Cloud Foundry для OpenStack.
Конечно, независимые вендоры PaaS всегда могут просто подождать, пока вендоры IaaS адаптируются под их допущения. Но делать на это ставку опрометчиво. Предположение о том, что одни методы PaaS решают все прошлые и будущие проблемы с облачными приложениями, наверно, так же надежно, как привязка к тому или иному языку программирования эпохи 90-х или к какой-нибудь другой технологической платформе от компании Seattle. Лучше вендорам PaaS засучить рукава и внести лепту в успешную реализацию уровней Solum, Murano и Heat в составе OpenStack.
На самом деле, если непрекращающиеся споры «Emacs или VI» являются каким-то показателем, то поддержка более эффективной интеграции с OpenStack даже может быть разумной стратегией среди поставщиков PaaS для гарантии того, что они не повторят судьбу Visual Basic.
Оригинал статьи на английском языке.
Как-то на заре моей карьеры, задолго до OpenStack, я отправил по email шутку команде разработчиков. Шутка заканчивалась фразой: ни один человек с трехзначным IQ не будет спорить о том, что лучше – Emacs или VI, или наоборот. Что меня удивило, так это ответ, который я получил, что-то вроде:
«Эй, это прозвучало очень оскорбительно и бестактно. Не могу поверить, что ты мог прислать такое по email!»
Если вы пережили разделение DevOps, вам известно, что разработчики могут защищать свой выбор инструментов разработки более агрессивно, чем рассерженная лягушка с солнечным ожогом. Связано ли это с расстройством ввиду недостаточной зрелости или причиной тому самоуверенность, как бы то ни было, это может быть одним из самых серьезных барьеров на пути внедрения облака и еще большим на пути внедрения OpenStack.
Являются ли культурные различия и организационные модели причиной или следствием балканизации IT – вопрос спорный (некоторые моменты дискуссии затронуты в нашем блоге здесь). Как бы то ни было, моя цель – рассмотреть, как данную проблему раскола открыто решает OpenStack, делая выбор платформы как услуги (PaaS) разработчиком в большей степени функциональным решением и в меньшей – обязательством на 99 лет.
ReST не поможет заглянуть в головы разработчикам
Огромный прогресс, который мы наблюдали на пути *aaS-ификации за последние 10 лет, образовал значительную пропасть между разработчиками приложений и той инфраструктурой, на которой эти приложения работают. Между тем, в среде OpenStack есть соблазн думать, что проблема решена путем выражения элементов построения инфраструктуры через прикладной программный интерфейс ReST.
Но это как раз выворачивает проблему наизнанку. Интерфейсы к облачным компонентам на базе сервисов не образуют среду, готовую к использованию приложений, не говоря уже о среде, которая служит надежным хостом и основой для работы постоянно меняющегося множества приложений. Простое оглашение списка прикладных программных приложений ReST не убедит разработчиков в том, что «Cattle» станут «Pets». Каким именно образом мы ожидаем от владельцев серверов/приложений класса Pets превращения «котов» и «собак» в «мясомолочные комбинаты»? Pet-приложения работают на Pet-серверах.
Имея собственный набор устройств, команды разработчиков будут диктовать инфраструктурные ограничения для собственного набора приложений, и операционные команды будут иметь дело с теми же несоответствиями и разрозненностью, которые мешают им в работе сегодня. Инициатива OpenStack должна принять тот факт, что именно разработчикам приложений нужно понять ту роль, которую им придется играть в процессе перехода на облачную среду. Нам нужно помочь разработчикам осознать, почему они не могут просто продолжать вести себя, как прежде, и думать об инфраструктуре исключительно как о чем-то, на что можно возлагать вину за отвратительное функционирование и перебои в работе.
Положение дел между PaaS и IaaS
Чтобы разобраться с проблемой, давайте пойдем в обратном направлении: что нужно разработчикам для того, чтобы их приложения успешно работали в среде инфраструктуры как услуги (IaaS)? Преодоление образовавшейся пропасти подразумевает, что инициатива OpenStack должна предложить абстракции для решения реальных проблем разработчика таким способом, который целесообразен для разработчика. Для этого у OpenStack есть несколько проектов, призванных помочь PaaS-разработчикам в создании среды, в которой они смогут преуспеть.
На сегодняшний день в экосистеме OpenStack бытует мнение о том, что нужно применить ту же «агрессивную модуляризацию», которая лежит в основе проекта OpenStack, к решению проблемы органичного соединения PaaS и IaaS. Такая модуляризация охватывает 3 основных измерения:
-Превращение исходного кода во что-то, что сможет работать в облаке.
-Поиск приложений, которые можно использовать или потреблять повторно.
-Обобщение топологии развертывания, включая аппаратные ресурсы и конфигурации, а также исполняемые программные компоненты.
Если вы являетесь сторонником PaaS, то можете сказать: «Минуточку, PaaS именно это и делает. Точка». И это не глупый ответ, как и не достаточное основание для того, чтобы усомниться в трехзначном IQ. Но придержите свое неверие на мгновение.
Solum: отправка исходного кода на облако
Когда я начал заниматься программированием, немногим позже того, как люди научились добывать огонь и изобрели колесо, исходный текст был чем-то, что я компилировал (или надеялся скомпилировать; Visual Basic имел большой успех). Сегодня целью является не компилятор, а облако, и на выходе получаются не двоичные, а пакетные данные.
Безусловно, это упрощенное представление. Важнейшее значение имеют инструменты сборки, такие как Jenkins, которые работают из дерева исходного кода и выдают код, готовый к применению. В наиболее перспективных методах разработки облака Jenkins помогает запустить процесс непрерывной интеграции и непрерывной разработки, также известный как CI/CD (механизмы CI/CD в данном посте подробно не рассматриваются). Развертывание не будет успешным, если некорректно осуществлена упаковка в библиотеки и компоненты; для поддержания приложений в актуальном состоянии важную роль играет стандартизация.
Проектом OpenStack, который отвечает за эту область решения проблемы, является Solum. Несмотря на то, что некоторые позиционируют Solum как замену сегодняшним PaaS-технологиям, его нельзя отнести к разряду «или-или». Вместо того, чтобы быть просто общедоступной PaaS, целью Solum является предоставление услуг, которые делают возможным функционирование PaaS в рамках OpenStack.
По сути, если Solum получится таким, как задумано, он предоставит инструментарий, который позволит любому имеющемуся приложению, в том числе другой PaaS, генерировать артефакт, который можно будет развернуть на облаке OpenStack. Задумка в том, что Solum будет знать, для чего нужен «такой-то развертываемый элемент» в конкретном облаке. Иными словами, Solum мог бы предоставить противоядие от привязки к PaaS.
Murano: это нужно делать мне, или кто-то уже это делает?
Примерно на один уровень выше в стеке повторно используемый код – фантазия настолько же древняя, как я сам. Облачные технологии оказали в этом содействие. Но нужно сделать так, чтобы повторно используемые готовые к развертыванию приложения было проще найти и использовать. Зачем ломать голову, пытаясь понять, как развернуть сервер Tomcat, когда можно просто нажать для этого кнопку?
«Каталог услуг» является общеизвестным понятием в мире библиотеки инфраструктуры информационных технологий ITIL (хотя большинство разработчиков приложений считают, что ITIL – это не их проблема), примерно таким же интересным, как, скажем, протокол SNMP. Каталог, который организует готовые к использованию облачные приложения, не только избавляет от необходимости заново изобретать колесо для вашего облачного приложения; но и обеспечивает механизм для распределения проверенных прикладных компонентов. Магазины приложений – это каталоги, которые сделали мобильные телефоны тем, чем они являются сегодня (интересный взгляд на проблему поиска приложений представлен на Quixey.)
Безусловно, у вас нет необходимости часто объединять приложения на смартфоне; чего нельзя сказать об облаке, где это обычное явление. При этом, несомненно, хорошо, когда не приходится сталкиваться с проблемой развертывания базы данных в формате JSON с нуля или разбираться с тем, как подогнать СУБД Microsoft SQL Server под гостевую ОС Windows, работающую на KVM в OpenStack. Наличие унифицированного списка описателей по требованиям, функциональным возможностям, правам доступа и т.д. и установление правил по всем этим аспектам приложения одинаково критично как для обнаружения, так и для управления и технического обслуживания. Такой каталог предоставляется усилиями проекта Murano в составе OpenStack.
Развертывание: определение ресурсов, которые необходимы приложениям на облаке
Классическое определение упаковки подразумевает что, с ее помощью определяются ресурсы и взаимосвязи. В контексте облака ресурсами и взаимосвязями является распределенная инфраструктура. В упрощенном представлении IaaS определяет VM с некоторой памятью и сетевым адресом, по которому вы «устанавливаете» приложение, как если бы оно работало на паре компьютеров Mac Mini и через маршрутизатор за вашим столом.
Конечно, все это не так хорошо работает в распределенной среде с множеством ресурсов инфраструктуры. В облаке вам нужна возможность «говорить» инфраструктуре, что, ваше приложение нуждается, скажем, в двух сетях:
-У сети A есть серверы Apache, IP-адреса которых назначаются протоколом DHCP.
-У сети B есть база данных и прослушиватели на портах X, Y, и Z.
-Маршрутизатор между ними с политиками доступа, определенными таким-то образом…
Если вы когда-либо пытались развернуть приложение на разных физических ресурсах, вам могут быть знакомы такие зависимости. Их точное указание (а также последовательное соблюдение) и отладка при возникновении проблем не являются необязательными или тривиальными.
Согласно определению, проект по оркестровке облачных приложений на базе OpenStack, или Heat, созданный по образцу AWS CloudFormation, призван решить данную проблему. Это декларативный язык, который должен ответить на вопрос: «Что нужно вашему приложению?» Heat создает эквивалент контрольного списка действий к выполнению, который затем преобразуется механизмом Heat в соответствующие графы зависимостей, последовательность вызовов IaaS и т.д., тем самым способствуя самоорганизации лежащих в основе инфраструктуры примитивов в должным образом сконфигурированную среду выполнения. Почему Heat? Несомненно, одним из его преимуществ является отсутствие привязки к AWS при развертывании на OpenStack. Но другой плюс заключается в том, что при изменении инфраструктуры вы сможете воспользоваться преимуществами новых компонентов.
Может ли PaaS сделать шаг назад в будущее?
Итак, после подобного «анализа разрыва» не будет ли проще выполнить развертывание на PaaS и всё? Для организаций, которые очень четко представляют будущее ландшафта своего ПО, это было бы просто отлично. Тех, кто может бросить взгляд назад на годы технического долга (накопленного в результате былой уверенности в будущем плана развития ПО), это может заставить подумать о PaaS.
Удобство PaaS-решений заключается в том, что они обеспечивают единую, комплексную инфраструктуру. Можно начать с исходного кода, а об упаковке, каталогизировании и развертывании пусть позаботится PaaS; попробуйте переместить то, что уже собрано в PaaS, с одной IaaS на другую, и это может оказаться не так уж и просто. У каждой PaaS есть свой способ контейнеризации приложения, иногда не более чем путем конфигурации отдельного образа VM, на котором будет работать приложение, и предоставления ему свободы в вашей инфраструктуре.
Перемещение приложения с одной PaaS на другую – тоже задача не из легких. Это как если бы вы вытащили картридж из одного принтера и попытались использовать его в другом, даже если у обоих принтеров один и тот же производитель.
Было бы преувеличением предположить, что работа на OpenStack является такой же функционально полной, как на стандартной PaaS (не говоря уже о размещаемых PaaS типа Heroku; опыт работы разработчика на Heroku довольно приятный).
Но именно такие нефункциональные качества, как производительность, масштабируемость, безопасность и др. должны сделать OpenStack более привлекательной альтернативой. И, если вы представите облако, на котором может вместе работать множество различных приложений в той или иной степени операционной гармонии, то вам стоит подумать о PaaS (хорошо, это последний раз, когда я использую эту фразу). Если каждое приложение будет отвечать за собственное хранение данных, вычисления и потребление сетевых ресурсов, то это может с легкостью породить облачный хаос.
Заглядывая вперед, можно сказать, что инициатива OpenStack пытается найти способы упростить взаимодействие и эксплуатационную совместимость между естественным многообразием инструментов PaaS, чтобы вы смогли объединять приложения из различных PaaS в единообразной инфраструктуре OpenStack. На период выхода релиза Juno и следующего за ним релиза цели таковы:
— Начиная с процесса сборки, проект Solum предоставит набор инструментов для каждой PaaS. Он представит API, который будет брать исходный код из PaaS и генерировать образ, который будет работать с параметрами упаковки/временем исполнения, совместимыми с OpenStack. Проект Solum будет получать инструкции по сборке от PaaS и применять их для направления выходных данных PaaS в контейнер/ гостевую ОС/ виртуальную машину/ образ и т.д.
— У каждой PaaS имеется внутренний, закрытый каталог услуг. В нем задаются важные детали того, как приложение пользуется каждой представленной услугой на основе таких базовых параметров, как строка подключения. Напротив, подход OpenStack, выраженный в проекте Murano через обобщенную структуру каталогов, позволяет объединять приложения и услуги независимо от изначальной среды разработки. Вы получаете гораздо больший выбор в каталоге благодаря объединению различных PaaS или порождению услуг из других источников, тем самым избегая привязки (в действительности, стратегия Murano также нацелена на включение в каталог ряда стандартов упаковки приложений, таких как TOSCA, Parallels APS, или даже шаблонов Heat.
— Каталог Murano может запустить генерацию шаблона Heat во время развертывания для распределения ресурсов IaaS OpenStack, необходимых для запуска набора приложений. По мере изменения инфраструктуры и добавления новых возможностей в IaaS OpenStack устранение привязки инфраструктуры к приложению означает, что инфраструктура может более оперативно адаптироваться под меняющиеся требования и компоненты платформы.
Заключение
В соответствии с изначальной ориентированностью на инфраструктуру инициатива OpenStack сегодня может предложить больше на стороне развертывания, чем на стороне разработки в образовавшемся разрыве между PaaS и IaaS. Но принять это как желаемое положение дел – всё равно, что игнорировать течь по левому борту лодки только потому, что вы находитесь на палубе по правому борту. И наблюдаются признаки того, что сообщество PaaS готово всерьез воспользоваться данной возможностью, как показывают недавние обсуждения платформы Cloud Foundry для OpenStack.
Конечно, независимые вендоры PaaS всегда могут просто подождать, пока вендоры IaaS адаптируются под их допущения. Но делать на это ставку опрометчиво. Предположение о том, что одни методы PaaS решают все прошлые и будущие проблемы с облачными приложениями, наверно, так же надежно, как привязка к тому или иному языку программирования эпохи 90-х или к какой-нибудь другой технологической платформе от компании Seattle. Лучше вендорам PaaS засучить рукава и внести лепту в успешную реализацию уровней Solum, Murano и Heat в составе OpenStack.
На самом деле, если непрекращающиеся споры «Emacs или VI» являются каким-то показателем, то поддержка более эффективной интеграции с OpenStack даже может быть разумной стратегией среди поставщиков PaaS для гарантии того, что они не повторят судьбу Visual Basic.
Оригинал статьи на английском языке.