В чем разница между Google App Engine и Google Compute Engine?

Мне было интересно, в чем разница между App Engine и Compute Engine. Может кто-нибудь объяснить мне разницу?

App Engine - это платформа как услуга. Это означает, что вы просто развертываете свой код, а платформа делает все остальное за вас. Например, если ваше приложение станет очень успешным, App Engine автоматически создаст больше экземпляров для обработки увеличенного объема.

Узнайте больше о App Engine

Compute Engine - это инфраструктура как услуга. Вы должны создать и настроить свои собственные экземпляры виртуальной машины. Это дает вам больше гибкости и, как правило, стоит намного дешевле, чем App Engine. Недостатком является то, что вы должны сами управлять своим приложением и виртуальными машинами.

Узнайте больше о Compute Engine

При необходимости вы можете смешивать как App Engine, так и Compute Engine. Они оба хорошо работают с другими частями облачной платформы Google .

РЕДАКТИРОВАТЬ (май 2016 г.):

Еще одно важное различие: проекты, работающие на App Engine, могут уменьшаться до нуля, если запросы не поступают. Это очень полезно на этапе разработки, поскольку вы можете работать неделями, не выходя за щедрую бесплатную квоту часов-экземпляров. Гибкое время выполнения (т. Е. «Управляемые виртуальные машины») требует, чтобы хотя бы один экземпляр работал постоянно.

РЕДАКТИРОВАТЬ (апрель 2017 г.):

Облачные функции (в настоящее время в бета-версии) - это следующий уровень от App Engine с точки зрения абстракции - никаких примеров! Это позволяет разработчикам развертывать фрагменты кода размером с кусочек, которые выполняются в ответ на различные события, которые могут включать HTTP-запросы, изменения в облачном хранилище и т. Д.

Самое большое отличие от App Engine заключается в том, что функции оцениваются за 100 миллисекунд, а экземпляры App Engine отключаются только после 15 минут бездействия. Другое преимущество состоит в том, что облачные функции выполняются немедленно, в то время как для вызова App Engine может потребоваться новый экземпляр, а холодный запуск нового экземпляра может занять несколько секунд или дольше (в зависимости от времени выполнения и вашего кода).

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

Узнайте больше о облачных функциях

Основное отличие состоит в том, что Google App Engine ( GAE ) - это платформа как услуга ( PaaS ), а Google Compute Engine ( GCE ) - это инфраструктура как услуга ( IaaS ) .

Чтобы запустить ваше приложение в GAE, вам просто нужно написать свой код и развернуть его в GAE, никакой другой головной боли. Поскольку GAE является полностью масштабируемым, оно автоматически получит больше экземпляров в случае увеличения трафика и уменьшит количество экземпляров при уменьшении трафика. Вы будете платить за ресурсы, которые вы действительно используете , я имею в виду, вы будете платить за часы-инстансы , переданные данные , хранилище и т. Д., Которое действительно использовало ваше приложение. Но есть ограничение: вы можете создавать свое приложение только на 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 (Standard) - это как песочница, доступная только для чтения, куда вы загружаете код для выполнения и не беспокоитесь об остальном (да: только для чтения - для вас установлен фиксированный набор библиотек, и вы не можете его развернуть Сторонние библиотеки по желанию). DNS / субдомены и т. Д. Намного проще сопоставить.

Google App Engine (гибкий) на самом деле похож на целую файловую систему (не просто заблокированную папку), где у вас больше мощности, чем у стандартного механизма, например, у вас есть права на чтение / запись (но меньше по сравнению с Compute Engine ). В стандарте GAE у вас установлен фиксированный набор библиотек, и вы не можете развертывать сторонние библиотеки по своему желанию. В гибкой среде вы можете установить любую библиотеку, от которой зависит ваше приложение, включая пользовательские среды сборки (например, Python 3).

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

В дополнение к примечаниям App Engine и Compute Engine, приведенным выше, список также включает сравнение с Google Kubernete Engine и некоторые примечания, основанные на опыте работы с широким спектром приложений от маленьких до очень больших. Дополнительные сведения см. В описании высокого уровня документации по Google Cloud Platform в App Engine Standard и Flex на странице Выбор среды App Engine . Еще одно сравнение развертывания App Engine и Kubernetes смотрите в публикации Daz Wilkin App Engine Flex или Kubernetes Engine .

Стандарт App Engine

Pros

• Очень экономичен для приложений с низким трафиком с точки зрения прямых затрат, а также затрат на обслуживание приложения.
• Авто масштабирование быстро. Автоматическое масштабирование в 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 по умолчанию относительно безопасна.

Cons

• Как правило, более ограничены, чем в других средах. Экземпляры меньше. Хотя это полезно для быстрого автоматического масштабирования, многие приложения могут получить выгоду от более крупных экземпляров, таких как размеры экземпляров GCE до 96 ядер.
• Сеть не интегрирована с GCE
• Невозможно установить App Engine за Google Cloud Load Balancer. Ограничено поддерживаемыми средами исполнения: Python 2.7, Java 7 и 8, Go 1.6-1.9 и PHP 5.5. В Java есть некоторая поддержка сервлетов, но не полный стандарт J2EE.

