Почему люди используют Heroku, когда присутствует AWS? Что отличает Heroku от AWS?

Ответ 1

AWS/Heroku являются бесплатными для небольших хобби проектов (для начала).

Если вы хотите сразу начать приложение, без большой настройки архитектуры, выберите Heroku.

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

Heroku

• Платформа как услуга (PAAS)
• Хорошая документация
• Имеет встроенные инструменты и архитектуру.
• Ограниченный контроль над архитектурой при разработке приложения.
• Развертывание выполняется (автоматически через GitHub или вручную с помощью команд git или CLI).
• Не требует много времени.

AWS

• Инфраструктура как услуга (IAAS)
• Универсальный - имеет много продуктов, таких как EC2, LAMBDA, EMR и т.д.
• Может использовать выделенный экземпляр для большего контроля над архитектурой, такой как выбор ОС, версия программного обеспечения и т.д. Там имеется более одного базового слоя.
• Эластичный бобовый станок - это особенность, похожая на Heroku PAAS.
• Может использовать автоматическое развертывание или сворачивать самостоятельно.

Ответ 2

Прежде всего, AWS и Heroku - это разные вещи. AWS предлагает инфраструктуру как услугу (IaaS), тогда как Heroku предлагает платформу как услугу (PaaS).

Какая разница? Очень важно, что IaaS дает вам компоненты, необходимые для создания вещей поверх него; PaaS дает вам среду, в которой вы просто вводите код и какую-то базовую конфигурацию и получаете запущенное приложение. IaaS может дать вам больше энергии и гибкости, за счет того, что вам нужно строить и поддерживать больше себя.

Чтобы получить код на AWS и немного похож на развертывание Heroku, вам понадобятся некоторые экземпляры EC2 - вам понадобится установленный на них уровень балансировки нагрузки/кеширования (например, Varnish), вам понадобятся экземпляры, запускающие что-то вроде Passenger и nginx для вашего кода, вы захотите развернуть и настроить экземпляр кластерной базы данных, например, PostgreSQL. Вам понадобится система развертывания с чем-то вроде Capistrano и что-то, что делает агрегацию журналов.

Это не несущественная работа по созданию и поддержанию. С Heroku усилия, необходимые для того, чтобы добраться до такого этапа, - это, может быть, несколько строк кода приложения и git push.

Итак, вы так далеко, и хотите увеличить масштаб. Отлично. Вы используете Puppet для своего развертывания EC2, правильно? Итак, теперь вы настраиваете файлы Capistrano для разворачивания вверх/вниз по мере необходимости; вы повторно запустите свою конфигурацию Puppet, чтобы Varnish знал о экземплярах веб-мастера и автоматически объединялся между ними. Или вы heroku scale web:+5.

Надеюсь, это даст вам представление о сравнении между ними. Теперь, чтобы ответить на ваши конкретные вопросы:

Speed ​​

В настоящее время Heroku работает только с экземплярами AWS в us-east и eu-west. Для вас это звучит так, как вы хотите. Для других это потенциально более важно.

Безопасность

Я видел много внутренних серверов, которые поддерживают обновления безопасности, или, как правило, плохо объединяются. С Героку у вас есть кто-то другой, управляющий такими вещами, который является либо благословением, либо бичем в зависимости от того, как вы на это смотрите!

Когда вы развертываете, вы эффективно передаете свой код прямо на Heroku. Это может быть проблемой для вас. Их статья о Dyno Isolation подробно описывает их технологии изоляции (кажется, что несколько отдельных динамиков запускаются в отдельных экземплярах EC2). Несколько коллег выразили проблемы с этими технологиями и силой их изоляции; Я, увы, не в состоянии достаточно знаний/опыта, чтобы действительно комментировать, но мои текущие развертывания Heroku считают это "достаточно хорошим". Это может быть проблемой для вас, я не знаю.

масштабирование

