Проект "На коленке" 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, хранилище образов, гитхаб.

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

#авторское

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

К примеру - закинули вы сначала метрику одного типа в прометей. Допустим gauge, поменяли на count и всё - сервису плохо. И вперёд - бежим по ssh в убунту, потом в крутящийся образ докера, останавливаем демона, грепаете логи, включаете доступ к его api через доп флаги запуска, мануальный тестовый запуск, удаляете метрику через апи - ложится уже sfdb (внутренняя база данных прометеуса), разбираетесь как собрать логи после старта, почему нет доступа к разбитым по файлам-чанкам при старте сервиса. Т.е. склеить это еще пол-дела, хорошо бы уметь ещё и по "канализации" с гаечным ключом ползать. А придётся. И не раз.

В общем, я всё к тому, что разница между чем-то proof-of-concept и реальностью - как между полноценным автомобилем и скамейкой с прибитыми колёсиками.

Едут-то оба, вопрос в "нюансах" :)

#авторское

Хабр теперь вот такой. Курочки, козочки ...

WTT 5 кур -> windows 10 key !

Контентик с конфы Highload++ подъехал. Налетай! https://www.youtube.com/c/HighLoadChannel/videos 🚣🚣🚣

#доклады #highloadconf

Лан, не поленюсь и закину сюда ссылочки. Поставил плюсик тем докладам, которые интересны лично мне.

1) +"Где деньги, Лебовски?", или Почему пора перейти на FinOps / Александр Токарев, Павел Журов
2) Использование телеметрии с клиентских инсталляций для предиктивного решения проблем / Максим Лапшин
3) Нагрузочное тестирование с K6 / Дмитрий Самиров
4) +Есть ли жизнь без ELK? Как снизить стоимость Log Management / Денис Безкоровайный
5) Внедрение SRE. Итоги 5 лет опыта / Павел Притчин
6) Концентрируемся на бизнес-модели данных: от ETL к ELT / Иван Зерин
7) Techtalk с Ильей Таратухиным (2ГИС)
8) Синхронная репликация и выборы лидера в Tarantool / Сергей Петренко
9) +Мониторинг как процесс, или Как перестать бояться и начать спать по ночам / Виталий Медведев
10) Techtalk с Николаем Кнышом (Почтатех)
11) +Мифическая миллисекунда, или Как ускоряют движки OLAP баз данных / Роман Кондаков
12) Tarantool: от коммита до прода за 20 минут / Роман Проскин
13) Techtalk с Владимиром Наумовым (РСХБ)
14) Точные рекомендации для пользователя: как мы научили систему выбирать контент / Даниил Бурлаков
15) В поисках идеальной кластерной ФС: опыт использования LINSTOR / Андрей Квапил (kvaps)
16) Высоконагруженная Платформа 1С / Антон Дорошкевич
17) +Архитектура рекомендательной системы Дзена / Дмитрий Кондрашкин
18) Techtalk с Сергеем Луговым (ЦФТ)
19) +Инфраструктура как микросервисы. Зачем и почему? / Алексей Шарапов
20) +Теория программирования: пакетные принципы и метрики / Александр Макаров
21) Технический директор: вроде бы ему все можно, но нельзя... / Артем Каличкин
22) +Авито IaaS: как мы управляем инфраструктурой / Юрий Дзюбан
23) +Сквозное логирование с использованием транзакционных логов в Росгосстрахе / Александр Крылов
24) +Отказ в обслуживании: как положить высоконагруженную систему / Алексей Бабенко
25) Как мы перевели десятки миллионов пользователей на новый сетевой протокол / О.Смирнов, А.Никитин
26) Techtalk с Никитой Гордиенко (Дойчетелеком)
27) Повседневная практическая векторизация / Ignas Bagdonas
28) Бесфайловая система хранения. Почему YDB работает с дисками напрямую / Владислав Кузнецов
29) Json or not Json. Плюсы и минусы использования Json в PostgreSQL / Олег Бартунов, Никита Глухов
30) Techtalk с Денисом Рылеевым (РСХБ)
31) Раздача контента с HDD: быстро, увлекательно и надежно / Кирилл Шваков
32) +Ускорь это немедленно, или Легкая сеть тяжелого бэкенда / Илья Щербак
33) Транспорт будущего, или Как мы ускорили ВКонтакте в 1,5 раза / Александр Тоболь
34) Миграция приложения Oracle PL/SQL на Postgres pl/pgSQL / Анатолий Анфиногенов
35) +Безопасность DNS / Филипп Кулин
36) +Service Mesh на стероидах. Часть 1 / Алексей Ефимов
37) TLA+/TLC: формальный метод верификации конкурентных алгоритмов для инженеров / Алексей Найденов
38) Что нового в плане мониторинга в PostgreSQL / Алексей Лесовский
39) Хранение графов в Tarantool: реальность или миф? / Александр Горякин
40) +Облака для самых маленьких / Алексей Учакин
41) +Ubisoft в Google Cloud: автомасштабирование игрового кластера / Владислав Шпилево
42) Технология распределенного реестра R3 Corda и CBDC / Марина Кудрявцева
43) Симуляция боевой инсталляции MySQL/ MariaDB/ Postgresql/ MongoDB / Николай Ихалайнен
44) Kafka. Как мы строили корпоративную шину данных, которая обрабатывает до 3 млн сообщ./сек. / И.Гаас
45) Tarantool Cartridge: кластер из коробки / Игорь Золотарев
46) +Как снизить накладные расходы на добавление +1 микросервиса / Руслан Сафин
47) +Что такое хорошая интеграция / Максим Цепков
48) +Киберучения: методы проведения и реализация / Лука Сафонов
49) +Экономика железа для облачных услуг, старое дешевое против нового мощного / П.Леонтьев, С.Наумов
50) MPP СУБД на примере Vertica: архитектура и способы достижения производительности / А. Скоробогатов
51) Возможности Spark Streaming для аналитики данных в потоковом режиме / Артем Гогин
52) Как построить высоконагруженное и отказоустойчивое S3-хранилище / Дмитрий Анисов
53) Ускорение разработки с Rust / Олег Уткин
54) «Get Real»: как я в финтехе машинное обучение растил / Иван Комаров

