@mister_fog11 дек 2011 в 16:03

RedHat CEO: не попадитесь в «облачный» Vendor Lock-in

5 мин

3.1K

Облачные вычисления *

Перевод

+27

Комментарии 17

@stepio 11 дек 2011 в 16:33

А Google App Engine поддерживается?

@mechmind 11 дек 2011 в 16:58

AppEngine немного из другой оперы — Google предоставляет готовую платформу, с которой вы взаимодействуете на уровне приложения (PaaS). В отличие от нее, «облачная» инфраструктура (IaaS) предоставляет пользователю инструменты для управления «низкоуровневыми» ресурсами, такими как количество виртуальных машин, количество выделенной им памяти, диска, ядер итд. Что работает внутри этих машин, платформу не интересует.

@mister_fog 12 дек 2011 в 07:59

AppEngine немного из другой оперы

Тут дело не в конкретной реализации (deltacloud), а в самой идее — насколько беспрепятственен перенос между различными реализациями облаков? Утверждать не берусь, но я слышал, что в AppEngine приложения «прибиты гвоздями» и использовать их вне «экосистемы» google невозможно.

@orcy 12 дек 2011 в 15:37

Слово «облако» — это маркетинг, технически под этим может несколько разных подходов (вроде PaaS, SaaS, IaaS). То что описано в статье больше похоже на унификацию работы с IaaS (чем gae не является), так что в рамках подхода из статьи никто не обещает что ваши приложения Salesforce будут работать на GAE и обратно.

@mister_fog 13 дек 2011 в 07:07

Есть общая идея Red Hat о том, что необходима «переносимость» в облачных вычислениях. На всех уровнях. В SaaS — чтобы мы могли забрать свои данные и переместить их в другое SaaS-приложение или использовать с обычным софтом. В PaaS — чтобы мы могли взять приложение и переместить его из одного PaaS в другое или на личный сервер. В IaaS — чтобы мы могли сформированные виртуальные образы переместить от одного хостера к другому или в свой ЦОД.

И есть Deltacloud — работающий код, созданный для того, чтобы показать, что у Red Hat есть не только красивые слова, но и реальные действия в плане воплощения этих слов в жизнь. Да, он не идеален, да, он работает не везде и не со всем, но это в первую очередь, демонстрация возможностей. На данный момент в облачных вычислениях слишком мало стандартизации, поэтому предстоит много работы, но её нужно делать.

@mister_fog 12 дек 2011 в 07:29

А Google App Engine поддерживается?

Deltacloud это открытый проект Apache, соответственно, взять его и встроить в своё облако может каждый желающий, но не наоборот — у разработчиков Deltacloud нет возможности «влезть» в чужие облака. Поэтому, правильнее спросить: «А поддерживает ли Google App Engine Deltacloud API или что-нибудь похожее?». И спросить это нужно у Google. Сможете ли вы, не внося изменений, переместить свои приложения и данные из App Engine в, например, Rackspace cloud?

@mechmind 11 дек 2011 в 17:03

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

@mechmind 11 дек 2011 в 17:08

Как пример — OpenStack позволяет дать виртуалке несколько сетевых интерфейсов, в то время как Eucalyptus — нет. OpenStack поддерживает api-клиент Eucalyptus'а, который в свою очередь похож на api-клиент Амазона. Можно достаточно просто обернуть все три платформы амазоноподобным api, вот только дополнительные интерфейсы из OpenStack'а это api видеть не будет.

@stepio 11 дек 2011 в 18:09

А эта «надстройка» оставляет возможность таких себе «системных вызовов»? Т.е. чтобы основной функционал через единое API + доступ к платформозависимому (для исключительных случаев). Это бы помогло, как по мне.

@mister_fog 12 дек 2011 в 09:13

как только появляются конкурирующие продукты, решающие одну и ту же задачу

Стоп-стоп-стоп, облачные вычисления — не просто продукт, а платформа для различных продуктов, поэтому их стандартизация — очень важный вопрос. Вот например, если взять мобильные платформы — разве не круто было бы писать приложения, которые работали бы на всех смартфонах, вне зависимости от производителя и ОС? Когда речь идёт о таких вещах, как системное ПО, стандарты, на мой взгляд, должны быть важнее, чем «вкусные» особенности.

@tranquil 11 дек 2011 в 18:41

Vendor lock-in является одной из причин крупных расходов в IT-отделах, говорит Уайтхерст.

Продавцы ~~воздуха~~ ПО и руководство IT-отделов одобряют.

@mister_fog 13 дек 2011 в 07:17

Это вы к чему сказали? Не очень понятно. O_o

@tranquil 11 дек 2011 в 18:45

По теме, redhat ещё не довёл до продакшена свободную реализацию rhev (ovirt).

Учитывая качесивр свободного облачного ПО, например, Openstack, делать свободные облака RH будет ещё очень и очень долго.

@tranquil 11 дек 2011 в 18:46

*качество

@Xobb 11 дек 2011 в 21:41

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

@zone1508 12 дек 2011 в 08:08

Помоему он немного опоздал. Есть уже куча проприетарных и открытых платформ. Более того есть уже и агрегаторы умеющие управлять виртуализацией от различных вендоров например тот же SCVMM майкрософтовский.

@mister_fog 12 дек 2011 в 08:20

Тут речь идёт не столько об управлении, сколько о переносе приложений и данных. И тут как раз с майкрософтовской платформой самый большой вопрос — ведь поддержка Java и PHP есть почти во всех cloud, а вот чтобы заставить работать приложения, написанные на C#, где-нибудь, кроме платформы MS… ;-) Это и есть vendor lock-in в чистом виде.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий