Как посмотреть баланс google cloud

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

В марте 2020 года, когда COVID поразил весь мир, наш стартап Milkie Way тоже сильно пострадал и почти закрылся. Мы сожгли 72 000 долларов во время изучения и внутреннего тестирования Cloud Run с Firebase в течение нескольких часов.

Я начал разработку сервиса Announce в ноябре 2019 года. Главная цель состояла в выпуске минимально функциональной первой версии продукта, поэтому код работал на простом стеке. Мы использовали JS, Python и развернули наш продукт на Google App Engine.

С очень маленькой командой мы сосредоточились на написании кода, разработке пользовательского интерфейса и подготовке продукта. Я практически не тратил времени на управление облаком — потратил ровно столько, чтобы поднять систему и обеспечить базовый процесс разработки (CI/CD).

Десктопный Announce

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

Разве не здорово сгенерировать на платформе немного данных, когда пользователи ещё не закачали свою информацию? Эта мысль привела к появлению другого проекта Announce-AI для генерации контента. Богатые данные — это различные события, такие как оповещения о землетрясениях и, возможно, релевантные местные новости.

Некоторые технические детали

Для начала разработки Announce-AI мы использовали Cloud Functions. Поскольку наш бот для скрапинга был ещё на начальной стадии, мы решили взять эти легковесные функции. Но при масштабировании возникли проблемы, потому что у облачных функций тайм-аут около 9 минут.

И вдруг мы узнали о системе Cloud Run, у которой тогда был большой лимит бесплатного использования! Не разобравшись полностью, я попросил команду развернуть «тестовую» функцию Announce-AI в Cloud Run и оценить её производительность. Цель состояла в том, чтобы поиграться с Cloud Run для накопления опыта.

Google Cloud Run

Поскольку у нас очень маленький сайт, то для простоты мы использовали БД Firebase, так как у Cloud Run нет никакого хранилища, а деплой SQL Server или другую БД слишком чрезмерен для теста.

Я создал новый проект GCP ANC-AI Dev, настроил бюджет облачного биллинга на 7 долларов, сохранил проект Firebase по бесплатному плану (Spark). Худший вариант, который мы представляли, — это превышение ежедневного лимита Firebase.

После некоторых модификаций мы подготовили код, сделали несколько запросов вручную, а затем оставили его работать.

Кошмар начинается

В день тестирования всё прошло нормально, и мы вернулись к разработке Announce. На следующий день после работы ближе к вечеру я пошёл слегка вздремнуть. Проснувшись, я увидел несколько писем из Google Cloud, все с интервалом в несколько минут.

Первое письмо: автоматический апгрейд нашего проекта Firebase

Второе письмо: бюджет превышен

Третье письмо: карта отклонена

Проблема была в том, что с каждой минутой счёт продолжал расти.

К этому времени мы с командой были на телеконференции, я был в полном шоке и не имел абсолютно никакого понятия, что делать дальше. Мы отключили биллинг, закрыли все сервисы.

Поскольку во всех проектах GCP мы рассчитывались одной картой, все наши учётные записи и проекты были приостановлены.

Кошмар продолжается

Все наши облачные проекты приостановлены, разработка остановлена

Как только разум смирился с новой реальностью, в полночь я решил нормально разобраться, что же произошло. Я начал составлять документ с подробным расследованием инцидента… и назвал его «Глава 11» [это глава из закона о банкротстве — прим. пер.].

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

На следующее утро, в субботу 28 марта, я позвонил и написал письма десятку юридических фирм, чтобы записаться на приём или поговорить с адвокатом. Все они были в отъезде, но я смог получить ответ от одного из них по электронной почте. Поскольку детали инцидента настолько сложны даже для инженеров, объяснить это адвокату на простом английском языке было само по себе непросто.

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

Некоторая передышка: лазейки GCP

GCP и Firebase

1. Автоматический апгрейд аккаунта Firebase на платный аккаунт

Мы такого не ожидали, и об этом нигде не предупреждалось при регистрации на Firebase. Наш биллинг GCP был подключён к исполнению Cloud Run, но Firebase шла под бесплатным планом (Spark). GCP просто ни с того ни с сего провела апгрейд на платный тариф и взяла с нас необходимую сумму.

Оказывается, этот процесс у них называется «глубокая интеграция Firebase и GCP».

2. Биллинговых «лимитов» не существует. Бюджеты запаздывают минимум на сутки

Выставление счетов GCP фактически задерживается как минимум на сутки. В большинстве документов Google предлагает использовать бюджеты и функцию автоматического отключения облака. Но к тому времени, когда сработает функция отключения или пользователю пришлют уведомление, ущерб уже будет нанесён.

Синхронизация биллинга занимает около суток, именно поэтому мы заметили счёт на следующий день.

3. Google должен был взять 100 долларов, а не 72 тысячи!

Поскольку с нашего аккаунта до сих пор не проходило никаких платежей, GCP должен был сначала взять плату в размере 100 долларов в соответствии с платёжной информацией, а при неуплате — прекратить услуги. Но этого не произошло. Я понял причину позже, но это тоже не по вине пользователя!

4. Не полагайтесь на панель управления Firebase!

Не только биллинг, но и обновление панели управления Firebase заняло более 24-х часов.

Согласно документации Firebase Console, цифры в панели управления могут «незначительно» отличаться от отчётов биллинга.

В нашем случае они отличались на 86 585 365,85%, или 86 миллионов процентных пунктов. Даже когда пришёл счёт, панель управления Firebase Console ещё показывала 42 000 операций чтения и записи в месяц (ниже дневного лимита).

Новый день, новый вызов

Отработав шесть с половиной лет в Google и написав десятки проектных документов, отчётов с расследованиями событий и много другого, я начал составлять документ для Google, описывая инцидент и добавляя лазейки со стороны Google в отчёт. Команда Google вернётся на работу через два дня.

Поправка: некоторые читатели предположили, что я использовал свои внутренние контакты в Google. На самом деле я ни с кем не общался и выбрал путь, по которому пошёл бы любой нормальный разработчик или компания. Как и любой другой мелкий разработчик, я проводил бесчисленные часы в чате, за консультациями, составлением длинных электронных писем и сообщений об ошибках. В одной из следующих статей, посвящённой составлению отчётов об инцидентах, я покажу документы, которые отправил в Google.

Последний день в Google

Кроме того, нужно было понять наши ошибки и разработать стратегию развития продукта. Не все в команде знали об инциденте, но было совершенно ясно, что у нас большие неприятности.

В Google я сталкивался с человеческими ошибками ценой в миллионы долларов, но культура Google спасает сотрудников (за исключением того, что инженерам приходится потом сочинять длинные отчёты). На этот раз Гугла не было. На карту поставлен наш собственный маленький капитал и наша тяжёлая работа.

Стойкие Гималаи нам говорят…

В то время у меня работала команда из семи инженеров и стажёров, и Google требовалось около десяти дней, чтобы ответить нам по поводу этого инцидента. Тем временем мы должны были возобновить разработку, найти способ обойти приостановку счетов. Несмотря на всё, мы должны были сосредоточиться на функциях и нашем продукте.

Стихотворение «Стойкие Гималаи нам говорят»

Почему-то у меня в голове постоянно крутилось одно стихотворение из детства. Это была моя любимая книга, и я помнил её слово в слово, хотя в последний раз читал более 15 лет назад.

Что мы на самом деле сделали?

Будучи очень маленькой командой, мы хотели как можно дольше воздержаться от расходов на аппаратное обеспечение. Проблема Cloud Functions и Cloud Run заключалась в тайм-ауте.

Один инстанс будет постоянно скрапить URL-адреса со страницы. Но через 9 минут наступит тайм-аут.

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

Концепт Announce-AI на Cloud Run

Чтобы преодолеть ограничение тайм-аута, я предложил использовать POST-запросы (с URL в качестве данных) для отправки заданий в инстанс и — запускать параллельно несколько инстансов, а не составлять очередь для одного. Поскольку каждый инстанс в Cloud Run скрапит только одну страницу, тайм-аут никогда не наступит, все страницы будут обрабатываться параллельно (хорошее масштабирование), а процесс высоко оптимизирован, поскольку использование Cloud Run происходит с точностью до миллисекунд.

Скрапер на Cloud Run

Если присмотреться, в процессе не хватает нескольких важных деталей.

Сводка транзакций на конец месяца для GCP

116 миллиардов операций чтения и 33 миллиона записей

Экспериментальная версия нашего приложения на Cloud Run сделала 116 миллиардов операций чтения и 33 миллиона записей в Firestore. Ох!

Стоимость операций чтения на Firebase:

16 000 часов работы Cloud Run

После тестирования из остановки логов мы сделали вывод, что запрос умер, но на самом деле он ушёл в фоновый процесс. Поскольку мы не удалили сервисы (мы первый раз использовали Cloud Run, и тогда действительно не понимали этого), то несколько сервисов продолжали медленно работать.

За 24 часа все эти службы на 1000 инстансах отработали в общей сложности 16 022 часа.

