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

Ответ 1

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

Заметьте, что:

• Мое приложение имеет полосу пропускания (начиная со 100 Мбит/с на экземпляр)
• Моя компания и я находимся в Швейцарии, и это, безусловно, повлияло на нашу оценку.
• Я определяю пропускную способность как скорость потока (mbps и т.д.) и трафик как объем (mb, gb и т.д.).

Плюсы:

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

Минусы:

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

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

Ответ 2

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

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

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

О, у меня нет проблем с лицензией.

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

Ответ 3

Что касается надежности

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

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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