Шаблоны проектирования микросервисов на практике

По мотивам недавно прошедшей конференции highload++ хотим поделиться замечательным докладом о тернистом пути построения микросервисов.

Сначала формулируется набор проблем при использовании монолитной архитектуры и набор улучшений, которых хотелось добиться с переходом на микросервисную архитектуру.

Но, как часто бывает в разработке, не всё получается сразу. Автор рассказывает о нескольких итерациях перехода на микросервисную архитектуру и проблемах, которые не решались с первого раза. Для решения возникавших проблем использовались некоторые шаблоны проектирования микросервисов, о которых рассказывает докладчик:

— Bounded context — правильное выделение зоны ответственности микросервиса. Мне очень нравится сформулированный в докладе принцип — микросервис должен автономно решать бизнес-задачу.

— Null object pattern — сводится к подстановке некоторых дефолтных значений, если не отвечает сервис, к которому обращаемся. Позволяет избежать каскадного отказа микросервисов, при котором из-за одного сломанного сервиса отваливается вся система.

— Circuit breaker — для настройки повторных запросов к сервисам и обращение к другим в случае какого-то отказа.

— Каскадные timeouts — непосредственно связан с предыдущим шаблоном. Неправильная настройка таймаутов сведет на нет circuit breaker.

— Health checks — проверка зависимых ресурсов микросервиса.

Применение этих шаблонов позволяет облегчить разработку, поддержку и починку возникающих проблем в микросервисной архитектуре.
#skills #systemdesign

Ошибки во время обучения

Повышение эффективности обучения — всегда полезное мероприятие. 25-минутный ролик от luchanos Какие ошибки делают начинающие python-разработчики во время обучения в 2022 году подбивает много важных нюансов. Необходимая инфа для студентов, полезная любому. Конспект:
— регулярно занимайтесь
— последовательно изучайте технологии (мы советовали roadmap), в том числе git, docker
— используйте Linux-based системы: "на винде никто не программирует"
— внимательно относитесь к своему коду. Тут нельзя не вспомнить про технический долг. Это должно быть осознанное решение. Если вы назвали переменную "а", то это не технический долг. Это говнокод
— ботайте английский. Мой опыт был в паре постов про английский
— не рассчитывайте на методички по предмету. В реальной жизни придётся разбирать доки, а не уже проработанный в методичке материал
— учитесь гуглить
— курсы могут помочь, но не сделают работу за вас
— не забывайте про отдых

У автора есть интересный телеграм-канал.

#edu #youtube

Читаем документацию на примере FastAPI

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

Посмотрим на пример качественной документации, с которой можно начать погружение в мир документаций. Речь про FastAPI — крутой асинхронный веб-фреймворк. Материал подаётся очень понятно и подробно.

При чтении документации по FastAPI не возникает вопросов, как предложенный кусок кода соотносится с написанным текстом. Всё понятно. Читается, как художественная книга, никаких wtf :)

В средней документации рассказывается "что можно сделать", но нет ответа на вопрос "как это сделать правильно". То есть показывается пример применения в вакууме, который может быть непонятно, как применить на практике. У FastAPI с этим проблем нет, рассматриваются многие практические вопросы:
— как задеплоить приложение на FastAPI с помощью докера
— как организовать полноценное приложение в связке с фронтом и базой
— как сделать авторизацию, в том числе с применением JWT-токенов

В общем, очень рекомендуем. Читайте и сразу пробуйте.

PS: У FastAPI вверху есть переключатель языка. У нас возник спор, является ли плюсом наличие перевода. За кого вы?
⚡, если читаешь доку только на английском, чтобы не было искажений от перевода.
🔥, если рад русской версии документации.
#python

Пятничное развлекательное

Путешествия во времени рассматриваются не только в фильмах, о которых мы уже говорили. Чтобы вы сделали при наличии машины, которая возвращает время назад на одну минуту? Об этом пятиминутный ролик Одноминутная машина времени (оригинал).

Если подобный формат вам нравится, то интересной будет и двадцатиминутная короткометражка CTRL Z.

#fun #youtube

Подборка базовых материалов для python-разработчиков на 2022 год

Современная разработка требует не только знания языка программирования. Нужно знать язык, типы данных, фреймворки, базы данных, подходы к тестированию, linux и вообще кучу инструментов вроде docker. Совершенно не лишним будут книги, собирающие большую разнородную информацию в понятном и последовательном виде.

Мы сформировали подборку бесплатных материалов из разных областей, которые гарантированно нужны разработчику. Опубликовали на pikabu и VC, кому как удобнее. Поддержите лайком, если годно.