Я коснулся того, как это можно реализовать в моем сравнении IaaS и PaaS выше. Пример: у вашего приложения есть Procfile, который имеет строки формы dyno_type: command_to_run, например, (скребок из http://devcenter.heroku.com/articles/process-model):

web:    bundle exec rails server
worker: bundle exec rake jobs:work

Это с помощью:

heroku scale web:2 worker:10

приведет к тому, что у вас будет 2 web dynos и 10 worker dynos. Хороший, простой, легкий. Обратите внимание, что web - это специальный тип dyno, который имеет доступ к внешнему миру и находится за их хорошим мультиплексором веб-трафика (вероятно, какой-то комбинацией Varnish/nginx), которая будет маршрутизировать соответственно. Ваши рабочие, вероятно, взаимодействуют с очередью сообщений для аналогичной маршрутизации, из которой они получат местоположение через URL-адрес в среде.

Эффективность затрат

У многих людей есть много разных мнений об этом. В настоящее время он составляет 0,05 долл. США за час в час, по сравнению с 0,025 долл. США за час для микро-экземпляра AWS или 0,09 долл./Час для небольшого экземпляра AWS.

Heroku динамическая документация говорит, что у вас около 512 МБ ОЗУ, поэтому, вероятно, не слишком необоснованно рассматривать дино как немного похожее на EC2 micro пример. Стоит ли это вдвое больше цены? Сколько вы цените свое время? Количество времени и усилий, необходимых для создания на вершине предложения IaaS, чтобы получить его к этому стандарту, определенно не дешево. Я не могу ответить на этот вопрос, но не стоит недооценивать "скрытые затраты" на настройку и обслуживание.

(Немного в стороне, но если я подключусь к дино отсюда (heroku run bash), беглый взгляд показывает 4 ядра в /proc/cpuinfo и 36 ГБ ОЗУ - это заставляет меня думать, что я нахожусь a "High-Memory Double Extra Large Instance" . Heroku дино документация говорит, что каждый дино получает 512 МБ ОЗУ, поэтому я могу разделить до 71 другого динозавра. (У меня недостаточно данных о гомогенности экземпляров AWS Heroku, поэтому ваше перемещение может меняться))

Как они конкурируют с конкурентами?

Это, боюсь, я не могу вам помочь. Единственным конкурентом, с которым я когда-либо смотрел, был Google App Engine - в то время, когда я искал развертывание приложений Java, и количество ограничений на используемые рамки и технологии было невероятно удалено. Это больше, чем "просто Java-вещь" - количество общих ограничений и необходимых соображений (ответы на часто задаваемые вопросы в нескольких) казалось менее удобным. Напротив, развертывание в Хероку было мечтой.

Заключение

Я надеюсь, что это ответит на ваши вопросы (прокомментируйте, есть ли пробелы/другие области, которые вы хотели бы адресовать). Я чувствую, что должен предлагать свою личную позицию. Я люблю Heroku для "быстрого развертывания". Когда я запускаю приложение, и мне нужен какой-то дешевый хостинг (свободный уровень Heroku - это классно - по существу, если вам нужен только один веб-дино и 5MB PostgreSQL, он может свободно размещать приложение), Heroku - моя позиция, Для "Серьезного развертывания производства" с несколькими платящими клиентами, с соглашением на уровне обслуживания, с выделенным временем, потраченным на операционные системы и т.д., Я не могу полностью избавиться от такого контроля над Хероку, а затем либо AWS, либо наши собственные серверы были платформой для хостинга.

В конечном счете, это о том, что лучше всего подходит для вас. Вы говорите, что вы "программист для начинающих" - возможно, только с помощью Heroku вы сможете сосредоточиться на написании Ruby и не тратить время на создание всей другой инфраструктуры вокруг вашего кода. Я бы определенно дал ему попробовать.

Примечание. AWS действительно имеет предложение PaaS, Elastic Beanstalk, поддерживающее Ruby, Node.js, PHP, Python,.NET и Java. Я думаю, что большинство людей, когда они видят "AWS", переходят на такие вещи, как EC2 и S3 и EBS, которые, безусловно, являются предложениями IaaS

Ответ 3

Как утверждает Kristian Glass Said, нет никакого сравнения между IaaS (AWS) и PaaS (Heroku, EngineYard).

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

Но все же есть темная сторона PaaS, которая препятствует принятию PaaS:

• Менее контроль над сервером и базами данных
• Затраты будут очень высокими, если не будут правильно регулироваться
• Преждевременные и сомнительные в текущем дне и возрасте

Помимо выше, у вас должно быть достаточно навыков, чтобы свести вас с ума IaaS:

• Приобретение оборудования
• Операционная система
• Серверное программное обеспечение
• Среда для сценариев на стороне сервера
• веб сервер
• Система управления базами данных (Mysql, Redis и т.д.)
• Настроить производственный сервер
• Инструмент для тестирования и развертывания
• Приложение для мониторинга
• Высокая доступность
• Маршрутизация загрузки /Http
• Политики резервного копирования услуг
• Командное сотрудничество
• Перестроить производство

Если у вас есть малый бизнес, PaaS будет лучшим вариантом для вас:

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

Это будет полностью индивидуальный выбор, основанный на требовании. У вас есть информация о моих приложениях PPT Hosting Rails.

Ответ 4

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

Подумайте о своих требованиях.

Я разработал веб-сайты, которые ежедневно обслуживали более 8 миллионов часов и доставляли терабайты видео в неделю, построенные на инфраструктурах, начиная с $250 тыс. в капитальном оборудовании unr огромным трудовым персоналом в $MM.

Но у меня также были небольшие веб-сайты, которые были предназначены для генерации $10-20 тыс. в год, не имели очень высокого трафика, db или требований к обработке, и я запустил их с общей учетной записи хостинга $10/mo без компромиссов.

В будущем развертывание будет больше напоминать Heroku, чем AWS, только из-за прогресса. Существует нулевое значение в ручке ИТ-масштабирования масштабирующих интернет-инфраструктур, которая не становится все более автоматизированной, и ничто из этого не имеет ничего общего с ценностью продукта или услуги, которую вы предлагаете.

Кроме того, обратите внимание на коммерческий сайт - масштабируемость - это то, что мы часто называем "хорошей проблемой" - хотя проблемы с масштабируемостью на таких сайтах, как Facebook и Twitter, были очень громкими, они имели нулевой негативный эффект на успех - новость, возможно, даже способствовала увеличению количества подписчиков (все пресса является хорошим нажатием).

Если у вас есть служба, которая генерирует 100k + uniques в день и имеет проблемы с масштабированием, я был бы рад взять ее за вас за вас, независимо от того, на каком языке, db, платформе или инфраструктуре вы работаете

Масштабируемость - это исправляемая проблема реализации - не наличие клиентов является экзистенциальной проблемой.

Ответ 5

На самом деле вы можете использовать оба варианта - вы можете разработать приложение с серверами Amazon ec2. Затем нажимайте на него (с помощью git) на героку бесплатно на некоторое время (используйте бесплатный уровень heroku для его публикации) и протестируйте его так. Это очень выгодно по сравнению с арендой сервера, но вам придется поговорить с более ограничительным героем api, о чем вы должны думать. Источник: этот метод был принят для одного из моих онлайн-классов "Вводная инженерия из Курсеры/Стэнфорда" Баладжи С. Сринивасан и Виджай С. Панде

Ответ 6

Существующие ответы в целом точны:

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

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

Для tl; dr пропустите до конца этого сообщения.

AWS ElasticBeanstalk представляет собой попытку создать платформу для автоматического масштабирования и простоты развертывания Heroku. Поскольку он использует экземпляры EC2 (которые он создает автоматически), EB-серверы могут делать все, что может сделать любой другой экземпляр EC2, и это дешево для запуска.

Развертывание с помощью ЭБ очень медленное; развертывание обновления может занять 10-15 минут на один сервер, а развертывание в более крупный кластер может занимать большую часть часа - по сравнению с несколькими секундами для развертывания обновления на Heroku. Развертывания на EB не обрабатываются особенно легко, что может налагать ограничения на дизайн приложения.

Вы можете использовать все сервисы, которые ElasticBeanstalk использует за кулисами для создания собственной системы на заказ (с CodeDeploy, балансировщиком эластичной нагрузки, группами автоматического масштабирования и CodeCommit, CodeBuild и CodePipeline, если вы хотите все входить), но вы можете определенно потратить хорошее пару недель, настроив его в первый раз, поскольку он довольно запутан и немного запутан, чем просто настройка вещей в EC2.

AWS Lightsail предлагает выгодный по цене вариант хостинга, но не помогает при развертывании или масштабировании - это действительно просто оболочка для своего предложения EC2 (но стоит гораздо больше). Он позволяет автоматически запускать сценарий bash при начальной настройке, что приятно, но это дорого, по сравнению с затратами на простое создание экземпляра EC2 (что также можно делать программно).

Некоторые мысли о сравнении (чтобы попытаться ответить на вопросы, хотя и обходным путем):

1. Не стоит недооценивать, сколько работает системное администрирование, включая все, что вы обновили с помощью патчей безопасности (и случайных обновлений ОС).

2. Не стоит недооценивать, насколько эффективны автоматическое развертывание, автоматическое масштабирование и настройка и настройка SSL.

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

   Вы также можете использовать ElasticBeanstalk для автоматического развертывания, но будьте готовы к установке недельной настройки в первый раз - вам, возможно, придется изменить способ развертывания и создания активов (например, CSS и JS) для работы с тем, как ElasticBeanstalk обрабатывает развертывания или логику сборки в ваше приложение для обработки развертываний.

   Имейте в виду, что для оценки затрат, которые для беспрепятственного развертывания без отключения EB, вам нужно запустить несколько экземпляров - EB разворачивает обновления для каждого сервера индивидуально, чтобы ваша служба не ухудшалась - где, когда Heroku закручивает новый дино для вас и просто осуждает старая служба до тех пор, пока все запросы к ней не будут обработаны (тогда она удалит ее).

   Интересно, что стоимость хостинга нескольких серверов с EB может быть дешевле одного экземпляра Heroku, особенно после того, как вы включите стоимость надстроек.

Некоторые другие вопросы, о которых конкретно не спрашивают, но затронуты другими ответами:

1. Использование другого поставщика для производства и разработки - плохая идея.

   Я сжимаю, что люди предлагают это. В то время как идеальный код должен отлично работать на любой разумной платформе, чтобы он был как можно более переносимым, версии программного обеспечения на каждом хосте будут сильно различаться, и только потому, что код работает в стадии постановки, это не значит, что он будет запущен в процессе производства (например, основные Node.js/Версия Ruby/Python/PHP/Perl может отличаться способом, который делает код несовместимым, часто беззвучным способом, который не может быть пойман, даже если у вас есть достойное покрытие для тестирования).

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

   Обязательно учитывайте стоимость запуска производственных и предварительных экземпляров при принятии этого решения, не забывая о стоимости репликации всей среды (включая сторонние сервисы, такие как хранилища данных/добавление, установка и настройка SSL и т.д.).,

2. Если вы используете AWS, будьте осторожны с предварительно настроенными экземплярами AWS от таких поставщиков, как Bitnami - это кошмар безопасности. По умолчанию они могут обнародовать множество незащищенных приложений, не упоминая об этом в описании.

   Вместо этого рассмотрите возможность использования широко распространенного дистрибутива, такого как Ubuntu или Debian (или CentOS, если вам нужна поддержка RPM).

   Примечание. У Amazon есть собственный дистрибутив Amazon Linux, который использует RPM, но EC2 определен и менее хорошо поддерживается сторонним/открытым исходным кодом.

3. Вы также можете настроить экземпляр EC2 на AWS (или Lightsail) и настроить с ним что-то вроде flynn или dokku, на котором вы могли бы легко развернуть несколько сайтов, что может быть полезно, если вы поддерживаете множество сервисов или хотите быть способный легко раскручивать новые вещи. Однако создание его не так просто, как просто использование Heroku, и вы можете потратить много времени на его настройку и поддержку (до такой степени, что я обнаружил, что развертывание с использованием кластеров Amazon и Docker Swarm было проще, чем их настройка; YMMV).

В то же время я использовал экземпляры AWS EC (отдельно и в кластерах), Elastic Beanstalk и Lightsail и Heroku в зависимости от потребностей проекта, над которым я работаю.

Мне не нравится тратить время на настройку сервисов, но мой счет в Heroku будет тысячами в год, если я буду использовать его для всего, и AWS выработает часть стоимости.

ТЛ; др

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

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

Пример службы, которая почти такая, - now.sh, которая фактически использует AWS за кулисами, но делает развертывание и кластеризацию так же просто, как и на Heroku (с автоматическим SSL, DNS, изящными развертываниями, супер-простой настройкой кластеров и управление).

Я использовал его довольно много для приложений Node.js и развертывания образа Docker, главное предостережение - это совместное использование экземпляров (что-то отражается в их более низкой стоимости), и в настоящее время нет возможности покупать выделенные экземпляры. Однако их инструмент для развертывания с открытым исходным кодом "сейчас" также можно использовать для развертывания в выделенных экземплярах на AWS, а также в Google Cloud и Azure.

Ответ 7

Ну, люди обычно задают этот вопрос: Heroku или AWS, когда начинают что-то развертывать.

Мой эксперимент по использованию и Heroku и AWS, вот мой быстрый обзор и сравнение:

Heroku

• Одна команда для развертывания любых типов проектов: Ruby on Rails, Nodejs
• Так много 1-кликов для интеграции плагинов и третьих сторон. С чем-то очень легко начать.
• Не имеют автоматического масштабирования; это означает, что вам нужно масштабировать вверх/вниз вручную
• Стоимость стоит дорого, особенно, когда системе требуется больше ресурсов.
• Доступен бесплатный экземпляр
• Свободный экземпляр переходит в спящий режим, если он неактивен.
• Центр обработки данных: только для США и ЕС
• МОЖЕТ погрузиться в/на уровень машины с помощью Heroku run bash (спасибо, MJafar Mash за совет), но это немного ограничено! У вас нет полного доступа!
• Не нужно слишком много знать о DevOps

AWS - EC2

• Это как машина с предустановленной ОС (или нет), поэтому вам нужно установить программное обеспечение, библиотеку, чтобы сделать ваш сайт/услугу в сети.
• Плагин и библиотека необходимо интегрировать вручную или автоматизировать script (общедоступный script и написанный вами)
• Автоматическое масштабирование и балансировка нагрузки - это поддерживаемые службы, просто узнайте, как конфигурировать и интегрировать в свою систему.
• Стоимость довольно дешевая, зависит от того, какие услуги и количество часов вы используете.
• Существует несколько бесплатных часов для экземпляров T2.micro, но обычно вы будете платить несколько долларов каждый месяц (если все еще используете T2.micro)
• Ваш бесплатный экземпляр не будет спать, доступен 24/7 (потому что вы можете заплатить за него:))
• Центр обработки данных: по всему миру. Выберите регион, который наилучшим образом подходит для вас.
• Погрузитесь в машинный уровень. Таким образом, вы можете наслаждаться этим.
• Некоторые знания о DevOps, но это нормально, Stackoverflow здесь полезен.