#доклады

55) +Хранилище фич или какая-то дичь? / Леонид Блохин, Дмитрий Евстюхин
56) +Stateful Deployment Platform или как Uber управляет сотнями тысяч баз данных / Егор Гришечко
57) +ETL-сервисы и таски для Такси, Еды и Лавки / Владимир Верстов
59) ML в промышленности: задачи и проблемы / Андрей Зубков
60) Apache Ignite теперь с CDC! / Николай Ижиков
61) Панельная дискуссия "Как выиграть в конкурентной борьбе за сети"
62) +Как (и зачем) переехать на архитектуру ARM в облаке? / Михаил Голубев, Дмитрий Иванов

Часть из этих докладов планирую как и прежде, слушать в mp3. Если кто не знал - существуют бесплатные веб сервисы, которые вам легко вытянут mp3 из ютуба. Я пользуюсь, к примеру - https://yt1s.com/ru180/youtube-to-mp3, заливаю в telegram и на прогулочках включаю.

Приятного просмотра. Ну или прослушивания :)

#доклады

чык

Лучше всего положение белорусского ПВТ описывает сам сайт ПВТ

Впны, тележка и авито. Иран становится ближе, чем кажется.

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

Какая точность у timestamp в sqlite? Забавный баг с #радиоТ

У АйтиБороды вышел видос, где он рассказывает что будет с контентом и его каналом, а так же выражает и объясняет свою позицию. Имхо, большой респект ему, т.к. реально по пальцам одной руки можно пересчитать публичных блогеров и так называемых "лидеров мнений" из СНГ, которые рискуя своей "долей пирога" - остаются людьми с большой буквы.

В ролике он в том числе упоминал кейс, когда ему писали по поводу рекламы из РФ, он отказывался, а на вопрос "почему" - уже начинало гореть. Отлично понимаю. Вспомнил как 4-ого марта мне написал HR из РФ с дефолтным "привет, не хотел бы [вакансия]?". Я прогуглил человечка и удостоверившись, что их hr-агенство действительно базируется в Питере, ответил, что не хочу иметь дел с HR из РФ.

Собственно, ответ на это письмо на скриншоте. Бывает и так, поэтому старайтесь не делить людей по паспорту. Делите по личным качествам конкретного человека.

🇺🇦❤️

Сколько человек работает в тиктоке? 😜 #радиоТ

Основы Linux (обзор с практическим уклоном)

https://habr.com/ru/post/655275/ - хорошая входная статья в мир Linux.