Все наши ошибки

Деплой ошибочного алгоритма в облаке

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

Деплой Cloud Run с параметрами по умолчанию

При создании службы Cloud Run мы выбрали в ней значения по умолчанию. Максимальное число инстансов 1000, а параллелизм — 80 запросов. Мы не знали, что эти значения на самом деле наихудший сценарий для тестовой программы.

Если бы мы выбрали max-instances=2, затраты были бы в 500 раз меньше.

Если бы установили concurrency=1, то даже не заметили бы счёт.

Использование Firebase без полного понимания

Кое-что понимаешь только на опыте. Firebase — это не язык, который можно выучить, это контейнерная платформа. Её правила определены конкретной компанией Google.

Кроме того, при написании кода на Node.js нужно подумать о фоновых процессах. Если код уходит в фоновые процессы, разработчику нелегко узнать, что служба работает. Как мы позже узнали, это ещё и стало причиной большинства таймаутов наших Cloud Functions.

Быстрые ошибки и быстрые исправления — плохая идея в облаке

Облако в целом похоже на обоюдоострый меч. При правильном использовании он может быть очень полезен, но при неправильном — пеняй на себя.

Если посчитать количество страниц в документации GCP, то можно издать несколько толстенных томов. Чтобы всё понять, в том числе тарификацию и использование функций, требуется много времени и глубокое понимание, как работают облачные сервисы. Неудивительно, что для этого нанимают отдельных сотрудников на полный рабочий день!

Firebase и Cloud Run действительно мощны

На пике Firebase обрабатывает около миллиарда считываний в минуту. Это исключительно мощный инструмент. Мы играли с Firebase уже два-три месяца — и всё ещё открывали новые аспекты, но до того момента я понятия не имел, насколько мощная это система.

То же самое относится и к Cloud Run! Если установить количество параллельных процессов 60, max_containers == 1000, то при запросах по 400 мс Cloud Run может обрабатывать 9 миллионов запросов в минуту!

Для сравнения, поиск Google обрабатывает 3,8 миллиона запросов в минуту.

Используйте мониторинг

Хотя Google Cloud Monitoring не остановит биллинг, он отправляет своевременные оповещения (задержка 3-4 минуты). Поначалу не так просто освоить терминологию Google Cloud, но если вы потратите время, то панель мониторинга, оповещения и метрики немного облегчат вашу жизнь.

Эти метрики доступны только в течение 90 дней, у нас они уже не сохранились.

Мы выжили

Фух, пронесло

Изучив наш длинный отчёт об инциденте, описывающий ситуацию с нашей стороны, после различных консультаций, бесед и внутренних обсуждений, Google простила нам счёт!

Спасибо тебе, Google!

Мы схватили спасательный круг и использовали эту возможность, чтобы завершить разработку продукта. На этот раз — с гораздо лучшим планированием, архитектурой и намного более безопасной реализацией.

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

(Примечание: это моё личное мнение как индивидуального разработчика. Наша компания никоим образом не спонсируется и не связана с Google).

Что дальше?

После этого случая мы потратили несколько месяцев на изучение облака и нашей архитектуры. За несколько недель моё понимание улучшилось настолько, что я мог прикинуть стоимость скрапинга «всего интернета» с помощью Cloud Run с улучшенным алгоритмом.

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

Во второй версии Announce мы не просто создали MVP, мы создали платформу, на которой могли быстрыми итерациями разрабатывать новые продукты и тщательно тестировать их в безопасной среде.

Это путешествие заняло немало времени… Announce запущен в конце ноября, примерно через семь месяцев после первой версии, но он очень масштабируемый, берёт лучшее из облачных сервисов и высоко оптимизирован.

Мы также запустились на всех платформах, а не только в интернете.

Более того, мы повторно использовали платформу для создания нашего второго продукта — Point Address. Он тоже отличается масштабируемостью и хорошей архитектурой.

Источник

GCP: Разбор вычислительного стека Google Cloud Platform

Перевод статьи подготовлен специально для студентов курса «Облачные сервисы».

Интересно развиваться в данном направлении? Смотрите запись профессионального мастер-класса «AWS EC2 сервис», который провёл Егор Зуев — TeamLead в компании InBit и автор образовательной программы в OTUS.

Google Cloud Platform (GCP) предлагает множество сервисов, и в частности вычислительный стек, который содержит Google Compute Engine (GCE), Google Kubernetes Engine (ранее — Container Engine) (GKE), Google App Engine (GAE) и Google Cloud Functions (GCF). Все эти сервисы имеют крутые названия, но могут быть не совсем очевидными в отношении их функций и того, что делает их уникальными по отношению друг к другу. Эта статья предназначена для тех, кто только знакомится с облачными концепциями, в частности с облачными сервисами и GCP.

