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

159

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


источник
2
Недавно я сравнивал то же самое - опубликовал свои плюсы и минусы в своем блоге. Azure отсутствует (в зависимости от стоимости небольшого проекта), но EC2 и Google App Engine являются сильными соперниками! blog.dantup.com/2010/10/…
Дэнни Таппени
2
Этот вопрос должен быть вики сообщества.
стеллажи
Грег

Ответы:

227

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

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

  • По сути, вы получаете одну бесплатную виртуальную машину в день. С Azure вы платите почти 100 долларов в месяц, даже если у вас нет ни одного посетителя сайта. Если ваша база данных превышает 1 ГБ, вы платите дополнительные $ 90 ($ 9 -> $ 99) за хранение. Обновление: теперь Azure имеет различные размеры виртуальных машин и баз данных в разных ценовых категориях. Подробности здесь .
  • Оплата GAE достаточно тонкая - большинство ресурсов оплачивается за запрос / ГБ / МБ, опять же с бесплатным ежедневным распределением для большинства ресурсов. Однако в ноябре 2011 года она присоединилась к Azure и AWS для начисления платы за веб-сервер за час работы. Подробности здесь .
  • GAE имеет самую легкую нагрузку администратора. После настройки развертывание и повторное развертывание происходит быстро, и все автоматически. Например, вы не беспокоитесь о том, сколько серверов использует ваше приложение, как защитить данные, как распределить нагрузку.
  • Почта просто работает. На момент написания Azure не предлагал SMTP, поэтому вам нужен сторонний сервер.
  • Отличная интеграция со многими предложениями Google - календари, почта, что угодно. Вы можете делегировать управление пользователями в Google, если не хотите контролировать свою пользовательскую базу.
  • С GAE вы знаете все функции, которые они добавляют в магазин, вы получите. С Azure вы почувствуете, что база данных Sql Azure получит большую часть любви, но это будет дороже. Хранилище Azure, вероятно, будет иметь наибольшее количество ошибок. Никакой целостности отношений, никакого упорядочения, вы больше будете возиться с контекстом в памяти. Магазин GAE имеет гораздо меньше ограничений и больше функций, чем таблицы Azure.
  • Хороший выбор, если вы уже используете языки Python или JVM. В настоящее время многие языки компилируются в байт-код Java.
  • Обновление приложения происходит очень быстро. Для Python у меня была настройка сочетаний клавиш, и это совсем не заняло времени. Сейчас я использую Eclipse Plugin для Java, и он работает очень хорошо. Лазурь более нервный.
  • Локально протестированное приложение, вероятно, будет работать в облаке без (больших или каких-либо) изменений. В Azure конфигурация отличается, и я потратил некоторое время, чтобы остановить удаление-сборку-загрузку-запуск, прежде чем понял все правильно.
  • GAE имеет отличный пользовательский интерфейс, который включает в себя просмотр журнала и редактор данных. В Azure вам в настоящее время приходится искать внешних зрителей / редакторов для этого.
  • GAE позволяет вам иметь несколько версий вашего приложения, работающих в одном хранилище данных. Вы можете развернуть, протестировать версию и затем установить текущую «живую» версию, когда будете готовы. Вы можете вернуться обратно, если что-то пойдет не так.


    Причины использования Azure:

  • Характеристики производительности и стоимость хранилища данных App Engine удивят вас. Если вы делаете что-то кроме простого CRUD, вам нужно работать усерднее, чем с обычной БД. Нет специальных запросов.
  • Azure имеет два подхода к хранилищу, предлагая больший выбор. Это база данных SQL Azure (SAD), которая является реляционной базой данных, и хранилище Azure, которое состоит из нереляционных таблиц, больших двоичных объектов и очередей. Если у вас есть инвестиции в SQL Server, то к SAD будет легко перейти, но это довольно дорого и может быть менее масштабируемым. Обновление: App Engine имеет MySQL API в ограниченной бета-версии.
  • Azure, кажется, лучше спроектирован, если у вас есть подход типа SOA. Их архитектура, кажется, извлекает выгоду из опыта в корпоративном мире. GAE кажется более сосредоточенным на простом обслуживании веб-страниц.
  • Вы можете запустить приложение в режиме отладки, установить точки останова и т. Д.
  • В Azure есть «промежуточная» среда, в которой вы можете развернуть ее в облаке, но не запускать ее до тех пор, пока вы не будете довольны ее работой.
  • Я использую .Net для других целей, и интегрировать их с .Net на серверной стороне гораздо проще, чем с GAE. (Обновление - использование Java в GAE работает нормально, а 10-секундный таймаут теперь составляет 30 секунд).
  • Интеграция со многими предложениями MS "Live".

    Итак, нет очевидных ответов. На данный момент я по умолчанию использую App Engine из-за затрат и простоты использования. Я мог бы использовать Azure для очень ориентированных на MS приложений. Я использую Amazon S3 для загрузки, но, скорее всего, не буду использовать EC2, потому что я предпочитаю оставлять все на уровне приложений экспертам.

  • Ричард Уотсон
    источник
    10
    Ричард, может быть, еще один плюс для Azure - наличие реляционной базы данных. Осколки Bigtable - это несколько иностранная парадигма.
    Hyperlug
    22
    App Engine также позволяет создавать несколько версий вашего приложения. Каждая версия получает свой собственный URL, который вы можете проверить, и когда вы будете готовы к развертыванию, просто пометьте эту версию как версию по умолчанию. Легко тестировать, развертывать и, если необходимо, откатиться до предыдущей версии, если что-то пойдет не так.
    Azure платит, когда вы идете без каких-либо обязательств, только на использование, это не минимум 99 долларов в месяц.
    Акаш Кава
    1
    На microsoft.com/windowsazure/pricing говорится о SQL Azure: «* Web Edition: до 1 ГБ реляционной базы данных = 9,99 долл. США / месяц * Business Edition: до 10 ГБ реляционной базы данных = 99,99 долл. США / месяц * Передача данных = 0,10 долл. США в / 0,15 долл. США / ГБ - (0,30 долл. США / 0,45 долл. США / ГБ в Азии) "
    Ричард Уотсон
    1
    У App Engine теперь есть поддержка SQL для поддержки Block Storage. code.google.com/apis/sql
    devnul3
    176

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

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

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

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

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

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

    Ник Джонсон
    источник
    А как насчет таких вопросов: когда App Engine не работает ?
    Кристиан Чиупиту
    @Cristian Я не уверен, что ты хочешь услышать - у любой службы время от времени простои. Это включает в себя как App Engine и EC2.
    Ник Джонсон
    @ Ник Джонсон: вы правы, у любой службы время от времени простоя, и я не ожидаю 100% безотказной работы. С другой стороны, эта проблема не похожа на проблему простоя. Для меня это выглядит как ограничение Google App Engine, т. Е. Ваш код должен выполняться довольно ограниченное количество времени. Я не знаком с GAE, поэтому, пожалуйста, поправьте меня, если я что-то неправильно понимаю.
    Кристиан Чупиту
    1
    @ Кристиан Ах. Само исключение выдается из-за слишком большого количества времени, затрачиваемого на выполнение, да, но причиной замедления стали некоторые временные проблемы с производительностью.
    Ник Джонсон
    Я согласен на "они не сопоставимы". Сравнение этих услуг похоже на сравнение яблок и апельсинов. Оба фруктовые, вот и все.
    до
    27

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

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

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

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


    источник
    3
    GAE может запускать довольно стандартные приложения Java-сервлетов и может использовать постоянство на основе стандартов.
    Стивен Денн
    4
    GAE полностью открыт (хотя вам нужно придерживаться использования API хранилища JDO.)
    1
    Ограничивает ли Google объем данных, которые вы можете получать за раз? Их блокировка основана на данных больше, чем код.
    Марк Рэнсом
    4
    Вы можете использовать AppScale для запуска своих приложений в EC2 или в любом другом месте: appscale.cs.ucsb.edu
    Амир,
    3
    Наткнулся сегодня на это, кто-то смог отключиться от Google через неделю. Они также признают, что это могло бы занять месяцы, если бы они не использовали передовой опыт с самого начала. carlosble.com/?p=719
    Марк Рэнсом
    20
    • Если вы являетесь разработчиком .NET - перейдите на Azure.
    • Если вы на Python или Java - зайдите в Google.
    • Если вы на Ruby - зайдите в Amazon

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

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


    источник
    8
    Не все разработчики .NET должны переходить на Azure. Amazon EC2 - вполне приемлемый вариант для них. Но +1 за ссылку на отличную статью.
    Эндрю Арнотт
    Да, Amazon - это в некоторой степени свобода виртуальной машины, но изначально сообщество, в основном, ориентированное на Ruby ...
    1
    AWS поддерживает разработчиков .Net на своих Windows 2003 Server AMI, но я подозреваю, что многие разработчики .Net предпочитают развертывать на Windows Server 2008, который еще не реализован на AWS. Если вы регулярно посещаете форумы AWS, возможно, вы заметили, что Amazon немного спокоен в этом вопросе.
    Ричард Дорман
    2
    По профессии я .NET-разработчик, но цена использования Azure для веб-сайта, получающего 0 посещений, отразилась на моем пути Google. Я написал несколько сравнений в своем блоге: blog.dantup.com/2009/12/… blog.dantup.com/2009/12/…
    Дэнни Таппени
    4
    Если вы используете Ruby, рассмотрите Heroku или EngineYard вместо Amazon.
    andy318
    20

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

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

    Алекс Мартелли
    источник
    14

    Я только начал работать с 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 расширит ваши горизонты.


    источник
    2
    В Azure нет чего-то, что даже отдаленно соответствует функциональности Amazon Elastic Map Reduce (на основе Open Source Hadoop). Это даже не позволяет устанавливать количество рабочих ролей программно.
    3
    Microsoft явно пытается монетизировать свою базу разработчиков .NET, и это правда, что есть преимущество в использовании стека Microsoft. Я не уверен, что это одно компенсирует дорогостоящую модель с блочными затратами. Весь смысл облачных вычислений заключается в том, что Azure пока не предлагает гибкости в плане оплаты по факту.
    Вы можете использовать Clojure в GAE. the-deadline.appspot.com/login
    8

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

    Джон Стивенс
    источник
    5

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

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

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

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

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

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

    Spanky
    источник
    TyphoonAE и AppScale - отличные инструменты для запуска приложений GAE в других местах.
    4

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

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

    Обновить:

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

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

    Питер Кнего
    источник
    1
    Я думаю, что Amazon CloudWatch решает проблему запуска дополнительных экземпляров на основе трафика.
    1
    Одна из самых распространенных демонстраций, которые я видел для Azure, - это демонстрация масштабируемости, где они пишут некоторый код для установки пороговых значений для увеличения или уменьшения скорости работы веб-работников в зависимости от нагрузки. его можно найти в комплекте для обучения Azuer для Windows: microsoft.com/downloads/en/…
    4

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

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

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

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

    savagepanda
    источник
    3

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


    источник
    3

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

    У меня есть проект социальной сети, который требует базы данных 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.


    источник
    1

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

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

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

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

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

    Удачи.


    источник
    Nitpick: GQL не является базой данных. GQL - это SQL-подобный язык запросов для среды выполнения Python, написанный поверх хранилища данных. Вам даже не нужно его использовать - есть еще и Query API.
    Ник Джонсон
    Кроме того, вы можете войти в систему любым пользователям в приложении GAE - просто GAE предоставляет ярлык для использования учетных записей Google.
    Ник Джонсон
    Правильно, плохой выбор слов в обоих случаях, спасибо за указание на это.
    BigTable - это механизм хранения данных Google, и, потратив некоторое время на него, я начал задумываться, не потратил ли я всю свою карьеру на мысли о том, что СУБД SQL необходимы для написания веб-приложений. Модель хранения BigTable является простой, гибкой, производительной и масштабируемой, и работает на удивление хорошо.
    1

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

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

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


    источник
    4
    Джефф - обучив партнеров Microsoft по SQL Server 2008, я определенно люблю и знаком с преимуществами стека Windows / SQL, но мне трудно согласиться с тем, что один из них связан с Google BigTable. Есть полдюжины или около того хороших библиотек, которые обертывают API BigTable, выставляя его как все от СУБД psuedo до индексируемого хранилища документов. BigTable был спроектирован с нуля для масштабирования на многих серверах (Google обнаружил, что пятно пота было 1500 на кластер), что является подвигом, который SQL просто не может сделать хорошо.
    1

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

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

    Doobi
    источник
    Да, но с другой стороны, Microsoft официально сказала «Нет» локальному хостингу Azure для бизнеса, что умаляет привлекательность шины.
    1
    Хотя это и верно для названия, на практике это не так, Microsoft предлагает очень привлекательный стек для частного облака с Hyper-V (который бесплатен) и такими вещами, как Systems Center и InTune, но это не «Azure». Если вы хотите, чтобы в скором времени появился вариант «Устройства Azure» для сторонних разработчиков, вы должны быть достаточно крупными, чтобы оправдать эти расходы. Я слышал, что вам нужно поддерживать как минимум около 1000 узлов, так что это больше для владельцев центров обработки данных.
    0

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

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


    источник
    Чтобы быть педантичным, вы можете запустить Scala, JRuby и даже Clojure на App Engine, так как все это JVM под капотом. Теперь, легко ли использовать эти языки, это другая история ...
    Крис Смит
    0

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

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

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


    источник