Windows Azure против Amazon EC2 против Google App Engine

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

Я написал одно и то же приложение для GAE (Python и теперь Java) и Azure. Я, вероятно, буду продолжать использовать оба, для разных вещей. Вот несколько мыслей, которые я буду постоянно обновлять:

Причины использовать GAE:

Я явно предвзят - я работаю в команде App Engine, поддерживаю отношения с разработчиками, но это мое мнение:

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

Azure, с другой стороны, предоставляет немного менее стесненную среду, которая позволяет вам писать более широкий набор приложений, но требует от вас писать больше - поскольку вы сами реализуете большую часть стека - и обеспечивает гораздо более слабую гарантию масштабируемости ,

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

Мой совет: если ваше приложение соответствует модели App Engine - и приложение для социальной сети, вероятно, будет хорошим примером того, что делает - напишите ваше приложение на App Engine (Java или Python, на ваш выбор). Это дешевле, и гораздо проще написать масштабируемое приложение.

Если ваше приложение не соответствует модели GAE, выберите Azure или AWS, в зависимости от того, пишете ли вы для стека MS и насколько вы хотите контролировать среду выполнения. Если большая часть вашего приложения подходит для GAE, а небольшие части - нет, вы можете рассмотреть гибрид, например, живую подачу в GAE, но хранение в S3 или массовую обработку в EC2.

Для меня решающим фактором является блокировка.

Если вы выберете Google, ваше приложение будет работать только в Google. Если вы обнаружите, что чувствуете себя не совсем довольным через некоторое время, вы застряли.

Если вы выберете MS, ваше приложение будет работать только в Azure. То же самое.

В Amazon вы получаете (а) виртуальные серверы, которые работают точно так же, как и машины, к которым вы привыкли. Не удовлетворены? Поднимите ваше приложение, установите на реальном оборудовании, готово.

• Если вы являетесь разработчиком .NET - перейдите на Azure.
• Если вы на Python или Java - зайдите в Google.
• Если вы на Ruby - зайдите в Amazon

Моим личным выбором сейчас был бы Google с Java (даже если я большую часть времени являюсь .NET). Подумайте о затратах - их схему сложно сравнить.

Проверьте эту статью - http://www.infoq.com/news/2008/11/Comparing-EC2-App-Engine-Azure

Как и паукообразный, я могу быть предвзятым, будучи гуглером. Тем не менее, я также являюсь акционером Amazon, так что предвзятость может частично компенсировать первое ;-). Нет опыта работы с Azure (хотя у меня также есть акции MSFT, поэтому я надеюсь, что они тоже преуспевают - еще один уклон ;-).

Мое простое предположение заключается в том, что App Engine легко предлагает вам возможность работать (в пределах своих ограничений) просто с помощью кодирования - никаких задач системного администрирования не требуется. AWS является гораздо более гибким, но вы будете нуждаться в существенной работы системного администрирования (и на самом деле не является тривиальной на всех) , чтобы воспользоваться этой гибкостью. Итак, в конце я бы поддержал предложение Арахнида: если App Engine может удовлетворить ваши потребности, обязательно сделайте это; если вам нужна большая гибкость, AWS кажется правильным (если только неизвестные мне возможности Azure не будут более подходящими), но я думаю, что AWS будет более гибким, независимо от того, что Azure может сделать, например, с помощью AWS. Можно даже выбрать, какую ОС использовать, если вам это нужно).

Я только начал работать с Azure и уже впечатлен, что вы можете сделать это на языке F #: http://code.msdn.microsoft.com/fsharpazure! Пока что это единственная облачная платформа, позволяющая использовать функциональное программирование управляемым способом (конечно, вы можете использовать Haskell в EC2 ... или Algol 68 в этом отношении). Я очень впечатлен качеством интеграции Visual Studio - вы получаете локальное «облако» для тестирования DevFabric с хранилищем, которое является настоящим SQL Server, поэтому вы можете играть перед загрузкой. Может ли GAE сделать это? Глядя на Azure, изучая VS с использованием F # (из Linux и OCaml), мне хотелось бы давно перейти на MS стек для этого. Создать хранилище SQL и проверить его в VS очень просто - это очень удобно. У Open Source нет подходящего набора инструментов, и настало время, чтобы люди серьезно подумали о MS - они проделали отличную работу здесь. Я, конечно, придерживаюсь своей базы Mac OSX (двойная загрузка в Vista), и я догадываюсь, с возможностью локальной разработки Azure я получу отдельную версию Vista для разработки Azure. .NET действительно ошеломляет, когда вы выходите из конвейерного мира Unix - PowerShell, SQL и LINQ, C # и F # (что является моей ключевой причиной) - но оказывается, что все это складывается и стоит учиться в дополнение к, а не вместо этого из Linux; и во всех случаях Azure расширит ваши горизонты.