1. Вычислительный стек

Вычислительный стек можно рассматривать как многоуровневую абстракцию над тем, что может предоставить компьютерная система. Этот стек восходит (moves up) от «голого железа» (bare metal), относящегося к фактическим аппаратным компонентам компьютера, вплоть до функций (functions), которые представляют собой наименьшую единицу вычисления. Что важно отметить в отношении стека, так это то, что сервисы агрегируются при перемещении вверх по стеку, например, раздел «приложения» (apps), показанный на рисунке 1 ниже, должен содержать все базовые компоненты контейнеров (containers), виртуальных машин (virtual machines) и железа. Таким же образом компонент виртуальных машин должен содержать железо внутри для работы.

Рисунок 1: Вычислительный стек | Изображение получено из Google Cloud

Эта модель, показанная на рисунке 1, является основой для описания предложений от облачных провайдеров. Таким образом, некоторые провайдеры могут предоставлять только, например, контейнеры и услуги ниже качеством по стеку, а другие — все, что показано на рисунке 1.

— Если вы знакомы с облачными сервисами, переходите к разделу 3, чтобы ознакомиться с эквивалентом GCP
— Если вам нужна только сводка по облачным сервисам, переходите к разделу 2.4

2. Облачные сервисы

Мир облачных вычислений очень разнообразен. Облачные провайдеры предлагают множество услуг, адаптированных к различным требованиям клиентов. Возможно, вы слышали о таких терминах, как IaaS, PaaS, SaaS, FaaS, KaaS и т.д. со всеми буквами алфавита, за которыми следует «aaS». Несмотря на странное соглашение об именовании, они образуют набор сервисов облачных провайдеров. Я констатирую, что есть 3 основных предложения «как услуга» (as a Service), которые облачные провайдеры почти всегда предоставляют.

Это IaaS, PaaS и SaaS, которые обозначают соответственно инфраструктуру как услугу (Infrastructure as a Service), платформу как услугу (Platform as a Service) и программное обеспечение как услугу (Software as a Service). Важно визуализировать облачные сервисы как уровни предоставляемых услуг. Это означает, что когда вы поднимаетесь или спускаетесь с уровня на уровень, вы, как клиент, пересекаете различные варианты обслуживания, которые либо добавляются, либо убираются из основного предложения. Лучше всего рассматривать это как пирамиду, как показано на рисунке 2.

Рисунок 2: Пирамида «aaS» | Изображение получено из Ruby Garage

2.1 Инфраструктура как услуга (IaaS)

Это самый низкий уровень, который может предложить поставщик облачных услуг, и он включает провайдера облачных вычислений, поставляющего «голую» инфраструктуру, включая промежуточное программное обеспечение, сетевые кабели, процессоры, графические процессоры, оперативную память, внешнее хранилище, серверы и образы базовых операционных систем, например, Debian Linux, CentOS, Windows и т. д.

Если закажите у поставщика облачных услуг IaaS предложение, то это то, что вы должны ожидать получить. За вами, как за клиентом, остается сборка этих частей для ведения вашего бизнеса. Степень того, с чем вам придется работать, может варьироваться от поставщика к поставщику, но, как правило, вы просто получаете аппаратное обеспечение и ОС, а остальное за вами. Примерами IaaS являются AWS Elastic Compute, Microsoft Azure и GCE.

Некоторым людям может не понравиться тот факт, что им приходится устанавливать образы ОС и заниматься сетью, балансировкой нагрузки или заботиться о том, какой тип процессора идеально подходит для их рабочей нагрузки. Именно здесь мы двигаемся вверх по пирамиде к PaaS.

2.2 Платформа как услуга (PaaS)

PaaS включает в себя только поставщика облачных услуг, предлагающего определенную платформу, на которой пользователи могут создавать приложения. Это абстракция над IaaS, означающая, что поставщик облака берет на себя все детали типов ЦП, памяти, ОЗУ, хранилища, сетей и т. д. Как показано на рисунке 2, вы, как клиент, имеете небольшой контроль над реальной платформой, поскольку облачный провайдер занимается всеми деталями инфраструктуры за вас. Вы запрашиваете выбранную платформу и собираете на ней проект. Примерам PaaS являютс Heroku.

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

2.3 Программное обеспечение как услуга (SaaS)

