Используете ли Вы услуги Amazons Cloud для своей компании?

Я настроил два экземпляра своего приложения на EC2 и использовал S3 в качестве резервного копирования local-to-AWS и доставки активов media. В середине июня мы перенесли около 15% наших приложений контента/трафика на EC2. Результат неоднозначен, и мы перемещаем экземпляр content heavy usage обратно в наш размещенный центр обработки данных, а теперь изучаем другие варианты доставки контента.

Отметим, что:

1. Мое приложение голодно по пропускной способности (начиная со 100 Мбит / с на экземпляр)
2. Моя компания и я находимся в Швейцарии, и это, безусловно, оказало влияние на нашу оценку.
3. Я определяю пропускную способность как скорость потока (Мбит / с и т. д.) и трафик как объем (Мб, ГБ и т.д.)

Плюсы:

• Затраты на трафик для малых и средних объемов, предполагая, что менее одного терабайта в месяц. Превысьте эту нечеткую линию и либо сделайте это сами, либо найдите правильный CDN
• Активное сообщество пользователей
• Эффективно неограниченная пропускная способность с содержимым S3/CloudFront-delivered
• Гибкость (запускайте экземпляр и запускайте его в считанные минуты)
• CPU мощности, доступной в экземпляре, даже маленьком типе экземпляра, всегда было достаточно для моего приложения. Для тех, кто в этом нуждается, существуют и другие типы инстансов high-CPU.

Аферы:

• У нас был экземпляр, ставший недоступным (не неслыханное явление), и мы выполнили нашу процедуру аварийного восстановления. 12 часов.
• Задержка сети, как для S3, так и для EC2, может быть неприемлемо высокой (100 мс)
• Пропускная способность инстанса EC2 ограничена. Несмотря на многочасовые поиски, я так и не нашел официального заявления с твердыми цифрами, что пользователи могут ожидать. Первоначально мы видели максимум ~250mpbs в тестах, но это, кажется, значительно улучшилось.
• Пропускная способность соединения на HTTP может быть неприемлемо низкой. 1-2mbps даже из нашего швейцарского дата-центра с подключением 800mpbs и качественным пирингом. EDIT: недавно мы видели тарифы между нашим дата-центром и EC2 в диапазоне 3-4mpbs.
• S3 не является файловой системой 'normal', и требуется специальное программное обеспечение. Мы выбрали JungleDisk,который я теперь считаю неуместным для среды сервера набора данных среднего размера 24/7,. Случались странные вещи (файл перечислялся дважды с командой 'ls') и неожиданные сбои. Используйте EBS для постоянных данных, хотя это и не без оговорок .
• S3-это не CDN. Моя компания, как и многие другие, пыталась использовать Amazon S3 в качестве CDN. Есть и другие недорогие альтернативы. (Akamai, voxel.net, easycache.com )

Я поклонник концепции cloud, и мы продолжим запускать экземпляр из EC2, но мы сочли его неподходящим для наших основных производственных потребностей в его нынешнем виде. AWS имеет некоторые проблемы, чтобы разобраться.

В настоящее время я использую S3 для видеохостинга, и мне это нравится. Если вы используете .NET, дайте себе немного времени, чтобы получить установку, интегрированную в ваш сайт. Я бы очень рекомендовал их услуги.

Единственное, что я нашел грубым, это то, что вы должны были потратить >100, чтобы получить серебряный уровень обслуживания, наш сайт будет тратить столько же в конечном итоге, но мы еще даже не в бета-версии. У меня не было вопросов, я просто хотел посмотреть, на что похожа их поддержка.

Поддержка была отличной и очень полезной, однако я хотел бы иметь возможность задать несколько вопросов, не заглядывая в свой карман (скорее в карман босса)

О, у меня не было никаких проблем с лицензиями.

Сравнительно, за деньги, я бы выбрал S3 выше других хостинг-сервисов, потому что их охват настолько огромен, а цена на него так низка.

Относительно Надежности

У меня нет ничего работающего на службе cloud, но я хотел бы решить проблему надежности.

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

Я использую S3 для размещения изображений (в настоящее время более 5 миллионов файлов) и для резервного копирования серверов. Я использовал EC2 для обработки изображений и SQS для координации между этими задачами. Я должен сказать, что я удалил EC2, так как для этой конкретной задачи невиртуализированный сервер оказался в 10 раз быстрее. И я написал свое собственное решение очереди с использованием mysql, которое оказалось намного быстрее и не было тесно связано с AWS.

Есть важный пост в Coding Aloud [ http://www.codingaloud.com/2008/01/going-bankrupt-with-amazon-s3.html] под названием "банкротство с Amazon S3", взгляните.

Отказ от ответственности: у меня есть аспирант в UCSB, который выпускает программное обеспечение, о котором я собираюсь упомянуть.

Если вы беспокоитесь о владении cloud (например, физически не владеете своими cloud коробками), вы можете посмотреть на эвкалипт . Он совместим с EC2 API и позволяет вам использовать ваши серверы, а также имеет открытый исходный код, так что вы можете точно видеть, что происходит.

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

Для вашего второго редактирования проверьте CloudStatus . Он отслеживает AWS stuff и Google App Engine на предмет сбоев и производительности. Amazon также отслеживает их перебои в работе на http://status.aws.amazon.com/ .

Мы храним файлы нашей компании на S3, чтобы они могли быть доступны сотрудникам на ходу. Чрезвычайно дешево и легко. Множество приложений для доступа к вашим файлам на S3. Тот, который мы используем, - это хороший онлайн-файловый менеджер: S3fm .

Группа друзей и я работаем над приложением, которое живет в cloud. Однако та часть cloud, в которой он живет, находится под нашим контролем. Я бы никогда не доверил третьей стороне делать такого рода подъем для моего приложения, потому что у меня нет контроля над ним. Недавнее отключение Amazon S3-отличная иллюстрация того, почему.

И я абсолютно, положительно, никогда бы не поставил какую-либо часть моей инфраструктуры на (например) серверы Amazon. Сборка серверов, исходный код и т. д. всегда строго контролируется. Не только из-за потенциальной ненадежности, но и потому, что я нахожу лицензии на эти услуги чрезмерно разрешительными для поставщика услуг. Кроме того, недобросовестный host* потенциально может взять мой исходный код и использовать его в своих целях, даже если что-то подобное не легализовано лицензионным соглашением, которое я должен был бы принять, чтобы использовать сервис.

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