Как бы я ни любил GAE, одна из основных причин, по которой я использую EC2 вместо GAE для моего текущего проекта, заключается в том, что мне нужно иметь возможность обслуживать внешний интерфейс моего приложения из центров обработки данных, расположенных в разных частях мира. GAE работает в одном дата-центре одновременно. Например, мне нужно, чтобы пользователи в Азии обращались к серверам в Азии для максимально быстрого отклика моего приложения. Добавьте к этому возможность управлять DNS, балансировщиками нагрузки, выбранной базой данных, перемещением потока данных в S3 для обработки данных Hadoop и т. Д., И EC2 становится действительно привлекательным решением.

Некоторые вещи для рассмотрения:

Быстрое освоение: как быстро вы можете работать продуктивно в выбранной среде, какие документы существуют и являются ли они понятными и хорошо поддерживаемыми образцами, очевидными и полезными

Стоимость: стоимость является одним из факторов, но если вы создаете коммерческое приложение, в котором действительно есть клиенты, это все жизнеспособный выбор. Если вы предполагаете, что Azure с одним процессом на «маленьком» экземпляре работает примерно за 90 долларов в месяц при использовании 24x7 ... Сколько пользователей вы можете обслуживать за это время? Добавьте второй экземпляр для избыточности ... все же не так уж и дорого, если ваш трафик это оправдывает. Если это не так, почему вы находитесь в облаке, а не у дешевого хостинг-провайдера? Более крупные факторы затрат приходят в ваше время для реализации этого. AWS - это ваше собственное решение. Это очень много, чтобы получить решение, которое будет стабильным и хорошо управляемым. Azure и GAE имеют это из коробки. На мой взгляд, AWS является самым дорогим из-за работы, которую вы должны выполнить. Вы действительно нуждаетесь в контроле над этим при таком уровне детализации? Если так,

Возможность делать то, что вы хотите: AWS полностью. Azure - второй, GAE - третий. Не важно, если вам нужны Java и Python. Бигги, если вы хотите сделать реляционную БД или обширную многопоточную обработку данных в C ++ (не уверен, если какой-либо из них делает это сейчас?).

Как насчет портативности? Можете ли вы потом вернуть его на свою ферму или перенести на другую облачную ферму? Все они в некоторой степени портативны.

Много думать о ... все еще учусь об этом сам.

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

Azure и EC2 - это просто виртуальные серверы с некоторыми сервисами на стороне.

Обновить:

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

GAE обрабатывает это автоматически "из коробки" и берет с вас плату только за время выполнения кода во время запросов.

Вот некоторые другие соображения.

GAE - находится на платформе в качестве стека услуг, чем AWS и Azure, весь трафик направляется через их DNS ghs.google.com, динамически загружая обслуживание вашей страницы через один из их компьютеров, что позволяет им поддерживать низкие цены. при таком подходе масштабирование детализировано, Cons не статический ip, склонен к фильтрации или блокировке. Из-за отсутствия статического IP-адреса вы не сможете настроить какой-либо специфический для сайта сертификат https.

AWS и Azure предоставляют вам практически статический IP-адрес и выделенную виртуальную машину, что позволяет выполнять такие базовые требования, как сертификат https. Вы также получите поддержку реляционного хранилища. Стоимость также выше, чтобы отразить этот факт выделенной виртуальной машины, и вы будете масштабироваться на каждую виртуальную машину, то есть на 40 долларов в месяц. Преимущество состоит в том, что, поскольку вы получаете виртуальную машину для себя, вы не ограничены 30-секундным ограничением обработки процессором в GAE и можете выполнять более крупные задачи.

Так что, если вы рассматриваете клиентские базы в отфильтрованных странах, или хотите, чтобы статический IP-адрес выполнял ваши собственные настройки DNS, или у вас есть требования, которые требуют реляционных дБ или задач длительностью более 30 секунд. AWS, с Azure было бы гораздо дружелюбнее работать.

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

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

У меня есть проект социальной сети, который требует базы данных nosql. AppEngine был бы хорошим решением, если бы он лучше поддерживал различные фреймворки. Django с nonrel адаптером работает на Python GAE, но я предпочитаю Rails по многим причинам. Rails3 был выпущен в течение нескольких месяцев, и никто из сообщества или команды GAE еще не написал рецепт для его поддержки. Если у вас нет набора навыков - знание внутренних элементов ruby ​​и rails, jruby и GAE - для написания собственного рецепта, вы зависите от других людей, просто чтобы попасть на платформу.

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

Моя жалоба на Heroku и EngineYard для разработчиков на Ruby является загадкой того, как масштабируются базы данных. Как они масштабируются?

В моем случае я выбираю NoSQL-решение, и Mongo кажется хорошим выбором. MongoMachine, кажется, является рекомендуемым решением для подобных Heroku или EY, но это безумно дорого. $ 2,50 / ГБ памяти? Хранение составляет всего $ 0,10 ГБ / мес на GAE или EBS.