SaaS представляет собой наиболее распространенные сервисы, предоставляемые поставщиками облачных услуг. Они предназначены для конечных пользователей и доступны главным образом через веб-сайты, например Gmail, Google Docs, Dropbox и т. д. Что касается Google Cloud, есть несколько предложений вне их вычислительного стека, которые являются SaaS. К ним относятся Data Studio, Big Query и т. д.

2.4 Сводка по облачным сервисам

Рисунок 3: Сводка основных облачных предложений | Изображение предоставлено Amir at Blog Specia

3. Вычислительный пакет Google Cloud Platform

Рассмотрев типичные предложения облачных провайдеров в разделе 2, мы можем сопоставить их с предложениями Google Cloud.

3.1 Google Compute Engine (GCE) — IaaS

Рисунок 4: Иконка Google Compute Engine (GCE)

GCE — это IaaS предложение от Google. С GCE вы можете свободно создавать виртуальные машины, распределять ресурсы процессора и памяти, выбирать тип хранилища, например SSD или HDD, а также объем памяти. Это почти так же, как если бы вы создали свой собственный компьютер/рабочую станцию и занимались всеми деталями его работы.

В GCE вы можете выбрать от микро инстанций с 0,3-ядерным процессорами и 1 ГБ ОЗУ до 96-ядерных монстров с более чем 300 ГБ ОЗУ. Вы также можете создавать виртуальные машины нестандартного размера для своих рабочих нагрузок. Для тех, кто заинтересовался — это виртуальные машины, которые вы можете собрать.

3.2. Google Kubernetes Engine (GKE) — (Caas / Kaas)

Рисунок 5: Иконка Google Kubernetes Engine (GKE)

GKE — это уникальное вычислительное предложение от GCP, которое представляет собой абстракцию над Compute Engine. В более общем смысле GKE можно отнести к категории «Контейнер как услуга» (CaaS), иногда называемой «Kubernetes как услуга» (KaaS), который позволяет клиентам легко запускать свои Docker-контейнеры в полностью управляемой среде Kubernetes. Для тех, кто не знаком с контейнерами, контейнеры помогают модульно формировать сервисы/приложения, поэтому разные контейнеры могут содержать разные сервисы, например, один контейнер может размещать интерфейс вашего веб-приложения, а другой может содержать его серверную часть. Kubernetes выполняет автоматизацию, координацию, управление и развертывание ваших контейнеров. Больше информации здесь.

3.3 Google App Engine (GAE) — (PaaS)

Рисунок 6: Иконка Google App Engine (GAE)

Как упомянуто в разделе 2.2, PaaS находится выше IaaS, и в случае GCP его также можно рассматривать как предложение над GKE. GAE — это специализированный Google PaaS, и как они сами лучше всего описывают себя — «несите ваш код, а мы позаботимся обо всем остальном».

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

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

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

По моему мнению, GAE — это лучшее место для старта, если вы разработчик с отличной идеей, но не хотите заниматься рутинной работой по настройке серверов, балансировкой нагрузки и всей другой трудоемкой devops/SRE работой. Со временем вы могли бы попробовать GKE и GCE, но это только мое мнение.

Дисклеймер: AppEngine используется для веб-приложений, а не мобильных приложений.

3.4 Google Cloud Functions — (FaaS)

Рисунок 7: Иконка Google Cloud Functions (GCF)

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

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

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

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

Заключение

В этой статье мы говорили о различных облачных предложениях, например IaaS, PaaS и т. д., и как стек вычислений Google реализует эти различные уровни. Мы видели, что уровни абстракции при переходе из одной категории услуг в другую, например, IaaS в Paas, требуют меньше знаний о лежащей в основе.

Для бизнеса это обеспечивает критически важную гибкость, которая не только отвечает его оперативным целям, но также удовлетворяет другим ключевым областям, таким как безопасность и стоимость. Обобщая:

Compute Engine — позволяет вам создать свою собственную виртуальную машину, выделяя определенные аппаратные ресурсы, например, ОЗУ, процессор, память. Он так же достаточно практичный и низкоуровневый.

Kubernetes Engine — это шаг выше по сравнению с Compute Engine, который позволяет вам использовать Kubernetes и контейнеры для управления вашим приложением, позволяя при необходимости масштабировать его.

App Engine — это шаг выше по сравнению с Kubernetes Engine, позволяющий вам сосредоточиться только на своем коде, в то время как Google обеспечивает все требования базовой платформы.

Cloud-Functions — это вершина вычислительной пирамиды, позволяющая написать простую функцию, которая при запуске использует всю базовую инфраструктуру для вычисления и возврата результата.

Источник