AWS Elastic Beanstalk альтернатива Heroku, но дешевле

• Эластичный бобовый станок был объявлен публичной бета-версией с 2010 года; это помогает нам легче работать с развертыванием. Для получения подробной информации перейдите здесь

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

• Я использую Elastic Beanstalk в течение длительного времени, и я думаю, что это может быть замена Heroku и дешевле!

Резюме

• Heroku: простой в начале, БЕСПЛАТНЫЙ экземпляр, но дорогой позже
• AWS: нелегко, свободные часы доступны, вид дешевле, Beanstalk должен заботиться о том, чтобы использовать

Итак, в моей нынешней системе я использую Heroku для постановки и Beanstalk для производства!

Ответ 8

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

Тем не менее, есть все больше возможностей для удобства использования Heroku и гибкости AWS, находясь на AWS с отличными фреймворками/инструментами.

Ответ 9

Amazon Web Services (AWS) предлагает множество услуг от IaaS до PaaS с гарантированной 99,9999999% долговечностью и доступностью данных и инфраструктуры. AWS предлагает инфраструктуру автоматизации наряду с несколькими инструментами для разработчиков для конвейерного процесса их развертывания приложений.

С другой стороны, Heroku - это просто PaaS, который предлагает услуги по управлению вашей платформой на своем облаке. Нигде не стоит с AWS, будь то инфраструктура или безопасность.