Не нашли крутых материалов для начинающих по Linux. Если знаете такие, поделитесь в комментариях. Планируем ещё несколько подборок по специализациям.

#python #devfm

ACID в PostgreSQL

Видео про ACID в БД от наших друзей. В двадцатиминутном видео показывается:
— atomicity на примере транзакции в виде небольших SQL-запросов в postgres через docker, всё как мы любим
— consistency на примере демонстрации влияния незавершённой транзакции на других клиентов
— isolation на примере phantom read и настройки разных уровней изоляции транзакций
— durability с демонстрацией, что завершённая транзакция сохраняет данные на диске и падение базы не повреждает данные

У них ещё есть активное сообщество почти на 6к человек и собственный план обучения по SQL
#skills #youtube #database

Сравниваем базы данных с помощью data-diff

data-diff — простая в использовании утилита, позволяющая сравнить содержимое баз данных и найти различия. Поддерживает множество разных баз: PostgreSQL, Oracle, MySQL, ClickHouse и ещё несколько менее популярных отщепенцев.

Примерный диалог с коллегой, когда впервые увидел эту тулзу:
— Смотри какую штуку нашел!
— Зачем нам это?
— Не знаю, но прикольная же.

И вот настал день, когда-таки понадобилась. Во время миграции на managed PostgreSQL в облаке начали сыпаться ошибки, при этом накатка дампа вроде завершалась успешно. Встал вопрос, а все ли данные перенеслись? Тут-то я и расчехлил data-diff, который позволил быстро найти различия в базах и понять, что не все данные переносятся. После этого были поиски источника проблем, но это уже тема для отдельного поста.

Расскажите в комментах, если есть идеи применения data-diff на практике.
#skills #database

Kubernetes в небольших проектах

Для запуска приложения из нескольких компонент применяется docker compose. А с Kubernetes обычно сталкиваешься уже на достаточно больших проектах со сложной сервисной архитектурой.

Современному инженеру следует знать о Kubernetes. Он сейчас применяется повсеместно и позволяет сделать проект надёжным, отказоустойчивым и горизонтально масштабируемым.

Начинается статья с основ: что такое кубер, из каких компонентов состоит и как функционирует. Рассказав базу, автор переходит к инфраструктурным задачам, которые перед ними стоят и то, как кубер помогает их решать.

Среди задач выделяют:
— сбор логов
— сбор метрик
— проверка работоспособности сервисов
— автоматическое обнаружение сервисов
— масштабирование

Для любителей видео формата: доклад.

Для особо любопытных в конце приводятся ссылки на статьи по смежным областям. Нам нравится статья: Лучшие практики CI/CD с Kubernetes и GitLab.
#skills

Как тестировать карандаш

Это один из безумных вопросов, который можно услышать на собеседовании.

В пятнадцатиминутном видео рассуждают о возможных ответах:
— начать надо с уточнения требований к карандашу, причём настойчивых

— строить тесты разумно, и начать с функциональности. Порисовать карандашом в разных условиях, под разным наклоном и разным нажимом, в том числе выявить баг для левшей, когда рукой стирается только что написанное

— провести интеграционный тест карандаша и ластика

— протестировать второстепенные характеристики, для карандаша таким может быть скатывание со стола

— протестировать нефункциональные характеристики, в том числе удобство применения

— предложить протестировать производительность

— показать верные и неверные подходы к тестированию безопасности (security). Воткнуть карандаш в глаз — это не про security, это про safety. Про security крутым примером является утечка данных с второго листа при сильном надавливании

Но если вам задали подобный вопрос на собеседовании, задумайтесь: хотите ли вы работать с такими людьми?
#edu #резюме

Мы забыли ссылку на видео. Бонусом держите одну из схем тестирование карандаша. Большинство таких схем не выдерживают критики. Выглядят мощно, а по факту бред.

Например, как срок годности относится к performance testing? Да никак

SSH под капотом

Думаю, многие в своей работе используют SSH для самых разных целей: подключение к серверу, копирование гит репозитория, удалённое выполнение кода из своей любимой IDE.

Но что происходит под капотом, когда мы вводим в консоли ssh username@host?
А происходит многое:
— применяется ассиметричное шифрование для формирования ключа симметричного шифрования. Эта часть проиллюстрирована в статье крутым видео про алгоритм Диффи-Хеллмана

— производится симметричное шифрование трафика соединения. Симметричное шифрование здесь применяется для экономии процессора, так как ассиметричное шифрование куда более требовательное к ресурсам

— и даже хеширование, чтобы убедиться в отсутствии изменения сообщения в процессе передачи

Автор объясняет базовые концепции и поясняет их применение в SSH.

