Мне было интересно, в чем разница между App Engine и Compute Engine. Может ли кто-нибудь объяснить мне разницу?
В чем разница между Google App Engine и Google Compute Engine?
Ответы (11)
App Engine - это платформа как услуга. Это означает, что вы просто развертываете свой код, а платформа делает все остальное за вас. Например, если ваше приложение станет очень успешным, App Engine автоматически создаст дополнительные экземпляры для обработки возросшего объема.
Compute Engine - это инфраструктура как услуга. Вам необходимо создать и настроить собственные экземпляры виртуальных машин. Это дает вам большую гибкость и обычно стоит намного меньше, чем App Engine. Недостатком является то, что вам придется самостоятельно управлять своим приложением и виртуальными машинами.
При необходимости вы можете одновременно использовать App Engine и Compute Engine. Оба они хорошо работают с другими частями Google Cloud Platform.
РЕДАКТИРОВАТЬ (май 2016 г.):
Еще одно важное отличие: проекты, работающие на App Engine, могут масштабироваться до нуля, если запросы не поступают. Это чрезвычайно полезно на этапе разработки, так как вы можете неделями не выходить за пределы щедрой бесплатной квоты в экземплярах-часах. Для гибкой среды выполнения (т. Е. Для «управляемых виртуальных машин») требуется, чтобы хотя бы один экземпляр работал постоянно.
РЕДАКТИРОВАТЬ (апрель 2017 г.):
Облачные функции (в настоящее время находятся в стадии бета-тестирования) - это следующий уровень абстракции по сравнению с App Engine - экземпляров нет! Он позволяет разработчикам развертывать небольшие фрагменты кода, которые выполняются в ответ на различные события, которые могут включать HTTP-запросы, изменения в облачном хранилище и т. Д.
Самая большая разница с App Engine заключается в том, что функции оцениваются за 100 миллисекунд, в то время как экземпляры App Engine отключаются только после 15 минут бездействия. Еще одно преимущество состоит в том, что облачные функции выполняются немедленно, в то время как для вызова App Engine может потребоваться новый экземпляр, а холодный запуск нового экземпляра может занять несколько секунд или дольше (в зависимости от времени выполнения и вашего кода).
Это делает облачные функции идеальными для (а) редких вызовов - нет необходимости поддерживать экземпляр в рабочем состоянии на всякий случай, (б) быстро меняющихся нагрузок, когда экземпляры часто вращаются и выключаются, и, возможно, для большего количества вариантов использования.
Подробнее об облачных функциях
projects running on App Engine can scale down to zero instances if no requests are coming in. Я изучаю gcloud, но всегда кажется, что ДВА экземпляра - это минимум, когда не поступают запросы. Что правильно? Ноль или минимум два? Есть особый трюк?
- person zipzit; 19.02.2017
Основное отличие состоит в том, что Google App Engine (GAE) является Платформа как услуга (PaaS), тогда как Google Compute Engine (GCE) - это Инфраструктура как услуга (IaaS).
Чтобы запустить приложение в GAE, вам просто нужно написать код и развернуть его в GAE, больше никакой головной боли. Поскольку GAE полностью масштабируем, он автоматически получит больше экземпляров, если трафик возрастет, и уменьшит количество экземпляров, когда трафик уменьшится. С вас будет взиматься плата за ресурсы, которые вы действительно используете, то есть вам будет выставлен счет за Instance-Hours, Переданные данные, Хранилище и т. Д. Ваше приложение действительно использовало. Но ограничение в том, что вы можете создать свое приложение только на Python, PHP, Java, NodeJS, .NET, Ruby и ** Go.
С другой стороны, GCE предоставляет вам полную инфраструктуру в виде виртуальной машины. У вас есть полный контроль над средой и средой выполнения этих виртуальных машин, поскольку вы можете написать или установить там любую программу. На самом деле GCE - это способ виртуально использовать центры обработки данных Google. В GCE вам необходимо вручную настроить инфраструктуру для обеспечения масштабируемости с помощью Load Balancer.
И GAE, и GCE являются частью Google Cloud Platform.
Обновление. В марте 2014 года Google анонсировал новую службу в App Engine под названием Управляемая виртуальная машина. Управляемые виртуальные машины предлагают приложениям ядра приложений немного больше гибкости по сравнению с платформой приложений, процессором и памятью. Как и GCE, на этих виртуальных машинах можно создать настраиваемую среду выполнения для приложения ядра приложений. Фактически управляемые виртуальные машины App Engine в некоторой степени стирают границу между IAAS и PAAS.
Проще говоря: вычислительный движок предоставляет вам сервер, за который вы полностью контролируете / несете ответственность. У вас есть прямой доступ к операционной системе, и вы устанавливаете все необходимое программное обеспечение, которое обычно представляет собой веб-сервер, базу данных и т. Д.
В движке приложений вы не управляете операционной системой какого-либо базового программного обеспечения. Вы загружаете только код (Java, PHP, Python или Go) и вуаля - он просто запускается ...
Движок приложений избавляет от головной боли, особенно для неопытных людей, но у него есть 2 существенных недостатка: 1. дороже (но у него есть бесплатная квота, которой нет у вычислительного движка) 2. у вас меньше контроля, поэтому некоторые вещи просто не подходят возможно, или возможно только одним определенным способом (например, сохранение и запись файлов).
Или, чтобы сделать это еще проще (поскольку иногда мы не можем различить GAE Standard и GAE Flex):
Compute Engine аналогичен виртуальному компьютеру, на котором, например, можно развернуть небольшой веб-сайт + базу данных. Вы управляете всем, в том числе и установленными дисками. Если вы развертываете веб-сайт, вы отвечаете за настройку DNS и т. Д.
Google App Engine (стандартный) похож на изолированную папку только для чтения, куда вы загружаете код для выполнения и не беспокоитесь об остальном (да: только для чтения - есть фиксированный набор библиотек. установлен для вас, и вы не можете развертывать сторонние библиотеки по своему желанию). DNS / поддомены и т. Д. Намного проще сопоставить.
Google App Engine (гибкий) фактически похож на целую файловую систему (а не только на заблокированную папку), в которой у вас больше возможностей, чем у стандартного движка, например у вас есть разрешения на чтение / запись (но меньше по сравнению с Compute Engine). В стандарте GAE у вас установлен фиксированный набор библиотек, и вы не можете развертывать сторонние библиотеки по своему желанию. В гибкой среде вы можете установить любую библиотеку, от которой зависит ваше приложение, включая пользовательские среды сборки (например, Python 3).
Хотя GAE Standard очень громоздок в использовании (хотя Google и объясняет это просто), он действительно хорошо масштабируется под давлением. Это громоздко, потому что вам нужно протестировать и обеспечить совместимость с заблокированной средой и убедиться, что любая сторонняя библиотека, которую вы используете, не использует какую-либо другую стороннюю библиотеку, о которой вы не знаете, которая может не работать в стандарте GAE. Настройка на практике занимает больше времени, но при более длительном развертывании может принести больше пользы.
В дополнение к примечаниям App Engine и Compute Engine выше список также включает сравнение с Google Kubernete Engine и некоторые примечания, основанные на опыте работы с широким спектром приложений от маленьких до очень больших. Дополнительные сведения см. В высокоуровневом описании функций App Engine Standard и Flex в документации Google Cloud Platform на странице Выбор среды App Engine. Для другого сравнения развертывания App Engine и Kubernetes см. Сообщение Даза Уилкина App Engine Flex или Kubernetes Engine.
Стандарт App Engine
Плюсы
- Очень экономичен для приложений с низким трафиком с точки зрения прямых затрат, а также затрат на поддержку приложения.
- Автоматическое масштабирование выполняется быстро. Автомасштабирование в App Engine основано на упрощенных классах экземпляров F1-F4.
- Управление версиями и разделение трафика выполняется быстро и удобно. Эти функции изначально встроены в App Engine (как Standard, так и Flex).
- Минимальное управление, разработчикам нужно сосредоточиться только на своем приложении. Разработчикам не нужно беспокоиться об управлении виртуальными машинами в надежном режиме, как в GCE, или изучении кластеров, как в GKE.
- Доступ к хранилищу данных быстрый. Когда App Engine был впервые выпущен, среда выполнения находилась в одном месте с Datastore. Позже Datastore был выделен как отдельный продукт Cloud Datastore, но совместно с App Engine Standard обслуживание с Datastore остается.
- Поддерживается доступ к Memcache.
- Песочница App Engine очень безопасна. По сравнению с разработкой на GCE или других виртуальных машинах, где вам нужно приложить собственные усилия, чтобы предотвратить захват виртуальной машины на уровне операционной системы, песочница App Engine Standard по умолчанию относительно безопасна.
Минусы
- Обычно более ограниченные, чем другие среды. Экземпляры меньше. Хотя это хорошо для быстрого автомасштабирования, многие приложения могут извлечь выгоду из более крупных экземпляров, таких как экземпляры GCE размером до 96 ядер.
- Сеть не интегрирована с GCE
- Не удается разместить App Engine за балансировщиком нагрузки Google Cloud. Ограничено поддерживаемыми средами выполнения: Python 2.7, Java 7 и 8, Go 1.6-1.9 и PHP 5.5. В Java есть некоторая поддержка сервлетов, но не полный стандарт J2EE.
App Engine Flex
Плюсы
- Можно использовать настраиваемую среду выполнения
- Встроенная интеграция с сетью GCE
- Версия и управление трафиком удобны, как Стандарт
- Экземпляры большего размера могут быть более подходящими для больших сложных приложений, особенно приложений Java, которые могут использовать много памяти.
Минусы
- Сетевая интеграция несовершенна - нет интеграции с внутренними балансировщиками нагрузки или общими виртуальными частными облаками
- Доступ к управляемому кэшу памяти обычно недоступен
Google Kubernetes Engine
Плюсы
- Встроенная интеграция с контейнерами позволяет настраивать время выполнения и лучше контролировать конфигурацию кластера.
- Включает в себя множество передовых методов работы с виртуальными машинами, например неизменяемые среды выполнения и простую возможность отката к предыдущие версии
- Обеспечивает согласованную и повторяемую структуру развертывания
- Основан на открытых стандартах, в частности Kubernetes, для переносимости между облаком и локальной средой.
- Управление версиями может осуществляться с помощью контейнеров Docker и Google Container Registry.
Минусы
- Разделение трафика и управление делаются своими руками, возможно, с использованием Istio и Envoy.
- Некоторые накладные расходы на управление
- Некоторое время, чтобы углубиться в концепции Kubernetes, такие как модули, развертывания, службы, входящие данные и пространства имен.
- Необходимо предоставить некоторые общедоступные IP-адреса, если не используются частные кластеры, сейчас в бета-версии, устраните эту необходимость, но вам все равно нужно предоставить доступ к местам, из которых будут запускаться команды kubectl.
- Интеграция мониторинга не идеальна
- В то время как внутренняя балансировка нагрузки L3 изначально поддерживается в Kubernetes Engine, внутренняя балансировка нагрузки L7 выполняется самостоятельно, возможно, с использованием Envoy.
Compute Engine
Плюсы
- Легко наращивать - не нужно наращивать Kubernetes или App Engine, просто повторно используйте все, что вы знаете из предыдущего опыта. Вероятно, это основная причина использования Compute Engine напрямую.
- Полный контроль - вы можете напрямую использовать многие функции Compute Engine и устанавливать последние из ваших любимых вещей, чтобы оставаться на переднем крае.
- Нет необходимости в публичных IP-адресах. Некоторое устаревшее программное обеспечение может быть слишком сложно заблокировать, если что-либо отображается на общедоступных IP-адресах.
- Вы можете использовать оптимизированную для контейнеров ОС для запуска контейнеров Docker.
Минусы
- В основном это делается самостоятельно, что может быть сложной задачей для обеспечения надежности и безопасности, хотя вы можете повторно использовать решения из разных мест, включая Cloud Launcher.
- Больше накладных расходов на управление. Для Compute Engine существует множество инструментов управления, но они не обязательно поймут, как вы развернули приложение, как это делают инструменты мониторинга App Engine и Kubernetes Engine.
- Автомасштабирование основано на экземплярах GCE, которые могут быть медленнее, чем App Engine.
- Тенденция заключается в установке программного обеспечения на экземплярах Snowflake GCE, что может потребовать некоторых усилий для обслуживания.
Как уже объяснялось, Google Compute Engine (GCE) - это инфраструктура как услуга (IaaS), а Google App Engine (GAE) - это платформа как услуга (PaaS). Вы можете проверить следующую диаграмму, чтобы лучше понять разницу (взято и лучше объяснено здесь) -
Google Compute Engine
GCE - важная служба, предоставляемая Google Cloud Platform (GCP), поскольку большинство служб GCP используют экземпляры GCE (виртуальные машины) под уровнем управления (не уверен, какие из них не ). Сюда входят App Engine, Cloud Functions, Kubernetes Engine (более ранний контейнерный движок), Cloud SQL и т. Д. Экземпляры GCE являются наиболее настраиваемым модулем, поэтому их следует использовать только в том случае, если ваше приложение не может работать на других сервисах GCP. В большинстве случаев люди используют GCE для переноса своих локальных приложений в GCP, так как это требует минимальных изменений. Позже они могут выбрать использование других сервисов GCP для отдельного компонента своих приложений.
Google App Engine
GAE - первая услуга, предлагаемая GCP (задолго до того, как Google пришел в облачный бизнес). Он автоматически масштабируется от 0 до неограниченного количества экземпляров (внизу используется GCE). Поставляется с двумя вкусами: Стандартная среда и Гибкая среда.
Стандартная среда действительно быстрая, масштабируется до 0 экземпляров, когда никто не использует ваше приложение, масштабируется вверх и вниз за секунды и имеет специальные службы и библиотеки Google для кэширования, аутентификации и т. Д. Предостережение со стандартной средой заключается в том, что она очень ограничительна поскольку он работает в песочнице. Вы должны использовать управляемые среды выполнения только для определенных языков программирования. Недавние дополнения - это Node.js (8.x) и Python 3.x. Более старые среды выполнения доступны для Go, PHP, Python 2.7, Java и т. Д.
Гибкая среда более открыта, поскольку позволяет использовать настраиваемые среды выполнения, поскольку в ней используются контейнеры докеров. Таким образом, если ваша среда выполнения недоступна в предоставленных средах выполнения, вы всегда можете создать свой собственный файл докеров для среды выполнения. Предостережение в том, что для этого требуется, чтобы был запущен хотя бы 1 экземпляр, даже если никто не использует ваше приложение, плюс для увеличения и уменьшения масштаба требуется несколько минут.
Не путайте GAE flexible с Kubernetes Engine, поскольку последний использует настоящие Kubernetes и предоставляет гораздо больше настроек и функций. GAE Flex полезен, когда вам нужны контейнеры без сохранения состояния, а ваше приложение полагается только на протоколы HTTP или HTTPS. Для других протоколов вы можете выбрать только Kubernetes Engine (GKE) или GCE. Проверьте другой мой ответ для лучшего объяснения.
Если вы знакомы с другими популярными сервисами:
Google Compute Engine -> AWS EC2
Google App Engine -> Heroku или AWS Elastic Beanstalk
Облачные функции Google -> Функции AWS Lambda
Я объясню это так, чтобы было понятно:
Compute Engine: если вы работаете самостоятельно или у вас есть ИТ-команда, и вы просто хотите арендовать компьютер в облаке с определенной ОС (например, Linux), вы выбираете Compute Engine. . Ты должен все делать сам.
App Engine: если вы (например) программист на Python и хотите арендовать предварительно настроенный компьютер в облаке с Linux с работающим веб-сервером и последней версией Python 3 с необходимыми модулями и некоторые плагины для интеграции с другими внешними службами, вы выбираете App Engine.
Бессерверный контейнер (Cloud Run): если вы хотите развернуть точный образ вашей локальной среды установки (например: python 3.7 + flask + sklearn), но не хотите иметь дело с сервером, масштабирование и т. д. Вы создаете контейнер на своем локальном компьютере (через докер), а затем развертываете его в Google Run.
Бессерверный микросервис (облачные функции): если вы хотите написать набор API (функций), выполняющих определенную работу, вы выбираете облачные функции Google. Вы просто сосредотачиваетесь на этих конкретных функциях, остальная часть работы (сервер, обслуживание, масштабирование и т. Д.) Выполняется за вас, чтобы представить ваши функции как микросервисы.
По мере того, как вы идете глубже, вы теряете некоторую гибкость, но вас не беспокоят ненужные технические аспекты. Вы также платите немного больше, но экономите время и деньги (ИТ-часть): кто-то другой (Google) делает это за вас.
Если вы не хотите заботиться о балансировке нагрузки, масштабировании и т. Д., Крайне важно разделить ваше приложение на группу веб-сервисов без сохранения состояния, которые записывают что-либо постоянное в отдельное хранилище (база данных или хранилище BLOB-объектов). Тогда вы убедитесь, насколько хороши Cloud Run и Cloud Functions.
Лично я нашел Google Cloud Run отличным решением, абсолютной свободой в разработке (при условии отсутствия состояния), выставить его как веб-службу, докернуть свое решение, развернуть с помощью Cloud Run. Пусть Google будет вашим ИТ-отделом и DevOps, вам не нужно заботиться о масштабировании и обслуживании.
Я перепробовал все другие варианты, и каждый из них подходит для разных целей, но Google Run просто потрясающий. Для меня это настоящий бессерверный продукт без потери гибкости в разработке.
App Engine дает разработчикам возможность управлять ядрами Google Compute Engine, а также предоставляет веб-интерфейс для приложений обработки данных Google Compute Engine.
С другой стороны, Compute Engine предлагает прямое и полное управление операционной системой ваших виртуальных машин. Чтобы представить свое приложение, вам потребуются ресурсы, а Google Cloud Storage идеально подходит для хранения ваших активов и данных, для чего бы они ни использовались. Вы получаете быстрый доступ к данным благодаря хостингу по всему миру. Гарантированная надежность составляет 99,95% времени безотказной работы, и Google также предоставляет возможность резервного копирования и восстановления ваших данных, и, хотите верьте, хотите нет, хранилище не ограничено.
Вы можете управлять своими активами с помощью Google Cloud Storage, хранить, извлекать, отображать и удалять их. Вы также можете быстро читать и писать в плоские таблицы данных, которые хранятся в облачном хранилище. Следующим в линейке Google Cloud идет BigQuery. С BigQuery вы можете анализировать огромные объемы данных, мы говорим о миллионах записей, за секунды. Доступ осуществляется через простой пользовательский интерфейс, передачу репрезентативного состояния или интерфейс REST.
Хранение данных, как вы могли догадаться, не проблема и масштабируется до сотен ТБ. BigQuery доступен через множество клиентских библиотек, в том числе для Java, .NET, Python, Go, Ruby, PHP и Javascript. Доступен SQL-подобный синтаксис под названием NoSQL, доступ к которому можно получить через эти клиентские библиотеки или через пользовательский веб-интерфейс. Наконец, давайте поговорим о вариантах базы данных платформы Google Cloud, Cloud SQL и Cloud Datastore.
Есть большая разница. Cloud SQL предназначен для реляционных баз данных, в первую очередь MySQL, тогда как Cloud Datastore предназначен для нереляционных баз данных, использующих noSQL. С Cloud SQL у вас есть выбор между хостингом в США, Европе или Азии, со 100 ГБ хранилища и 16 ГБ ОЗУ на экземпляр базы данных.
Cloud Datastore доступен бесплатно для до 50 КБ инструкций чтения / записи в месяц и 1 ГБ данных, хранящихся также в месяц. Однако за превышение этих квот взимается комиссия. App Engine также может работать с другими менее известными и более целевыми участниками платформы Google Cloud, включая конечные точки облака для создания серверных программ API, API Google Prediction для анализа данных и прогнозирования тенденций или API Google Translate для многоязычного вывода.
Несмотря на то, что вы можете сделать довольно много с помощью App Engine самостоятельно, его потенциал резко возрастет, если учесть его способность легко и эффективно работать с другими службами платформы Google Cloud.
Google Compute Engine (GCE)
Виртуальные машины (ВМ) размещены в облаке. До появления облака их часто называли виртуальными частными серверами (VPS). Вы бы использовали их так же, как и физический сервер, где вы устанавливаете и настраиваете операционную систему, устанавливаете свое приложение, устанавливаете базу данных, обновляете ОС и т. Д. Это известно как Инфраструктура. как услуга (IaaS).
Виртуальные машины наиболее полезны, когда у вас есть существующее приложение, работающее на виртуальной машине или сервере в вашем центре обработки данных, и вы хотите легко перенести его в GCP.
Google App Engine
App Engine размещает и запускает ваш код, не требуя от вас работы с операционной системой, сетью и многими другими вещами, которыми вам придется управлять с помощью физического сервера или виртуальной машины. Думайте об этом как о среде выполнения, которая может автоматически развертывать, версии и масштабировать ваше приложение. Это называется «платформа как услуга» (PaaS).
App Engine наиболее полезен, когда вам нужно автоматическое развертывание и автоматическое масштабирование вашего приложения. Если вашему приложению не требуется настраиваемая конфигурация ОС, App Engine часто дает преимущество перед настройкой виртуальных машин и управлением ими вручную.
Облачные сервисы предоставляют широкий спектр возможностей - от полностью управляемых до менее управляемых. Менее управляемые сервисы дают разработчикам больше контроля. То же самое и в вычислительном движке и в движке приложений. На изображении ниже подробно рассматривается этот вопрос 
