Правильные вопросы
Уже больше года я читаю множество статей о Google Cloud Run, некоторые из них сравнивают Cloud Run и облачные функции.
Вывод всегда один и тот же ⇒ Cloud Run лучше, полнее, с большим количеством языков, большим количеством кофе и другими вещами.
Тем не менее, я ждал больше года, прежде чем запустить свой первый рабочий экземпляр Cloud Run.
Несмотря на то, что эта статья, естественно, сравнивает Cloud Run и Cloud Function, ее главная цель — нанести ответный удар лоббистам Cloud Run.
Здесь я покажу, почему Cloud Functions по-прежнему остается очень хорошим продуктом, который следует использовать в некоторых случаях.
Краткое содержание
Простая презентация
Сравнение не является достаточной причиной
Преимущества Cloud Run, которые могут вас не волновать
Cloud Run не идеален
Облачные функции не идеальны
Почему я до сих пор использую Cloud Functions?
Простая презентация
Если вы не так хорошо знакомы с Cloud Function и Cloud Run, посмотрите эту презентацию:
Облачные функции: фрагмент кода, развернутый в Интернете. Ответ на вызовы HTTP или события Google Cloud.
Cloud Run: несколько больших фрагментов кода, развернутых в сети, достаточно больших для создания сервера или чего-либо, что может быть контейнеризировано.
У обоих есть общие черты: из кода, работающего локально, легко выйти в интернет, а остальное управляется Google Cloud. Спасибо за этого дружище!
Сравнение не является достаточной причиной
"Это лучше!"
Сравнение технических характеристик бросается в глаза, мы чувствуем, что многое узнали о самом продукте, и «О, я мог бы получить сертификат»!
Но нас не волнует, что продукт делает или не делает.
Мы не ищем продукт. Мы рассматриваем вариант использования!
Например, с точки зрения времени ожидания мы могли бы сравнить следующие характеристики:
- Облачный бег: 60 минут
- Облачные функции (1-го поколения): 9 минут.
Вау, Cloud Run — это так здорово!
Дело в том, что в 95% случаев мои облачные функции отключаются в течение 2 секунд.
И я думаю, что никогда не видел, чтобы экземпляр Cloud Functions/Cloud Run работал дольше 5 минут. Это может быть возможно при обработке файлов или огромных данных! Это касается меньшинства случаев.
Во многих аспектах Cloud Run — это «больше», чем Cloud Functions. Вы можете сравнить характеристики и посмотреть. Но нужно ли нам это больше?
Сравнение Cloud Run и Cloud Functions может заставить нас думать, что один продукт лучше другого, но оба они соответствуют моим потребностям на 100%. И за исключением сертификата или броского поста в блоге, сравнивать их бессмысленно.
Грузовик круче!
Позвольте мне рассказать вам короткую историю.
История человека, ищущего что-то, что могло бы перевезти его из пункта А в пункт Б.
Лоббисты грузовиков объясняют следующее:
- «На моем грузовике можно проехать тысячи километров!»
- «С моим грузовиком ты можешь возить медведя!»
- «С моим грузовиком вы можете установить кровать и отправиться в путешествие на несколько дней!»
- …
Все эти плюсы действительно крутые (разве что не упомянули воздействие грузовика на окружающую среду).
Дело в том, что кто-то искал что-то, чтобы возить его на работу всего в миле от его дома…
Грузовик — это круто, но у него есть несколько функций, которые совершенно не нужны этому потерянному парню!
Скейтборд тоже подойдет!
Со скейтбордом:
- Нельзя уехать за тысячи километров
- Вы едва можете нести кошку
- Вам повезло, если ваши ноги полностью выходят за пределы доски.
Но необходимость ехать на работу за версту удовлетворена!!
Потребность удовлетворена, и есть еще много преимуществ: экономия денег, меньше загрязнения, нет страховки, нет гаража, нет уборки, нет водительских прав, нет механических проблем…
То же самое происходит при сравнении Cloud Functions и Cloud Run.
Смотрите эту схему:
ОСТАНАВЛИВАТЬСЯ
Эта схема сложнее, чем кажется, чтобы глубже понять ее, прочитайте следующий раздел.
Куда мы идем?
На этом сравнение Truck-Skate и Cloud Run — Cloud Functions заканчивается.
Потому что в реальной жизни можно кататься на скейтборде по будням и на грузовике по выходным. Без проблем.
Но с Cloud Functions и Cloud Run нет особого смысла использовать оба продукта.
Как отметил guillaume blaquiere (еще раз спасибо!):
Проще всего использовать один продукт.
Потому что при использовании Cloud Functions мы будем создавать конвейеры развертывания, процессы тестирования, лучшие практики, терраформы.
И всю эту настройку нельзя использовать для Cloud Run. Мы должны создавать новые пайплайны, тесты, лучшие практики, новые терраформы…
Поскольку Cloud Functions и Cloud Run делают примерно одно и то же, лучше выбрать один из них и освоить его.
И чтобы узнать, какой из них следует выбрать, проверьте предыдущую схему:
- Вы находитесь в желтой зоне или в синей зоне?
- Окажетесь ли вы в желтой или синей зоне менее чем через год?
- Вам нужно ехать быстро, избегать пробок и контейнеров или идти далеко с чем-то более надежным и настраиваемым?
Если вы не являетесь разработчиком и хотите быстро развернуть очень простые сервисы, вы находитесь в желтой зоне.
Если вы открываете для себя инструменты Google Cloud и хотите выполнять различные задачи с помощью GCloud. Возможно, вы находитесь в желтой зоне.
Если ожидается, что ваши услуги будут расти, и вы строите что-то крупное, вы наверняка находитесь в синей зоне, даже если поначалу облачные функции удовлетворяют потребности.
Ой! Также: скейтбординг намного круче!
Преимущества Cloud Run, которые могут вас не волновать
Любой язык
С Cloud Run вы можете использовать любой язык!
Я видел это много раз и… это правда! Это правда и это здорово!
Мы можем развернуть Groovy API с помощью Cloud Run 🥳🍹
С облачными функциями мы полностью застряли, это ужасно, мы можем использовать толькоNodejs, Python, Go, Java, Ruby, PHP и .NET.
Если мы посмотрим на Опрос Stackoverflow 2022, эти языки представляют только то, что все используют ежедневно.
Ситуация та же, что и с таймаутами, о которых я упоминал ранее, мои потребности (и знания) на 100% соответствуют Cloud Functions и Cloud Run.
Большой сервер
Cloud Run идеально подходит для развертывания API, развертывания веб-сервера с несколькими конечными точками, POST, PUT, GET, LINK, PURGE, LOCK…
С Cloud Run развертывание сервера Python занимает всего несколько минут.
Честно говоря, развертывание API с использованием только облачных функций немного болезненно и приводит к потере времени, если API имеет более 3 конечных точек.
Вам нужно развернуть API? Вам нужно будет?
Многие потребности и многие требования не нуждаются в API.
Например:
- Отправить электронное письмо при загрузке файла в облачное хранилище
- Создать минимальный API с независимыми конечными точками
- Перенести файл из AWS S3 в Cloud Storage
- Записать данные в GSheets после HTTP-вызова
- Определить текст из фотографии, хранящейся в облачном хранилище, G Drive…
- И тысячи других случаев
Во многих ситуациях требуются небольшие или очень маленькие фрагменты кода.
Многие ситуации просты, с ними можно справиться с помощью простых облачных функций.
Иногда создание веб-сервера HTTP REST не имеет смысла и еще больше сбивает с толку.
Другие
Есть много других преимуществ использования Cloud Run, о которых мы заботимся! Например, тестирование, контейнеризация… Теперь мы это видим!
Cloud Run не идеален
«Разрыв в обучении небольшой»
В статье лоббиста я это прочитал.
Разрыв в обучении небольшой, это правда. Но все же есть один.
Допустим, у нас есть простая функция (например, в блокноте Jupyter), отвечающая на сообщение Hello!
Функция работает локально, и мы хотим, чтобы она была онлайн.
Чтобы развернуть его с помощью облачных функций, выполните следующие действия:
- Поместите зависимости в файл requirements.txt
- Вставьте функцию в файл main.py
- Запустите эту командную строку для развертывания
gcloud functions deploy hello --region=europe-west2 --trigger-http --entry-point main --runtime python310
Пуф, мы закончили!
Теперь… Если мы хотим использовать Cloud Run…
- Поместите зависимости в файл requirements.txt
- Вставьте функцию в файл main.py
- Оберните свою функцию в платформу Rest Server Framework по вашему выбору.
- Установить Докер
- Создать Dockerfile
- Создайте контейнер и проверьте правильность настройки веб-сервера и контейнера.
- Запустите эту командную строку для развертывания
gcloud run deploy hello --region=europe-west2 --source=$(pwd)
Это немного, если вы привыкли к Docker и серверам.
Но это несколько часов дополнительных занятий для тех, кто не привык к этим технологиям.
А, бывает, и не требуется.
Незначительное изменение может сломать все
С Cloud Run мы можем развертывать серверы.
И при развертывании новой версии маршрута GET/books нам также необходимо развернуть новую версию маршрута POST/books. Даже если ничего не изменилось, нам все равно нужно развернуть полный контейнер!
Что делать, если есть проблема с пакетом? Может случиться так, что вы выбрали не фиксированную версию пакета. Сервер использовал версию 1 Flask, после развертывания он использует версию 2 Flask! И это может (на самом деле) вызвать проблему.
Другой причиной сбоя может быть общая функция, используемая POST /books и GET /books. Как общая функция для аутентификации.
Изменение этой общей функции может привести к сбою другой части (например, если изменится формат ответа.
Это нормально для сервера, верно? Это работает таким образом.
С облачными функциями этого никогда не происходит, и для API с двумя конечными точками я думаю, что именно по этой причине я бы колебался между Cloud Run и облачными функциями.
Нет идентификатора выполнения
Благодаря Cloud Run все журналы со всех конечных точек от всех вызывающих абонентов поступают в одно и то же место.
Если 3 вызова API поступают в одно и то же время в одну и ту же конечную точку, у нас могут быть следующие журналы:
дата-время: Звонок А
дата-время: Звонок Б
дата-время: успех
дата-время: Звонок C
дата-время: успех
дата-время: сбой
И нет абсолютно никакого способа узнать, какой вызов не удался!
Опять же, это нормально для сервера.
Но… как видите, с облачными функциями этого никогда не произойдет!
Для каждого исполнения предусмотрена встроенная функция атрибуции идентификатора выполнения!
Для каждого выполнения вы можете получить идентификатор и проверить, что происходит для этого самого выполнения.
Это выглядит так:
дата-время: 1az23r Звонок А
дата-время: 4df1As Call B
дата-время: 1az23r успех
дата-время: 78eu3e Call C
дата-время: 78eu3e успех
дата-время: сбой 4df1As
(если вы хотите знать, как использовать этот идентификатор с Cloud Functions, отметьте это)
НО
Я существую, и я объяснил, как искусственно создать идентификатор выполнения с помощью Cloud Run.
Это представляет собой дополнительную разработку (и причины сбоя), но это выполнимо.
Разделение журнала
Еще одно доказательство несовершенства Cloud Run — многочисленные вызовы API из разных конечных точек.
Допустим, у нас есть конечные точки GET/books, PUT/books и POST/books. У нас могут быть следующие журналы:
дата-время: 1az23r Позвоните, чтобы получить /книги
дата-время: 4df1As Call B PUT /books
дата-время: 1az23r успех
дата-время: 78eu3e Позвоните C POST /books
дата-время: 78eu3e успех
дата-время: сбой 4df1As
С помощью Cloud Run мы не можем проверить все журналы, связанные с одной конечной точкой.
Допустим, я хочу посмотреть, как работает конечная точка POST /books, наше единственное решение — получить идентификатор выполнения и проверить выполнения одно за другим. Но это неэффективно.
Конечно, Cloud Functions делает это изначально 🥳
А для этой ситуации с Cloud Run, уважаемый читатель, я не нашел способа разделить логи по эндпоинтам. Возможно, создайте определенный идентификатор для каждой конечной точки или создайте структурированные журналы. Но вся эта настройка становится немного сложной. (если у вас есть подсказка, пожалуйста, прокомментируйте здесь)
Облачные функции не идеальны
Мы застряли
Развертывание многих функций Google Cloud с помощью Google Cloud блокирует нас в Google Cloud.
Структура облачных функций, лямбда-функций и функций Azure отличается. Переключение с одного на другое болезненно.
И, возможно, мы захотим выйти из Google Cloud и перейти на Lambda… Удачи!
В то время как с красиво изготовленным контейнером это кусок пирога.
…ну нет, но так проще!
Функции работают независимо
Как было замечено ранее, чем сложнее проект, тем больше облачных функций требуется.
Для одного и того же проекта может потребоваться множество облачных функций, что приведет к повторению кода и отсутствию сеанса или управления кешем.
Не идеально, хотя можно создать некоторые общие облачные функции, вызываемые многими другими, как мы видели здесь.
Холодный запуск
Да, Cloud Functions приходится иметь дело с холодным запуском. Из-за своего бессерверного состояния функция переходит в спящий режим после короткого периода бездействия.
Это нормально, если облачная функция используется для фоновых задач.
Но для функций, ориентированных на пользователя, это может разочаровать.
Тем не менее, холодный запуск можно сократить, следуя приведенным здесь советам:
Тестируемость
Тестируемость не так идеальна с облачными функциями.
Хотя вы можете использовать фреймворк функций, вы никогда не будете уверены, что это будет та же конфигурация веб-сервера, что и при развертывании…
По крайней мере, с Cloud Run вы определяете свой собственный веб-сервер.
Но все равно с functions-framework все в порядке, подробнее о тестировании и развертывании Cloud Functions читайте здесь.
Почему я до сих пор использую Cloud Functions
Даже после всех этих недостатков я все еще использую Cloud Functions, и мне это очень нравится.
(Первая причина в том, что я начал с них, и некоторые из них все еще находятся в разработке.)
Основными преимуществами являются простота масштабирования, экономичность и низкие эксплуатационные расходы.
Что мне также очень нравится, так это разделение между вещами.
Я мог бы развернуть функцию, которая каждый раз вылетает, использует 1 Гб памяти и печатает ужасные логи. Ни на что другое это не влияет.
При развертывании новой конечной точки на обычном сервере, даже после многочасового тестирования, все еще существует вероятность того, что другая часть будет затронута и изменит ее поведение (версии, зависимости…).
С облачными функциями такого риска не существует. Совсем.
Помимо всех этих технических преимуществ, больше всего мне нравится в облачных функциях мощность, которую они нам дают.
Понимание того, что любая часть кода может стать доступной через 2 минуты, это так чхууууууууууууууууууууууууууууууууууууууууууууууууу!
С облачными функциями нам нужен короткий период времени для развертывания серверной части «The Facemash», которую Марк Цукерберг развернул за несколько дней. Без проблем с масштабируемостью, с которыми он столкнулся!
Огромный!
Теперь ты знаешь все, что знаю я.
Я надеюсь, что это поможет, и это точно.
Bi!
Узнайте больше о Cloud Run и облачных функциях здесь:
