Проект "На коленке" vs "По красоте"?

Вот недавно друг спросил "Слушай, а вот ты там бота какого-то делаешь, хобби проектик. Сложно вообще сделать нормально? Чё там, команду принял, обработал, ответ вернул в бота - десять строк кода".

Тут я улыбнулся.

Разница между "тяп ляп и готово" и "продашн-реди" - пропасть. Хотя по внешним признакам "на глаз" и не определить что там на бэке крутится.

Давайте на реальном примере. Окей, давайте подумаем - а что там нужно-то для простейшего Telegram бота.

Вариант "MVP на коленке"

Пишите какой-то скрипт, заливаете это всё на какой-нибудь serverless AWS Lambda и ... если опустить настройку этого всего, изучение api Telegram, настройку AWS - в целом это дело пары часов для знающего человека. Работает как-то, чет отвечает по сценарию и хорошо. Кушает ресурсов мало, пока пользуешься сам и пара друзей. Красиво

Вариант "Продакшон-реди"

А теперь представим, что ботом начинают пользоваться слегка больше людей, чем два.

Поехали.
1) Нам бы базу. Хранить данные юзверя, какой-то стейт. Окей, поддержка своего сервера с бд - дело непростое, а потерять данные - очень больно. Покупаем managed postgres/mongodb, стоит от 5$ в месяц - недорого, безопасно и с возможностью вертикально/горизонтально заскейлить в случае нагрузки. Пойдёт.

2) Нам бы не крутить скрипт на лямбде. Лямбды удобные и стабильные, но дорогие, если там выполнять какие-то "жирненькие" скрипты. А своей api-gateway подымать пока рано, да в целом и не нужно. Поэтому будем лямбду всё же как-то использовать только для "проброски/хранения" вебхука от телеграма.

3) Будем класть все вебхуки в ... очередь. AWS SQS, допустим. Довольно бюджетно и не даст нам потерять сообщения в случае падения бэкэндов за ними. Ну или если нужно зачем-то отключить бэк, допустим для апдейтов. Очередь просто будет пухнуть, юзеры ждать - не критично. Как только бэки запустятся - они разгребут очередь, запросы не потеряются. Эдакий демпфер. Удобно!

4) Очередь нужно чем-то разгребать (не веслом желательно, да). Окей, давайте-ка напишем что-то, что будет в бесконечном цикле крутиться и бегать в очередь за сообщениями. и обрабатывать. Хорошо бы еще это в докере запускать. И как-то деплоить не сильно руками. Пишем пачечку деплой-скриптов. Берём 1 минимальный инстанс на Digital Ocean за 5 баксов и вот у нас уже в целом какое-никакое а работающее решение, подменяющее "MVP на коленке" . И даже с заделом на скейл.

5) Окей, еще бы понимать что вообще происходит на бэке в текущий момент времени. Нужен мониторинг. Если юзать какой-нибудь AWS CloudWatch - можно быстро выйти за рамки бюджета. А бюджет нам важен. Поэтому нам нужен сервер хранения и отображения метрик. Можно какой-нибудь ELK стек (elastic, logstash, kibana) поднять, но тут уже кому что ближе. Идём на тот же DO, устанавливаем ubuntu, а поверх - prometheus. К прометеусу прикручиваем pushgateway. Поверх этого всего Grafana - для графиков и каких-то алертов. Настраиваем это всё, вешаем через nginx аутентификацию (чтобы уши prometheus'а не торчали во внешку. Из коробки он, увы, так не умеет). Теперь и метрики есть и графики и алерты в telegram/slack.

6) Ну а логи ж ещё, точно. А давайте-ка тут не терять много времени и просто заюзаем NewRelic, у них там вполне себе демократичные цены для старта, и возможностей вагон. Подключаем к коду

7) Так. Что мы еще забыли... Ах да. Чтобы нам не мешали абьюзеры-боты своими частыми реквестами - давайте-ка напишем реквест-троттлер ("резальщик" частых запросов). Но под ним должно что-то быть. Что-то managed и быстрое. Конечно же Redis. 15$ в месяц, пару кликов на конфигурацию и вот уже маленький кластер на DO готов к бою.

8) Обмазываем весь код метриками, логами, бизнес-логику распихиваем по слоям, пропиливаем тесты, заводим Postman, хранилище образов, гитхаб.

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

#авторское