Когда следует использовать следующее: Amazon EC2, Google App Engine, Microsoft Azure и Salesforce.com?

Я прошу об этом в очень общем смысле. Как от облачного провайдера, так и от облачного потребителя. Кроме того, вопрос заключается не в каком-либо конкретном виде приложения (на самом деле, намерение состоит в том, чтобы знать, какой тип приложений/доменов может вписываться в какой из облачных панелей -SaaS PaaS IaaS).

До сих пор я понимаю:

IaaS: аппаратное обеспечение (процессоры, сети, хранилище).

PaaS: ОС, системное программное обеспечение, платформа разработки, виртуальные машины.

SaaS: программные приложения.

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

EDIT: Хорошо, я расскажу более конкретно -

Amazon EC2: у вас нет контроля над аппаратным слоем. Но вы можете выбрать свой образ ОС, Dev Framework (.NET, J2EE, LAMP) и приложение и разместить его на оборудовании EC2. Можете ли вы развернуть приложения, созданные с помощью Google App Engine или Azure на EC2?

Google App Engine: у вас нет контроля над оборудованием и ОС, и вы получаете конкретную Dev Framework для создания своего приложения. Можете ли вы взять любое существующее приложение Java или Python и перенести его на GAE? Или наоборот, могут ли приложения, построенные на GAE, извлекаться из GAE и переноситься на любой сервер приложений, такой как Websphere или Weblogic?

Azure: у вас нет контроля над оборудованием и ОС, и вы получаете конкретную Dev Framework для создания своего приложения. Можете ли вы взять любое существующее приложение .NET и перенести его в Azure? Или наоборот, могут ли приложения, которые были построены на Azure, вывезены из Azure и перенесены на любой сервер приложений, такой как Biztalk?

Ответы

Ответ 1

Хороший вопрос! Как вы отмечаете, различные предложения подходят для разных категорий:

EC2 - это инфраструктура как услуга; вы получаете экземпляры виртуальных машин и выполняете их по своему усмотрению. Облачные серверы Rackspace более или менее одинаковы.

Azure, App Engine и Salesforce - это платформа как услуга; однако они предлагают различные уровни интеграции: Azure в значительной степени позволяет запускать произвольные фоновые службы, а App Engine ориентирован на краткосрочные задачи обработчика запросов (хотя он также поддерживает очередь задач и запланированные задачи). Я не очень хорошо знаком с предложением Salesforce, но я понимаю, что он похож на App Engine в некоторых отношениях, хотя и более специализирован для своей конкретной ниши.

Облачные предложения, которые попадают под Программное обеспечение как услугу, - это все, от объектов инфраструктуры, таких как Amazon Simple Storage Service и SimpleDB, для завершения таких приложений, как Fog Creek, размещенных FogBugz и, конечно же, StackExchange.

Хорошим общим правилом является то, что чем выше уровень предложения, тем меньше работы вам придется делать, но тем более конкретным. Если вы хотите отслеживать ошибку, использование FogBugz, очевидно, будет наименьшей работой; построение одного поверх App Engine или Azure - это больше работы, но обеспечивает большую универсальность, а построение одного поверх необработанных виртуальных машин, таких как EC2, - это еще большая работа (на самом деле гораздо больше), но обеспечивает еще большую гибкость. Мой общий совет - выбрать платформу самого высокого уровня, которая по-прежнему соответствует вашим требованиям, и строить там.

Ответ 2

Это отличный вопрос. Полное раскрытие, поскольку я частично отношусь к Azure, но имею опыт с другими.

Где я думаю, что Лазур выделяется среди других, это быстрый переход от премьера к облаку. Например -

  • SQL Azure - изменить строку подключения, загрузить DB, перейти!
  • Очереди работают так же, как MSMQ.
  • Blobs - это в значительной степени капли, как бы вы их трясли, но они масштабируются как сумасшедшие.
  • Компонент хранения таблиц хорош, поскольку он обеспечивает невероятную масштабируемость для пар имя/значение - но требует некоторого привыкания.
  • Сервисная шина - моя любимая услуга, потому что она позволяет использовать различные парадигмы связи. Две конечные точки SB сначала пытаются подключиться друг к другу, если они не могут, затем они маршрутизируют через облако - делает для очень безопасной и масштабируемой обработки, когда брандмауэры, как правило, мешают.
  • Список контроля доступа - как правило, со служебной шиной, чтобы убедиться, что нужные люди имеют доступ к правильным вещам - подумайте о SAML в облаке.

Я надеюсь, что это поможет!

Ответ 3

В настоящее время мой облачный опыт ограничен Salesforce.com

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

  • Безопасность (администраторы могут контролировать доступ к объектам и полям)
  • Рабочий процесс и одобрения
  • Автоматическое создание пользовательского интерфейса
  • Встроенный отчет и панели мониторинга
  • Вся система (включая наши пользовательские изменения) доступна через веб-службы
  • Возможность сделать данные в системе доступными через общедоступные сайты (например, eCommerce)
  • Большая библиотека сторонних приложений для решения стандартных проблем

Платформа НЕ решает каждую проблему.

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

Ответ 4

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

Затраты - это не чисто х центов за экземпляр в час. Расходы включают в себя обслуживание, разработку, администрирование и т.д. Огромное преимущество облака, на мой взгляд, заключается в том, чтобы освободить клиентов от необходимости управлять всем, что не входит в сферу компетенции их основной деятельности. Если я являюсь страховым бизнесом, я хочу, чтобы мои разработчики сосредоточились на моих проблемах со страхованием, которые помогли решить потребности моих требований, ставок и т.д. Я бы предпочел избежать проблем с почтовыми серверами, файловыми серверами, репозиториями документов и администрированием патчей ОС, пакеты обновления и т.д.

Таким образом, на мой взгляд, самые большие выгоды получаются из предложений SaaS и PaaS. Нужно идти в IaaS только тогда, когда PaaS или SaaS имеют серьезные ограничения на конкретные потребности (т.е. Мне нужно установить набор собственных COM-компонентов, а Azure их не поддерживает).

SaaS хорош для товарного типа приложений, которые не являются основной сферой деятельности для клиента, но являются более полезными. Это типичные системы обмена сообщениями, порталы, репозитории документов, системы электронной почты, CRM, ERP, учет и т.д. И т.д. И т.д. Зачем изобретать колесо, написав свой собственный, когда вы можете настроить хорошо поддерживаемый сторонний продукт.

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

Ответ 5

Можно также воспользоваться преимуществами PaaS (скажем, Google App Engine) и продлить его, время от времени и, если необходимо, вытащить некоторые виртуальные машины из провайдеров IaaS (например, Amazon), чтобы сделать некоторое количество хрустов, затем просто отправьте обратно в Google App Engine.

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

Ответ 6

Это продолжает меняться, теперь Windows Azure также поддерживает VM, поэтому он также является поставщиком IaaS.