Решил просканить топ статей с хабра за последнюю неделю. Удивительно, но из 10 страниц топа, всего ОДНА статья, хоть как-то КОСВЕННО касается текущих реалий айтишки в РФ. Наводит на определенные выводы. Даже, если учесть, что хабр - вне политики, очевидно, что сверху включена цензура даже на этом уровне.
Штош, скриншоты как раз с этой единственной статьи : Отрасль IT в России поставили на паузу.
Выводы делайте сами что будет с IT сектором (и не только) в РФ в ближайшее время.
#habr
Штош, скриншоты как раз с этой единственной статьи : Отрасль IT в России поставили на паузу.
Выводы делайте сами что будет с IT сектором (и не только) в РФ в ближайшее время.
#habr
😢2
Проект "На коленке" 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, хранилище образов, гитхаб.
И вот это уже в целом можно назвать приличным решением для старта. Конечно, всё как всегда от целей и бюджета зависит - с корпоративными деньгами можно было бы хоть всю систему на лямбдах спроектировать, кек.
#авторское
Вот недавно друг спросил "Слушай, а вот ты там бота какого-то делаешь, хобби проектик. Сложно вообще сделать нормально? Чё там, команду принял, обработал, ответ вернул в бота - десять строк кода".
Тут я улыбнулся.
Разница между "тяп ляп и готово" и "продашн-реди" - пропасть. Хотя по внешним признакам "на глаз" и не определить что там на бэке крутится.
Давайте на реальном примере. Окей, давайте подумаем - а что там нужно-то для простейшего 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, хранилище образов, гитхаб.
И вот это уже в целом можно назвать приличным решением для старта. Конечно, всё как всегда от целей и бюджета зависит - с корпоративными деньгами можно было бы хоть всю систему на лямбдах спроектировать, кек.
#авторское
👍7
Суть ответа на изначальный вопрос кроется еще не только в минимум восьми пунктах и кучи технологий/решений, которыми склеен ваш апп. Дело в том, что это еще и работа со всем этим "внутрь". unix, понимания ограничений метрик, кэша, бд, многопоточной/асинхронной обработки - у каждого из пункта есть подпункты, а под ними еще десяток более мелких. Вот это всё годами и нарастает на сеньорах как мох.
К примеру - закинули вы сначала метрику одного типа в прометей. Допустим gauge, поменяли на count и всё - сервису плохо. И вперёд - бежим по ssh в убунту, потом в крутящийся образ докера, останавливаем демона, грепаете логи, включаете доступ к его api через доп флаги запуска, мануальный тестовый запуск, удаляете метрику через апи - ложится уже sfdb (внутренняя база данных прометеуса), разбираетесь как собрать логи после старта, почему нет доступа к разбитым по файлам-чанкам при старте сервиса. Т.е. склеить это еще пол-дела, хорошо бы уметь ещё и по "канализации" с гаечным ключом ползать. А придётся. И не раз.
В общем, я всё к тому, что разница между чем-то proof-of-concept и реальностью - как между полноценным автомобилем и скамейкой с прибитыми колёсиками.
Едут-то оба, вопрос в "нюансах" :)
#авторское
К примеру - закинули вы сначала метрику одного типа в прометей. Допустим gauge, поменяли на count и всё - сервису плохо. И вперёд - бежим по ssh в убунту, потом в крутящийся образ докера, останавливаем демона, грепаете логи, включаете доступ к его api через доп флаги запуска, мануальный тестовый запуск, удаляете метрику через апи - ложится уже sfdb (внутренняя база данных прометеуса), разбираетесь как собрать логи после старта, почему нет доступа к разбитым по файлам-чанкам при старте сервиса. Т.е. склеить это еще пол-дела, хорошо бы уметь ещё и по "канализации" с гаечным ключом ползать. А придётся. И не раз.
В общем, я всё к тому, что разница между чем-то proof-of-concept и реальностью - как между полноценным автомобилем и скамейкой с прибитыми колёсиками.
Едут-то оба, вопрос в "нюансах" :)
#авторское
👍11
Контентик с конфы Highload++ подъехал. Налетай! https://www.youtube.com/c/HighLoadChannel/videos 🚣🚣🚣
#доклады #highloadconf
#доклады #highloadconf
👍1
Айтигребец
Контентик с конфы 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»: как я в финтехе машинное обучение растил / Иван Комаров
#доклады
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»: как я в финтехе машинное обучение растил / Иван Комаров
#доклады
🔥2❤1
Айтигребец
Контентик с конфы Highload++ подъехал. Налетай! https://www.youtube.com/c/HighLoadChannel/videos 🚣🚣🚣 #доклады #highloadconf
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 и на прогулочках включаю.
Приятного просмотра. Ну или прослушивания :)
#доклады
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 и на прогулочках включаю.
Приятного просмотра. Ну или прослушивания :)
#доклады
❤1🔥1