Ответ 10

Забавно, что Heroku использует AWS на сервере. Это устраняет все накладные расходы и делает управление архитектурой на EC2 для вас. (Получил знания от старшего инженера в Большой компании во время интервью)

Ответ 11

Ну! Я наблюдатель Heroku известен в начинающих и новорожденных разработчиках, в то время как AWS имеет отличную персону разработчика. DigitalOcean также является основным игроком в этой области. Cloudways упростило создание Lamp stack одним щелчком мыши на DigitalOcean и AWS. Наличие всех обновлений услуг и пакетов в клике намного лучше, чем все вручную.

Вы можете полностью проверить здесь: https://www.cloudways.com/blog/host-php-on-aws-cloud/

Ответ 12

Иногда мне интересно, почему люди сравнивают AWS с Heroku. AWS - это IAAS (инфраструктура как услуга), он четко говорит о том, насколько надежной и расчетной является система. Heroku, с другой стороны, является просто SAAS, это в основном только одна часть услуг AWS. Так зачем бороться с настройкой AWS, когда вы можете отправить свой первый продукт в основное пользование с помощью Heroku.

Heroku является бесплатным, простым и простым в развертывании практически всех типов стеков в Интернете. Heroku специально построен для того, чтобы обойти все неприятности, связанные с отправкой вашего приложения на живой сервер менее чем за один раз.

