Неплохо бы в таких статьях показывать, чем выгодно отличается от того же упомянутого Chef?
То, что я прочитал в этой статье, как бы говлорит: ещё один велосипед, ни комьюнити, ни интеграции нормальной с Vagrant: создавать свой скрипт для провижина и тд.
Спасибо за статью! У меня, к сожалению, руки не дошли ещё на практике попробовать AWS Lambda.
Жаль, конечно, что пока только JS поддерживается, хотя имея смекалку…
Нужно тестировать для конкретного приложения. Думаю, что всякие задачки по типу обработки картинок будут проходить быстро. Как хранилище данных можно использовать DynamoDB — скорость записи должна быть ок.
Во-первых, статья — не разоблачение, а лишь два случая использования Route53. Факты описанные в статье, давно известны.
Во-вторых, отметать балансировщик только потому, что он «заточен под веб», без детального рассмотрения глупо.
Не совсем так. Это зависит от мониторинга и реализации. Например, если мониторинг близкий к реальному времени, тогда да. Если же нет, то sqs-очередь проверять можно с большй частотой.
Например, я тут прикинул, если раз в секунду проверять очередь, то в месяц заплатим 1$ за SQS.
Не могу сказать за loggly, есть ли у них проблемы. У нас на проекте с перконой точно никаких нет. Думаю, что проблема может возникнуть у приложений, доступных через интернет (кэширование на клиенте и т.д.).
Возможно я не верно вас понял, но если речь о втором случае с percona cluster, то elb совершенно излишен, так как все ноды находятся в одном регионе и все что нам нужно это раунд робин для запросов. На мой взгляд, все дело в том, что elb заточен изначально был под типичные web приложения.
Проблем никаких. Чем меньше сервисов нужно администрировать, тем лучше. Мониторинг и шеф — просто пример. На проекте есть множество задач, которые запускаются по расписанию или событию. Минус в том, что нужно поддерживать серверы, на которых эти задачи выполняются.
для автоматизации удаления ресурсов, ассоциированных с инстансами, например, из мониторинга, шефа (но есть проблема: инстансы не поддерживаются как источник событий, но думаю API спасет)
для запуска кучи задач по расписанию, но тут проблема с джавой пока
То, что я прочитал в этой статье, как бы говлорит: ещё один велосипед, ни комьюнити, ни интеграции нормальной с Vagrant: создавать свой скрипт для провижина и тд.
Жаль, конечно, что пока только JS поддерживается, хотя имея смекалку…
Проблема может возникнуть и с ELB за Route53, так как elb скейлится, периодически его IP меняются.
Во-вторых, отметать балансировщик только потому, что он «заточен под веб», без детального рассмотрения глупо.
Что касается IronWorker и IronMQ, то поддержка нескольких провайдеров — это преимущество, когда нужно избежать vendor lock.
Любобытно, что воркеры и очередь хостятся в AWS либо Rackspace.
А так, идея не нова, конечно же.
Например, я тут прикинул, если раз в секунду проверять очередь, то в месяц заплатим 1$ за SQS.
Не могу сказать за loggly, есть ли у них проблемы. У нас на проекте с перконой точно никаких нет. Думаю, что проблема может возникнуть у приложений, доступных через интернет (кэширование на клиенте и т.д.).
—
vagrant provision—
chef-solo—
knife bootstrap—
другой способзанимает больше врмени, тогда ОК.