App Engine Flex

Pros

• Можно использовать пользовательскую среду выполнения
• Встроенная интеграция с сетью GCE
• Управление версиями и трафиком удобно, так же как и в Standard
• Большие размеры экземпляров могут быть более подходящими для больших сложных приложений, особенно приложений Java, которые могут использовать много памяти

Cons

• Сетевая интеграция не идеальна - нет интеграции с внутренними балансировщиками нагрузки или общими виртуальными частными облаками
• Доступ к управляемой Memcache недоступен

Google Kubernetes Engine

Pros

• Встроенная интеграция с контейнерами позволяет настраивать время выполнения и лучше контролировать конфигурацию кластера.
• Содержит множество рекомендаций по работе с виртуальными машинами, такими как неизменяемые среды выполнения и простая возможность отката к предыдущим версиям.
• Обеспечивает согласованную и повторяемую структуру развертывания
• На основе открытых стандартов, в частности Kubernetes, для переносимости между облаками и локальными системами.
• Управление версиями может осуществляться с помощью контейнеров Docker и реестра контейнеров Google.

Cons

• Разделение и управление трафиком сделай сам, возможно, используя Istio и Envoy
• Некоторые накладные расходы на управление
• Некоторое время, чтобы освоить концепции Kubernetes, такие как модули, развертывания, службы, вход и пространства имен
• Нужно выставлять некоторые публичные IP-адреса, если только использование Private Clusters (сейчас в бета-версии) не устраняет эту потребность, но вам все равно нужно предоставить доступ к местам, из которых будут запускаться команды kubectl.
• Мониторинг интеграции не совершенен
• В то время как внутренняя балансировка нагрузки L3 поддерживается изначально в Kubernetes Engine, внутренняя балансировка нагрузки L7 выполняется самостоятельно, возможно используя Envoy.

Compute Engine

Pros

• Легко наращивать - не нужно наращивать Kubernetes или App Engine, просто используйте все, что вы знаете из предыдущего опыта. Это, вероятно, основная причина использования Compute Engine напрямую.
• Полный контроль - вы можете напрямую использовать многие функции Compute Engine и устанавливать самые последние из ваших любимых вещей, чтобы оставаться на переднем крае.
• Нет необходимости в публичных IP-адресах. Некоторое устаревшее программное обеспечение может быть слишком сложно заблокировать, если что-либо открыто для публичных IP-адресов.
• Вы можете использовать оптимизированную для контейнера ОС для запуска контейнеров Docker

Cons

• Главным образом сделай сам, что может быть сложно сделать адекватно для надежности и безопасности, хотя вы можете повторно использовать решения из разных мест, включая Cloud Launcher.
• Больше накладных расходов на управление. Существует множество инструментов управления для Compute Engine, но они не обязательно поймут, как вы развернули свое приложение, как это делают инструменты мониторинга App Engine и Kubernetes Engine.
• Автоматическое масштабирование основано на экземплярах GCE, которые могут быть медленнее, чем App Engine
• Тенденция заключается в установке программного обеспечения на экземплярах GCE типа «снежинка», что может потребовать определенных усилий для поддержки

Как уже объяснялось, Google Compute Engine (GCE) - это инфраструктура как услуга (IaaS), а Google App Engine (GAE) - это платформа как услуга (PaaS). Вы можете проверить следующую диаграмму, чтобы лучше понять разницу (взято и объяснено здесь ) -

Google Compute Engine
GCE - это важная служба, предоставляемая Google Cloud Platform (GCP), поскольку большинство служб GCP используют экземпляры GCE (ВМ) под уровнем управления (не знаю, какой из них этого не делает). Это включает в себя App Engine, облачные функции, Kubernetes Engine (ранее контейнерный движок), Cloud SQL и т. Д. Экземпляры GCE являются наиболее настраиваемыми единицами, поэтому их следует использовать только в том случае, если ваше приложение не может работать в каких-либо других службах GCP. В большинстве случаев люди используют GCE для передачи своих приложений On-Prem в GCP, поскольку это требует минимальных изменений. Позже они могут использовать другие службы GCP для отдельных компонентов своих приложений.

Google App Engine
GAE - это первая услуга, предлагаемая GCP (задолго до того, как Google пришел в облачный бизнес). Он автоматически масштабируется от 0 до неограниченного количества экземпляров (внизу используется GCE). Это идет с 2 ароматами Стандартная Среда и Гибкая Среда.

Стандартная среда действительно быстрая, она уменьшается до 0, когда никто не использует ваше приложение, масштабируется за секунды и имеет специальные сервисы и библиотеки Google для кеширования, аутентификации и т. Д. Предостережение со стандартной средой заключается в том, что оно очень ограничительно. так как он работает в песочнице. Вы должны использовать управляемые среды выполнения только для определенных языков программирования. Последние добавления - Node.js (8.x) и Python 3.x. Старые версии доступны для Go, PHP, Python 2.7, Java и т. Д.

Гибкая среда более открыта, так как позволяет использовать пользовательские среды выполнения, так как она использует контейнеры Docker. Таким образом, если ваша среда выполнения недоступна в предоставленных средах исполнения, вы всегда можете создать свой собственный файл Docker для среды выполнения. Предостережение заключается в том, что требуется наличие хотя бы одного экземпляра, даже если ваше приложение никто не использует, плюс для увеличения и уменьшения требуется несколько минут.

Не путайте GAE Flexible с Kubernetes Engine, так как последний использует настоящий Kubernetes и предоставляет гораздо больше возможностей для настройки и функций. GAE Flex полезен, когда вам нужны контейнеры без сохранения состояния, а ваше приложение использует только протоколы HTTP или HTTPS. Для других протоколов Kubernetes Engine (GKE) или GCE - ваш единственный выбор. Проверьте мой другой ответ для лучшего объяснения.

App Engine дает разработчикам возможность контролировать ядра Google Compute Engine, а также предоставлять веб-интерфейс для приложений обработки данных Google Compute Engine.

С другой стороны, Compute Engine предлагает прямое и полное управление операционной системой ваших виртуальных машин. Чтобы представить свое приложение, вам потребуются ресурсы, а облачное хранилище Google идеально подходит для хранения ваших активов и данных, для чего бы они ни использовались. Вы получаете быстрый доступ к данным с хостинга по всему миру. Надежность гарантируется на 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. Благодаря облачному SQL вы можете выбрать хостинг в США, Европе или Азии, со 100 ГБ дискового пространства и 16 ГБ ОЗУ на экземпляр базы данных.

Облачное хранилище данных доступно бесплатно для до 50 К инструкций чтения / записи в месяц и 1 ГБ данных, хранящихся также в месяц. Однако за превышение этих квот взимается плата. Кроме того, App Engine может работать с другими менее известными и более целевыми участниками платформы Google Cloud, включая облачные конечные точки для создания бэкэндов API, Google Prediction API для анализа данных и прогнозирования тенденций или API Google Translate для многоязычного вывода.

Несмотря на то, что вы можете делать немало с помощью App Engine, он может взлететь до небес, если учесть его способность работать легко и эффективно с другими службами платформы Google Cloud.

Если вы знакомы с другими популярными сервисами:

Google Compute Engine -> AWS EC2

Google App Engine -> Heroku или AWS Elastic Beanstalk

Облачные функции Google -> Лямбда-функции AWS

Я объясню это так, чтобы это имело смысл для меня:

• 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) делает это за вас.

Если вы не хотите заботиться о балансировке нагрузки, масштабировании и т. Д., Крайне важно разделить ваше приложение на набор веб-служб без сохранения состояния, которые записывают все постоянные данные в отдельное хранилище (базу данных или хранилище больших двоичных объектов). Тогда вы узнаете, насколько великолепны Cloud Run и Cloud Functions.

Лично я нашел Google Cloud Run отличным решением, абсолютной свободой в разработке (при условии, что он не имеет состояния), выставил его в качестве веб-службы, подключил ваше решение, развернул его с помощью Cloud Run. Пусть Google будет вашим IT и DevOps, вам не нужно заботиться о масштабировании и обслуживании.

Я перепробовал все остальные варианты, и каждый из них хорош для разных целей, но Google Run просто потрясающий. Для меня это настоящий сервер без потери гибкости в разработке.

Облачные сервисы предоставляют широкий спектр возможностей: от полностью управляемых до менее управляемых. Менее управляемые сервисы дают больше контроля разработчикам. Та же разница в Compute и App engine. На изображении ниже более подробно об этом

Google Compute Engine (GCE)

Виртуальные машины (ВМ), размещенные в облаке. До появления облака их часто называли виртуальными частными серверами (VPS). Вы будете использовать их так же, как физический сервер, на котором вы устанавливаете и настраиваете операционную систему, устанавливаете приложение, устанавливаете базу данных, обновляете ОС и т. Д. Это называется инфраструктурой. как услуга (IaaS).

Виртуальные машины наиболее полезны, когда в вашем центре обработки данных запущено существующее приложение на виртуальной машине или сервере, и вы хотите легко перенести его в GCP.

Google App Engine

App Engine размещает и запускает ваш код, не требуя от вас работы с операционной системой, сетью и многими другими вещами, которыми вам придется управлять с физическим сервером или виртуальной машиной. Думайте об этом как о среде выполнения, которая может автоматически развертывать, устанавливать версии и масштабировать ваше приложение. Это называется Платформа как услуга (PaaS).

App Engine наиболее полезен, когда вам нужно автоматическое развертывание и автоматическое масштабирование вашего приложения. Если вашему приложению не требуется настраиваемая конфигурация ОС, App Engine часто имеет преимущество перед настройкой и управлением виртуальными машинами вручную.