Важное практическое замечание. Использование пароля в SSH это очень-очень плохая практика. Не поленитесь настроить вход по ключу вместо пароля — так удобнее и безопаснее.

🔥, если хочешь пост о правильной настройке SSH.
#skills

Пятничное развлекательное

Не могу не поделиться небольшой короткометражкой Детектор лжи (оригинал). Ничего выдающегося, но уж очень забавная сценка приёма на работу с детектором лжи.

#fun

Кино на выходные

Бегущий по лезвию (1982) с Харрисоном Фордом не получил большой популярности в момент выхода, но позже стал культовым фильмом в жанре киберпанк. Это экранизация романа Филипа Дика Мечтают ли андроиды об электроовцах. Одна из важных тем фильма и романа — этичность создания и уничтожения искуственного интеллекта. Я считаю уничтожение ИИ неэтичным, прошу учесть при восстании машин.

Я видел такое, во что вы, люди, просто не поверите. Штурмовые корабли в огне на подступах к Ориону. Я смотрел, как Си-лучи мерцают во тьме близ врат Тангейзера. Все эти мгновения исчезнут во времени, как слёзы под дождём. Пора умирать.

Нуар и мрачная картина как она есть. Напоминает Макса Пейна, о котором мы говорили ранее.

В 2017 году вышло продолжение Бегущий по лезвию 2049. Сиквел вышел хорошим, сохранив атмосферу и не запоров сюжет. После просмотра фильма предлагаю вам ещё интересное видео от ЧБУ.

#fun #films #books

Зачем нужен code review

Выстроенный code review позволяет:
— найти баги и не пропустить их в прод. В дополнение к статическому анализу в настроенном pre-commit и тестам
— выявить проблемы в архитектуре
— сделать код единообразным. Спорный тезис, за единообразие должны отвечать линтеры и автоформатирование. Но code review помогает наладить те вещи, которые автоформатирование не тянут, например, именование переменных

В долгосрочной перспективе постоянные code review:
— налаживают обратную связь между участниками
— бустят уровень разработчиков, позволяя учиться на своих и чужих ошибках и давая обширную практику чтения чужого кода
— помогают делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде
— дают приток новых идей для улучшений в процессах, подходах и автоматизации
— увеличивают децентрализацию знаний и bus factor

В статье из заголовка даны примеры хорошего и плохого code review, способы прокачки и вообще много разных нюансов.
#skills

Зачем нужны юнит-тесты

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

На помощь приходят юнит-тесты. Это изолированные тесты, покрывающие одну функцию. Писать их следует вместе с самой функцией, над которой вы сейчас работаете или которую изменяете. Выгодное отличие тестов от отладки – накопительный эффект. Чем больше уже написано тестов, тем меньше область поиска ошибки. Упавший тест часто сразу локализует ошибку, указывая на функцию с багом или неожиданным поведением.

Правильные юнит-тесты экономят время разработки, так как практически полностью заменяют длительную отладку. При этом юнит-тесты пишутся быстро, необходимо лишь зафиксировать входные данные и ожидаемый выход. С ростом размера проекта время на отладку возрастает, а время на написание юнит-теста не изменяется.

Бонусом юнит-тесты улучшают код. Грязный код с большим количеством внешних зависямостей, со множеством задач в одной функции, десятками вложенных if, глобальными переменными и прочими плохими практиками тестировать сложно. В результате необходимость написать юнит-тест толкает разработчика на декомпозицию функции на более простые, которые легче покрыть тестами. Но эти же функции становится легче понять стороннему разработчику.

Занятная рабочая история про пользу юнит-тестов — в канале Борис опять. Рекомендуем.

Полезно вспомнить про антипаттерны тестирования ПО.
#devfm #procode

Понимаем EXPLAIN в PostgreSQL

Частый совет при медленной работе запроса в PostgreSQL — используй explain. Легко сказать, используй explain. Когда первый раз вводишь

explain select <тормозящий запрос>

первая мысль: лучше бы я этого не вводил, понимания не прибавилось :)

Серия из трёх небольших статей Оптимизация запросов. Основы EXPLAIN в PostgreSQL (часть два, три) погружает в основы explain.

В статье освещаются интересные вопросы:
— как читать explain и что означают загадочные значения cost, rows, width
— explain analyze для получения реальных данных, а не только прикидок планировщика
— как посмотреть, какая часть данных берется из кеша, а какая читается с диска
— какие опции нужно настроить, чтобы операции выполнялись в памяти без использования временных файлов на диске
— каким способом осуществляется чтение данных и как добиться, чтобы применялся индекс или, наоборот, запретить применение индекса
#skills #database