Рекомендую тем, кто хочет начать разбираться в unix системах, подойдёт даже джунам :) Время чтения ~20 минут

#библиотека_знаний #habr

Aspect Oriented Programming (AOP)

Аспектно ориентированное программирование? WTF!? Мало нам аббревиатур и концепций, подавай больше. На самом деле штука очень крутая и перспективная - расскажу в двух словах на примере C#.

Задача
Есть, допустим, репозиторий. К примеру UserRepository. Со стандартными CRUD операциями. Положить пользователя, вытащить по ID, удалить - ну вот это вот всё. И нужно вот нам собрать метрики - хотим видеть время выполнения каждого похода в субд.

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

Как это сделать?

Решение
1) Пойдём от решения "в лоб".

Пишем в начале каждого метода StopWatch.Start, а в конце StopWatch.ElapsedMilliseconds и пушаем метрику.

CreateUser(User user){
StopWatch sw = new StopWatch();
sw.Start();

//поход в базу

sw.Stop();
Metrics.Add('UserRepository.CreateUser',sw.ElapsedMs);
}

и что дальше? Будем нарушать DRY (don't repeat yourself) и вставлять данный кусок ВО ВСЕ МЕТОДЫ? Можно, но ... не можно. Очевидно, что нужно это куда-то выносить. Куда и как?

2) Окей, тут у нас развилочка по решениям. Более топорный способ - создадим базовый класс/хелпер, где сделаем метод-враппер, который будет в себя принимать некий Action (делегат), исполнять его и обернув тем же самым кодом - успокаиваемся. Или нет?

class RepositoryBase : {

CallWithMetric(Action act){
StopWatch sw = new StopWatch();
sw.Start();

act.Invoke();

sw.Stop();
Metrics.Add('UserRepository.CreateUser',sw.ElapsedMs);
}
}

и получается что-то такое :

CreateUser(User user){
CallWithMetric(() => {
//идём в базу
})
}

неплохо, но не сказать, что красиво. коллбековая джаваскриптщина какая-то.

3) Третья стадия уже более generic-like подход и в целом скорее уже ближе к AOP, хотя по факту скорее ООП.

Мы можем вынести из репозитория интерфейс и создать декоратор для репозитория. Оборачивать все репозитории им и "под капотом" вызывать метрики. Код приводить не буду, телега не предполагает длинных постов :) (можете глянуть на MSDN - понятная и коротенькая статейка).

Это уже взрослый подход. Но всё еще хочется немного магии.

3) И так. А вот и дошли до AOP. А что если нам создать атрибут, который будет сам оборачивать наш метод в нужный код? Звучит-то клёво, но как? Ведь атрибуты это про метаданные, они не являются декораторами сами по себе.

В C# есть пару классных библиотек. Самые известные это PostSharp и Fody. Они на этапе компиляции могут менять IL код. Это значит, вы можете пометить, допустим специальным атрибутом вам класс/метод и уже после компиляции в него вставится нужный код. В нашем случае - вызов метрик будет выглядеть уже как-то так :

[TimeElapsedMetric]
CreateUser(User user){
       //поход в базу      
}

Удобно. Красиво. Магия!

Но... есть нюансы :) Во-первых, PostSharp, говорят, хорош, но стоит по 700$ per developer. Цена - 🐴. Есть фри версия, но с ограничениями. Не интересно.

Fody же - бесплатный и с открытым кодом. Наш кейс он отлично покрывает (см. MethodTimer), + умеет навешивать "хуки" на методы из коробки. Но и тут есть нюансы. Например, он не позволяет делать re-execute методов, т.е. какой-нибудь Retry Policy уже не навесишь. Так же есть нюансы по работе с async/await - он не везде поддерживается и судя по вкладке Issues на гитхабе - есть баги.

В качестве остаточных решений еще можно подумать в сторону молодого Roslyn, но это уже заморачиваться нужно. Есть еще старый добрый T4 темплейтинг. И пару встроенных классов в .net, которые позволяют переписывать метод в рантайме, но не изменять его.

Что ж. Штука классная, но ждём развития. Надеюсь, в ближайшие пару лет появится что-то "из-коробки".

Пара общих статей с рефами :
Aspect Oriented Programming (AOP) через исходный код
Теория и практика AOP. Как мы это делаем в Яндексе
Aspect-Oriented Programming : Aspect-Oriented Programming with the RealProxy Class

#csharp #библиотека_знаний #авторское