Когда следует использовать следующее: 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 Движок или Azure на EC2?
Google App Engine: у вас нет контроля над оборудованием и ОС, и вы получаете конкретную структуру разработки для создания своего приложения. Можете ли вы взять любое существующее приложение Java или Python и перенести его в GAE? Или наоборот, могут ли приложения, построенные на GAE, быть удалены из GAE и перенесены на любой сервер приложений, например Websphere или Weblogic?
Azure: у вас нет контроля над оборудованием и ОС, и вы получаете определенную платформу разработки для сборки ваше приложение. Вы можете взять любое существующее приложение .NET и перенести его в Azure? Или наоборот, могут ли приложения, построенные на Azure, быть удалены из Azure и перенесены на любой сервер приложений, например Biztalk?
7 ответов:
хороший вопрос! Как вы указываете, различные предложения вписываются в разные категории:
EC2-это инфраструктура как сервис; вы получаете экземпляры VM и делаете с ними все, что хотите. Облачные серверы Rackspace более или менее одинаковы.
Azure, App Engine и Salesforce являются платформой как Служба; они предлагают различные уровни интеграции, хотя: Azure в значительной степени позволяет запускать произвольные фоновые службы, в то время как App Engine ориентирован на недолговечность задачи обработчика запросов (хотя он также поддерживает очередь задач и запланированные задачи). Я не очень хорошо знаком с предложением Salesforce, но я понимаю, что он похож на App Engine в некоторых отношениях, хотя и более специализирован для своей конкретной ниши.
облачные предложения, которые подпадают под программное обеспечение в качестве услуги, - это все, начиная от инфраструктурных частей, таких как простой сервис хранения Amazon и SimpleDB, до полных приложений, таких как Fog Creek, размещенный FogBugz и, конечно конечно, StackExchange.
хорошее общее правило заключается в том, что чем выше уровень предложения, тем меньше работы вам придется делать, но тем более конкретным он является. Если вам нужен трекер ошибок, использование FogBugz, очевидно, будет наименьшей работой; создание одного поверх App Engine или Azure-это больше работы, но обеспечивает большую универсальность, в то время как создание одного поверх необработанных виртуальных машин, таких как EC2, еще больше работы (на самом деле намного больше), но обеспечивает еще большую универсальность. Мой общий совет-выбрать высшего уровня, который удовлетворяет вашим требованиям, и построить оттуда.
Это хороший вопрос. Полное раскрытие, поскольку я частично отношусь к Azure, но имею опыт работы с другими.
где я думаю, что Azure выделяется из других-это быстрый переход от on prem к облаку. Например -
- SQL Azure-изменить строку подключения, загрузить БД, go!
- очереди работают так же, как MSMQ.
- капли-это в значительной степени капли, как вы их встряхиваете, но они масштабируются как сумасшедшие.
- в компонент хранения таблиц хорош тем, что он обеспечивает невероятную масштабируемость для пар имя/значение - но требует некоторого привыкания.
- служебная Шина является моим любимым из услуг, потому что она позволяет использовать различные коммуникационные парадигмы. Две конечные точки SB сначала пытаются подключиться друг к другу, если они не могут, то они проходят через облако - делает для очень безопасной и масштабируемой обработки, когда брандмауэры, как правило, мешают.
- список управления доступом-спаренный типично с помощью служебной шины, чтобы убедиться, что правильные люди получают доступ к правильным вещам-подумайте SAML в облаке.
Я надеюсь, что помогает!
мой облачный опыт в настоящее время ограничен Salesforce.com
для стандартных бизнес-операций и автоматизации он предоставляет значительное количество функций, которые позволяют нам получить приложения и работает очень быстро. Мы особенно выигрываем от следующего:
- Безопасность (Администраторы могут контролировать доступ к объектам и полям)
- Рабочий Процесс И Утверждения
- автоматическое создание пользовательского интерфейса
- встроенный в отчетности и приборные панели
- вся система (включая наши пользовательские изменения) доступна через веб-службы
- возможность сделать данные в системе доступными через общедоступные сайты (например, электронная торговля)
- большая библиотека сторонних приложений для решения стандартных задач
платформа не решает все проблемы.
Я бы не стал использовать платформу для моделирования атомной электростанции или построить следующий твиттере.
основные моменты облачных вычислений-это экономия на затратах за счет оплаты использования и немедленного развертывания вычислительных ресурсов.
затраты не являются чисто x количество центов за экземпляр в час. В стоимость входит техническое обслуживание, разработка, администрирование и т. д. Огромное преимущество облака, на мой взгляд, чтобы освободить клиентов от необходимости управлять чем-либо, что не входит в сферу их основной бизнес-компетенции. Если я являюсь страховкой бизнес, я хочу, чтобы мои разработчики сосредоточились на моих страховых проблемах, которые помогают решить потребности моих претензий, ставок и т. д. Я бы предпочел избежать проблем с почтовыми серверами, файловыми серверами, хранилищами документов и администрированием исправлений ОС, пакетов обновления и т. д.
таким образом, на мой взгляд, наибольшие выгоды извлекаются из облачных предложений SaaS и PaaS. Следует переходить на IaaS только тогда, когда PaaS или SaaS имеют серьезные ограничения на конкретные потребности (т. е. мне нужно установить набор собственных компонентов COM и Azure не поддерживает их).
SaaS хорош для товарных типов приложений, которые не являются основным направлением бизнеса для клиента, но являются более полезными. Это ваши типичные системы обмена сообщениями, порталы, хранилища документов, системы электронной почты, CRMs, ERP, Бухгалтерия и т. д. так далее. так далее. Зачем изобретать колесо, написав свой собственный, когда вы можете настроить хорошо поддерживаемый сторонний продукт.
Чук отлично подходит для основной линии бизнес-программное обеспечение, которое поддерживает основные бизнес-предложения компаний. Абстрагирует клиентов от необходимости иметь дело с управлением ОС и позволяет клиентам сосредоточиться на развитии бизнес - системы-то, что никто другой не может сделать для клиента.
можно также воспользоваться преимуществами PaaS (скажем, Google App Engine) и расширить его, время от времени и при необходимости, вытаскивая некоторые виртуальные машины из поставщиков IaaS (например, Amazon), чтобы сделать некоторое количество хруста, а затем просто отправить обратно вывод в Google App Engine.
таким образом, вы получаете лучшее из обоих миров-вы можете быстро разрабатывать масштабируемые приложения в GAE, а затем вы всегда можете увеличить его, запустив любую программу, которую вы хотите от виртуальных машин Amazon.
Это продолжает меняться, теперь Windows Azure также поддерживает виртуальную машину, так что теперь это также поставщик IaaS.
теперь как насчет бесплатного Amazon EC2 в течение года, чтобы сделать лучшее сравнение. Проверить это.
http://www.buzzingup.com/2010/10/amazon-announces-free-cloud-services-for-new-developers/