Почему разработчикам необходимо знать Cloud сервисы?
#cloud

В одном из #nodejs чатов прилетел вопрос "Подскажите, нужна либа которая из текста делает озвучку и сохраняет ее. Куда копать?" (c)

Вот варианты решения задачи Text-To-Speach:
1️⃣Web Speech API, необходим запущенный браузера.
2️⃣Использовать Node.js только для запуска child_process.
3️⃣Vendor hosted, Использовать стороннего сервиса
4️⃣Cloud Native, т.е. использования сервисов предлагаемых облаком

Когда бизнесу важна скорость выхода на рынок, то Cloud Native безусловный фаворит. Поэтому я бы рекомендовал начать с родного облака:

☁️ AWS предлагает Polly
☁️ GCP предлагает @google-cloud/text-to-speech
☁️ Azure предлагает microsoft-cognitiveservices-speech-sdk

Запуск GDG Cloud Kyiv
#announcement #cloud

В конце апреля я проводил Cloud Study Jam. Это был trail event. По его итогу открыли Google Developer Group Cloud Kyiv. Google помогает комьюнити доступом к различным ресурсам. У нас уже была Google Developer Group Kyiv, но там фокус не на Cloud.

Комьюнити создано, чтобы помочь инженерам в освоение Cloud Native подходов. Именно инженерам, без разделения на разработчиков и DevOps инженеров. Разработчикам нужно знать облачные инструменты, а DevOps инженерам особенности поддержки и разворачивания языков.

Ссылки на комьюнити:
🔗 Платформа: https://gdg.community.dev/gdg-cloud-kyiv/
🔗 Канал: https://xn--r1a.website/GDGCloudKyiv
🔗 Чат: https://xn--r1a.website/GDGCloudKyiv_chat

Первое мероприятие через неделю.
🎤 Cloud Study Jam: Build a Website on Google Cloud
📍 26 мая, 18:30-21:00
🔗 Регистрация

Cloud Native Landscape for Node.js Developers
#worth_seeing #cloud

При просмотре описания докладов на OpenJS World 2021 я подумал, что речь будет идти об Cloud Native Landscape. Это страница где собраны проекты участвующие в Cloud Native Foundation. Я ошибся. Докладчик делает обзор самого подхода, а не инструментов.

Slides

Build Better Workloads with the AWS Well-Architected Framework and Tool
#worth_seeing #aws #cloud_native

Сегодня в рекомендациях видео об AWS Well-Architected Framework. Данный фреймворк помогает разворачивать приложения в AWS правильно. Вот ссылки, которые помогут лучше разобраться:
- общая инфо
- white paper, по своей сути является манифестом. Стоит знать, даже если вы не работает с AWS.
- labs, лабораторные для применения идей на практике.
- Well-Architected Tool, инструмент для проверки.

Данное рецепт являет логическим продолжением для тех, кто уже выполнил 100 базовых упражнений для изучения AWS.

Как и зачем настраивать healthchecks/probes?
#kubernetes #cloud

В реальных проектах трафик, который идет на Node.js приложение сначала проходит через какой-то из инфраструктурных элементов. Это могут быть load balancer, API Gateway, оркестратор (kubernetes/Docker Swarm) и т.д. Кроме маршрутизации трафика инфраструктура отвечает за перезапуск и масштабирование приложения. Для этого ей необходимо сообщить, что приложение работает с помощью healthcheck. Инструментов много, поэтому рецепт рассматривает healthcheck только для kubernetes. В остальных инструментах принципы и реализация аналогичны.

Как правило healthcheck это конкретный http endpoint, который отдает 200 если приложение работает. Он может проверять доступность зависимостей, памяти, процессора и т.п. В Nest.js для этого используется terminus. В kubernetes помимо http healtcheck можно настроить tcp или bash команду – может быть полезно для worker-ов без http.

Kubernetes позволяет сконфигурировать несколько видов healthcheck. В документации они еще называются probes. Рассмотрим каждый из них:
– Liveness показывает, что контейнер работает. Если не будет 200 ответа, то Kubernetes перезапустит контейнер.
– Readiness показывает, что контейнер доступен для трафика. Если не будет 200 ответа, то Kubernetes не будет отправлять на него запросы. Пример из реального проекта – WS сервер отдавал 200 ответ пока не количество подключений не превышало лимит.
– Startup показывает, что контейнер успешно запустился. Редко используется для Node.js приложений, так как спроектирован для долго запускающихся контейнеров.

Ссылки по теме:
🔗 The Twelve-Factor App
🔗 Configure Liveness, Readiness and Startup Probes
🔗 Kubernetes Liveness and Readiness Probes: How to Avoid Shooting Yourself in the Foot
🔗 Liveness probes в Kubernetes могут быть опасны

Що перевірити при розгортанні API?
#list #devops #cloud

1️⃣ Чи є Load Balancer?
Без нього масштабування не можливо.
2️⃣ Чи включений редирект з http на https?
Ваше API має працювати тільки по https.
3️⃣ Чи включений HTTP/3?
74% користувачів мають браузер з підтримкою HTTP/3.
4️⃣ Чи налаштовано стискання (compression)? Які методи підтримуються?
Load Balancer має цю відповідальність, а не Node.js
5️⃣ Чи має публічне API кешування?
Поділ публічного та приватного API (яке вимагає авторизації) відповідальність розробників, а ось налаштувати Load Balancer-а – DevOps інженер.