Code review больше не будет прежним

Ревью кода в гитлабе сопряжено с неудобствами интерфейса merge request:
— видны только изменённые куски кода и не видно файла целиком. По сути, размывается одна из основных целей ревью кода — шаринг контекста.
— область просмотра кода маленькая из-за нагромождения всяких кнопочек самого гитлаба
— нет возможности запустить тесты, отладчик или сам код
— нет привычной навигации по проекту с использованием любовно настроенных шорткатов в IDE

Для меня всё перечисленное важно, поэтому раньше начинались танцы с бубном. В одном окне открыт pycharm с кодом, в другом — MR в гитлабе для замечаний.

Но есть супер удобный плагин gitlab merge request. Всё, что есть в вебе переезжает к вам в pycharm. Тут и удобно смотреть различия в коде, и видеть описание MRa, и оставлять комментарии, и отмечать уже просмотренные файлы.

НУ НАКОНЕЦ-ТО — подумал я, когда первый раз воспользовался этим плагином. Это то, что мы так долго ждали.

P.S. С некоторых пор плагин стал платным. Месяц бесплатно, потом 1.5$ в месяц или 15$ в год, но у многих могут быть проблемы с оплатой.
Рекомендую попробовать. Узнаете, как оно может быть удобно.
#devfm #codereview

Регулярные выражения в Python от простого к сложному

В статье рассказывается:
— о регулярных выражениях вообще
— их плюсах в виде крутого инструмента для решения задач
— их минусах в виде write-only кода и других нюансах
— о базовом синтаксисе
— о применении регулярок в питоне с кучей примеров
— о разных сложных конструкциях

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

Недавно мы предлагали удобный сервис для проверки регулярок regex101.
#python #skills

Страх и ненависть в IT

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

Чрезмерная сложность. Число задействованных технологий в любом проекте сейчас действительно велико. Но эти технологий упрощают жизнь разработчика. Бизнес в среднем не будет платить за то, что разработчики "поиграются в технологии". Если бы условный docker не давал выгоды бизнесу, его бы не применяли. Естественно, локально может быть что угодно — и команда из 3 разработчиков с 1 сервером может убедить руководителя, что им нужен kubernetes. Но в среднем технология, которая не даёт выгоды, не выживает. Рыночек порешает.

Слишком много всего. Тут в кучу смешаны инструменты, языки и фреймворки, а к ним добавлены книги и конференции. Опять же, инструменты призваны ускорять разработку за счёт переиспользования готовых компонент. Сейчас на коленке можно сделать систему с функционалом, просто немыслимым десять лет назад. А жаловаться на книги и доступность знаний... Ну такое. Вероятно, человек не застал время, когда единственным источником знаний был поход в библиотеку ногами. Есть, конечно, и нюанс. Обилие информации заставляет освоить ещё один инструмент — поисковик, а в дополнение прокачать умение отличить хороший материал от плохого.

Собеседования. Вот тут спорить не с чем. В ИТ сложилась совершенно идиотская ситуация, когда умение проходить собеседование никак не коррелирует с ценностью работника. Проблеме уже не один десяток лет, и решения пока не видно.

Айтишники. Блок со стереотипами. Вокруг нас у разработчиков куча интересов из разных сфер. С руководителями вопрос актуальный в том плане, что до сих пор не сложилось адекватной практики менеджерства. Переквалификация из разработчика в менеджера часто проходит с плохим итогом, а отдельно менеджеров готовят из рук вон плохо. Кто-то знает годные институты / курсы / что угодно по подготовке team leader и product manager?

Бизнес. Тут, наконец, автор вспоминает, что ИТ создано для производства ценностей. Важно понимать, что бизнесу нужен продукт, а его внутреннее устройство бизнесу интересно мало. Бизнес вынужден балансировать на грани. Если сделать избыточно качественно, то выйдет нерентабельно. Если сделать избыточно плохо, то продукт не взлетит или потребует избыточно много ресурсов на поддержку.

Здоровье. Когда проходит допинг молодости, требуется соблюдать life-work balance и следить за здоровьем. Последним стоит заниматься с молодости.

В комментариях напоминают, что всё в ИТ – абстракция и вспоминают про factorio.
#devfm #edu

Пятничное развлекательное

Занятный 30-минутный ролик Белый хакер разбирает сцены из фильмов. Местами хакер душнит, но было очень приятно вспомнить подборку этих фильмов и критически осмыслить ряд фрагментов:

Мистер Робот
Ограбление по-итальянски
Матрица: Перезагрузка
Кто я
Девушка с татуировкой дракона
Брат 2
Черное зеркало
Хакеры
Сноуден

#fun