В этой заметке я намерен поделиться с вами своим субъективным мнением касательно Amazon Web Services , которое сформировалось у меня после года использования этого облака на практике. Поскольку есть основания полагать, что те же рассуждения применимы не только к AWS, но и к Azure с Google Cloud, я рискну экстраполировать свои мысли также и на другие облака.

На этот раз начну с плюсов:

• Не нужно самим админить железные сервера, прокладывать между ними кабеля, охлаждать, и так далее. Нажал кнопку — получил сервер. Нажал другую — удалил. Очень удобно;
• Как следствие, нет такого, что на еще один крутой сервер нет денег, или его некуда поставить, или он будет долго ехать. В результате вы не приходите к ситуации вроде «ну раз новой железки не будет, придется тут добавить кэшик, здесь добавить, и вот тут еще, и надеяться, что нигде ничего не разъедется». Железо есть (почти) всегда. Фактически, приходится заниматься не столько оптимизацией CPU или памяти, сколько оптимизацией стоимости одного пользователя;
• За счет того, что новый север можно ввести в бой за пару минут, и так же быстро потом вывести, вы всегда готовы к пиковым нагрузкам, например, если ваш проект внезапно упомянут по TV или на крупном новостном сайте (с оговорками, см ниже);
• Зрелый SDK, API на все случаи жизни, хорошая документация;
• В отличие от некоторых популярных недооблаков, тут имеется полноценная VPC с удобной настройкой через веб-интерфейс, у каких машин и какие порты куда торчат;
• Очень понравилось делать раскладку при помощи AMI. Создал виртуалку, разложил там приложение, а также Nginx , всякие там collectd , агенты для агрегации логов и так далее. Делаешь из виртуалки образ, прописываешь в автоскелинг группе для stage, увеличиваешь группу, уменьшаешь и все — твой бэкенд на stage. QA проверяют, если все ОК, точно такой же протестированный образ едет на prod. Удобно;
• Для ленивых есть балансировщики нагрузки, всякие там готовые Memcached , Redis и прочее (с оговорками, см ниже);

Но следует также иметь в виду и ряд недостатков:

• Дорого;
• Веб-интерфейс дичейше тормозит;
• Сеть в AWS ни на что не годится. Пинги между хостами в одной AZ идут 1.2 мс. Для сравнения, пинг от моего ноутбука до домашеного роутера по обычной витой паре составляет 0.3 мс, в четыре раза меньше. В некоторых других облаках пинг также существенно лучше, чем в AWS, в районе 0.7 мс. Плюс к этому часто (пару раз в неделю) случаются какие-то короткие сетевые проблемы, из-за которых, в частности, срабатывает автофейловер у Couchbase и разваливается Akka Cluster ;
• Очень просто подсесть на vendor lock и даже не сразу это заметить. Все сервисы, что там накручены, кроме основных (EC2, ELB, SES, и так далее), не работают за пределами AWS. А значит, если вы плотно на них завязались, то вам будет очень трудно уйти с AWS куда-то еще;
• Плюс эти сервисы довольно убоги сами по себе. Сервисы на основе открытых проектов, вроде ElastiCache или RDS, имеют чудовищный интерфейс, невыносимо долго разворачиваются (пол часа и дольше) и часто стоят дороже, чем если поднять все самим. Самопальные же сервисы вроде DynamoDB или CloudSearch попросту не годятся ни на что, кроме hello world’ов. Как только у вас появится нормальная нагрузка, вы либо разоритесь, либо утоните в кэшиках и прочих подпорочках, необходимых, чтобы использовать эти сервисы реже. Плюс невозможно сказать, как эти сервисы ведут себя в граничных случаях вроде нетсплитов, и при их использовании очень сложно посчитать, во сколько вам обойдется один пользователь. Скейлится все это хозяйство, вопреки рекламе, также далеко не моментально и не неограниченное количество раз. Как производить тестирование, в том числе нагрузочное, непонятно. В общем и целом, даже не пытайтесь их использовать, все действительно очень плохо;
• Отдельно хотелось бы сказать про автоскейлинг группы. Во-первых, они довольно тупые, и научить их правильно сжиматься и разжиматься так, чтобы это происходило автоматически, непросто. Проще написать скрипт, который тупо по расписанию создает новые машины, а потом удаляет их. Во-вторых, в Amazon есть квота на число EC2 инстансов, которое можно запустить с одного аккаунта. Чтобы эти квоты увеличить, приходится писать в саппорт. Более того, в вашей AZ могут тупо закончится машины используемого вами типа, и лечится это только переходом на другой тип. Короче говоря, в самый ответственный момент автоскейлинг может и не сработать. В-третьих, прикрутить к автоскейлинг группам какой-нибудь Nagios очень непросто, так как вы не можете сказать, какие машины он должен мониторить и нормально ли, если одна из этих машин сдохла;
• Есть сведения , что ELB не масштабируется, если не написать в поддержку;
• В AWS очень многое ведет себя не очевидно. Например, после ребута внезапно затирается файл /etc/apt/sources.list. Если зафаерволить при помощи Netfilter порты с 1024 по 65535, все будет работать. Но после ребута тачка уже никогда не поднимется. Ну и другие такого рода вещи;

Мой вердикт — если вы хоститесь в облаках, не используйте ничего, кроме самых основных вещей, которые есть вообще в любом облаке. Создавайте машины и виртуальную внутреннюю сеть между ними. Можно еще взять местный аналог SES и, возможно, местный S3 чисто для бэкапов. Может быть, даже Route 53, хотя тут я уже не уверен. Не верьте в маркетинговый булшит о том, что оно якобы само как-то умно будет маштабироваться, само себя администрировать, валшебным образом само очень классно работать и что вы будете платить только за то, что вам действительно нужно. Чудес не бывает. Используйте чужую инфраструктуру, но сервисы поднимайте сами — сэкономите и нервы, и деньги. Многие приводят контраргумент, что свои сервисы самим же приходится поддерживать . Практика показывает, что эти люди просто боятся того, что они сами никогда не делали. Разобраться в той же Cassandra и поднять свой кластер в Amazon занимает от силы один рабочий день. И затем там практически нечего поддерживать, разве что изредка умершие ноды заменять.

Ну вот, а если вы используете Amazon чисто как IaaS, то там все довольно неплохо. В реальных проектах его вполне можно использовать почти без боли.

Дополнение: См также статьи Создаем свой маленький IaaS на Parallels Virtual Automation и Мой первый опыт использования Proxmox VE .