Я начал экспериментировать с Google App Engine сравнительно недавно, и я считаю, что для веб-социальной сети он удовлетворит все ваши потребности. Его легко освоить, и его можно использовать как с Python, так и с Java. Это правда, что он не дает вам доступа к файлам, но для вашего приложения GQL (SQL-подобный интерфейс к предоставляемой ими базе данных), вероятно, будет более чем достаточно (и он достаточно надежен).

Одна вещь, которую вы, возможно, захотите рассмотреть, это то, что приложение в GAE может использовать интерфейс, который позволит пользователям с учетными записями Google или учетным записям в домене, используя Google Apps, войти в систему (ярлык). Вы выбираете любой из них. Поэтому, если вы уже используете веб-сайт Служб Google, Google App Engine станет для вас отличным выбором, поскольку вашим пользователям не придется регистрировать новые учетные записи.

РЕДАКТИРОВАТЬ: Как указал Арахнид, это не значит, что вы не можете кодировать свою собственную систему входа в систему. Извините, если я вас беспокою.

Что касается двух других альтернатив, я только прочитал о них и не проверял их. Но я полагаю, что GAE предоставляет более простую структуру, исходя из моих исследований, и, как вы упомянули, отличные цены.

В любом случае вы можете попробовать GAE, используя бесплатную квоту на пространство и пропускную способность, и посмотреть, соответствует ли она вашим потребностям.

Удачи.

Azure использует Windows / SQL в качестве сервера «Платформа как служба», и вы определенно НЕ застряли, просто вернитесь к Windows / SQL в своем собственном центре данных (нет Linux, но да, они поддерживают Java, Python, PHP, Ruby, Tomcat , Apache и др.). Как и Amazon, они также будут предоставлять полностью доступную опцию Virtual Machine, так что вы сможете установить / запустить все, что захотите.

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

У Google нет реляционной базы данных, и вы будете в восторге. Они действительно предназначены только для разработчиков Python и имеют ограниченную поддержку Java. Они действительно не игрок в облачном пространстве, по моему мнению.

Одна вещь, не упомянутая здесь, это то, что кто-то считает «служебной шиной Windows Azure AppFabric & ACS» помимо ужасного имени ...?

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

После экспериментов с Amazon EC2 и некоторых задержек я начал исследовать Google Apps, проводя эксперименты из-за высокой стоимости. Я бы предпочел Erlang в качестве языка разработки, но он может работать с Python, так что это не было решающим фактором. Когда я не видел статического IP, это было. Кроме того, все, что связано с тем, что я выше в стеке, заставляет меня немного нервничать по поводу производительности.

Хотелось бы, чтобы AWS был дешевле, но пока Google не предоставит статические IP-адреса и, желательно, дополнительные языки, такие как Scala, JRuby и Erlang, выбор для меня очевиден : AWS . Первые два языка тоже должны быть простыми, они оба основаны на JVM. Может быть, даже было сделано уже через обходные пути, так как я, кажется, помню, что-то читал об этом.

Ребята, я думаю, кроме того, что я думаю только о том, какую платформу он поддерживает, сравнение должно быть по масштабируемости, простоте доступа, универсальности (с точки зрения реализации), может работать с разными хостинговыми платформами, одинаково экономически жизнеспособными для бизнес-кейса, имеет несколько решений для предприятия приложений (то есть хранилища, доставки, пропускной способности, политики лицензирования и т. д.), отслеживания достоверности качества обслуживания, аудита безопасности, прозрачности в выставлении счетов, а также затрат и т. д. Если вы посмотрите на все вышеупомянутые показатели, я чувствую, что оценки AWS намного выше , Я управляю 10 производственными учетными записями в AWS, начиная с 2 лет, и в то же время компания / бизнес-единица смогли удовлетворить огромные требования клиента к масштабируемости .... Без сомнения, в AWS необходимо поддерживать инфраструктуру, Обновления (если есть / если требуется), безопасность и т. д. Но у вас есть все инструменты, доступные на рынке / сети свободно. Существующие ИТ-ресурсы также могут поддерживать всю инфраструктуру в AWS.

Azure наверняка имеет интегрированную IDE с VS 2010, но фактическая стоимость любого облака начнется после успешного развертывания приложения (платформы для развертывания). Еще предстоит пройти долгий путь для решения сценариев развертывания в реальном времени / масштабируемого производства ....... Как все знают, MS играет много скрытых задач по затратам ... очень трудно определить расходы, понесенные или собирающиеся понести (при отправке оценки).

GAE очень специфичен для приложений Python / Java. Огромные усилия (как с точки зрения ресурса, так и стоимости) в получении приложения, переписанного (существующего), протестированного, развернутого и т. Д.