Тем не менее, вы можете захотеть развернуть свое приложение с помощью любого из учебных пособий обеих сторон и сравнить

AWS DOCS и Heroku Docs

Ответ 13

Хорошо Heroku использует AWS в фоновом режиме, все зависит от типа решения, которое вам нужно. Если вы являетесь ядром Linux и devops, вы не беспокоитесь о том, чтобы создать vm с нуля, например, выбрав ami, выбрав опции подделки и т.д., Вы можете пойти с AWS. Если вы хотите делать что-то на уровне поверхности, не имея этих нетигрываний, вы можете пойти с героку.

Ответ 14

Хотя оба AWS и Heroku являются облачными платформами, они различны, поскольку AWS - это IaaS, а Heroku - PaaS

Ответ 15

Я прочитал несколько ответов о том, что HEROKU и AWS являются настолько разными (первая - это платформа как Сервис, а вторая - Infra as Service. Чтобы сопоставить сравнение в перспективе, Amazon предлагает решение PaaS своим названием AWS Elastic Beanstalk. Для сравнения о них, пожалуйста, проверьте приведенный ниже URL. https://dzone.com/articles/heroku-or-amazon-web-services-which-is-best-for-your-startup

Ответ 16

ну.. его не все так радужно..

в первую очередь: AWS - это не наука о ракетах, и если вы знаете свой путь вокруг развертывания "вещей" в конце дня, то лучше использовать AWS и дешевле.. вместо любых других PaaS, которые, как правило, всегда дороже в обмен на "вещи" для вас... IMHO AWS намного лучше, и у вас намного больше контроля в целом,

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