#статья #microservices #practices #en

Эффективные Микросервисы: 10 Лучших Практик.
Effective Microservices: 10 Best Practices.

Отличная статья про принципы построения микросервисной архитектуры.

Правда, немного однобоко, например, в пункте "Microservice First" автор объясняет, что подход "начинать проект с построения монолита и последующее его разделение на микросевисы" потерпит фейл, аргументируя тем, что модули в построенном монолите будут сильно связаны друг с другом.
В моем же понимании, нужно выбирать такой путь, который на старте даст максимальную скорость в доставке фичей до пользователя.

https://towardsdatascience.com/effective-microservices-10-best-practices-c6e4ba0c6ee2

#статья #найм #ru

Краткая инструкция по найму нормальных людей в ИТ

Рано или поздно вы начинаете нанимать. Важно уметь понимать - какие люди вам нужны прямо сейчас и как правильно их интервьюить. В статье рассматриваются 3 качества, на которые нужно обращать пристальное внимание:
1. Мудрость (умение рассуждать, задавать вопросы, анализировать аргументы, не делать поспешных выводов, видеть плюсы и минусы решений, процессов, фреймворков)
2. Умение делать дела
3. Совместимость с командой

https://vc.ru/hr/73687-kratkaya-instrukciya-po-naymu-normalnyh-lyudey-v-it

#статья #фидбек #habr #ru

Как давать и получать обратную связь, если ты воробушек-социофобушек

Почти всегда мы работаем в команде.
То, что нужно всегда и везде делать на регулярной основе, если ваша команда > 1 человека - это давать фидбек. Фидбек - самый мощный инструмент синхронизации культуры в компании. Как коллеге узнать о том, что он что-то делает не так, если ему об этом никто не скажет? Тут важно понимать - вам шашечки или ехать. Если вы хотите результат, вы будете пробовать и пробовать подступиться к человеку с разных сторон, если вас не услышат с первого раза. Если для вас результат не важен, стоит порефлексировать, возможно - вы токсичный.
Самое плохое, с чем тут можно столкнуться - это пассивная агрессия. Когда люди думают, что вы все делаете не так (какую бы роль вы в этой команде не играли), но не говорят об этом прямо. Работать с этим очень сложно.
Не видел лучше статьи про то, как давать фидбек, чем эта https://habr.com/en/company/yamoney/blog/441036/

#статья #practices #medium #en

Все, что вам нужно знать о кэшировании
Everything you need to know about Caching — System Design

Когда вы делаете прототип (MVP, эксперимент), важна скорость разработки. Вы реализовываете не самые эффективные алгоритмы, не самую надежную архитектуру.
В какой-то момент вы запускаете свою функциональность и, если с продуктовой точки зрения все хорошо, то у вас появляются пользователи, потом еще пользователи, потом еще.
Вы начинаете упираться в свои быстрорешения, которые вы принимали в самом начале пути. (PS: и это нормально). Но теперь приоритеты немного меняются, вам все также нужно сохранять скорость деливери, но при этом и выдерживать рост нагрузки.

На этом этапе появляется несколько вариантов, из которых нужно будет выбирать (а на самом деле комбинировать):
1) Начать переписывать (переосмысливать) части проекта (но может сильно затормозить деливери)
2) Начать заваливать деньгами - железом (но может оказаться сильно дорого)
3) Попытаться минимальными усилиями выжать из текущих решений максимум (добавит времени, но деливери со временем будет падать)

И, если первые два пункта, вроде бы, понятны, то вот с третьим нужно чуть больше конкретики.
Обычно, самое правильное и менее костыльное решение - это кэширование (PS: один из моих самых любимых вопросов на собеседовании - это реализовать LRU кэш).
С помощью кэширования можно существенно снизить нагрузку на базы данных или сторонние сервисы.
В статье рассматриваются основные методы и подходы для организации кэширования.

https://levelup.gitconnected.com/everything-you-need-to-know-about-caching-system-design-932a6bdf3334

#статья #habr #taxi #experience #ru

Citymobil — пособие для стартапов по увеличению стабильности на фоне роста

Две статьи про опыт сервиса такси Citymobil и кейсы, с которыми столкнулась команда на стадии активного роста бизнеса.

https://habr.com/en/company/mailru/blog/444818/
В первой статье описывается путь, который прошла команда на этапе бурного роста:
1) Как считать потери от факапов
2) Выстраивание процесса разработки бекенда
3) Почему с налаженным процессом разработки появилась угроза стабильности
4) Цель - учиться на ошибках

https://habr.com/en/company/mailru/blog/445704/
Во второй статье рассматриваются самые распространенные виды аварий:
1) Плохой релиз, 500-ые ошибки
2) Плохой релиз, неоптимальный код, нагрузка на базу
3) Неудачное ручное вмешательство в работу системы
4) Пасхальное яйцо
5) Внешние причины
6) Плохой релиз, сломанная функциональность

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

Why software architects fail – and what to do about it
10 Diseases You Should Know About.

Выступление с конференции craft, которое озвучивает много проблем, которые я иногда обнаруживаю в себе (а на некоторые начну обращать внимание), но, к сожалению, дает не очень много ответов.

1. Over-Generalization Drive
Symptom: Seeing commonalities in everything and turning them into generic solutions

2. Domain Allergy
Symptom: Treating the domain as a negligible nuisance

3. Obsessive Specialization Disorder
Symptom: Believing every problem to be unique, even if it’s been solved 1,000 times

4. Unhealthy Complexity Attraction
Symptom: Being so smart you can’t be bothered by simple approaches.

5. Analysis Paralysis
Symptom: Taking longer to evaluate than to actually do it

6. Innovation Addiction
Symptom: Things become progressively less fun the closer you get to production

7. Severe Tunneling Fixation
Symptom: Enforcing an architectural apporach that clashes with the framework, libraries or tools you use.

8. Asset Addiction
Symptom: Becoming so attached to a particular tool / library / framework it becomes a fit for every problem.

9. Exaggerated Risk Aversion
Symptom: Sticking with horrible, horrible, HORRIBLE tools because they are there.

10. Impact Dissonance
Symptom: Becoming too detached from the actual system that is being delivered.

Видео
https://www.youtube.com/watch?v=AkYDsiRVqno&feature=youtu.be&t=272
вот тут есть краткая выжимка: https://retrosight.github.io/learning/why-architects-fail-tilkov.html

#видео #youtube #craft #en

CQRS (Command and Query Responsibility Segregation) pattern

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

Плюсы:
— Независимое масштабирование читающей и пишущей моделей
— Оптимальные методы и схемы данных для записи и для чтения
— Безопасность (легко обеспечить, чтобы только разрешенные поставщики меняли данные).
— Разделение проблем читателей и писателей (бизнес-логика может остаться в модели изменения данных, при этом модель чтения окажется очень простой)
— Простые запросы.

Пример.
Функциональность "пользователь логинится в приложение, нужно отображать список активных пользователей" требует разные модели изменения состояния и чтения данных.
Следуя паттерну, такую функциональность легко разделить на команды (command): "пользователь активен" и запросы (query): "выбрать список активных пользователей".
Можно использовать event-log для хранения информации о времени активности пользователя и использовать ее как "источник правды".
В то же время, для запросов можно использовать более оптимизированное для чтение хранилище.
Таким образом, сохраняя команду "пользователь активен", мы синхронизируем ее с in-memory хранилищем активных пользователей c TTL, на который мы считаем пользователя активным. Читающие клиенты будут использовать ее для чтения.

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

https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs

#pattern #microservices #practices #doc #en

RESTful API Patterns

Часто приходится изобретать одни и те же вещи при проектировании API.
В статье вместе с подробными примерами собраны концепции:
- пагинация
- фильтрация
- асинхронные операции
- версионирование
- агрегация
- локализация

https://levelup.gitconnected.com/restful-api-patterns-81930c43e494

#article #pattern #microservices #practices #en

Фильтр Блума
https://en.wikipedia.org/wiki/Bloom_filter

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

Можно воспользоваться Блум-фильтром.
Создадим в сервисе хэш-таблицу фиксированного размера и заполним ее ключами пользователей, у которых есть активные заказы. Будем для каждого пользователя перед походом в базу данных проверять - есть ли его идентификатор в этой хэш-таблице.
Но ведь будут коллизии, следовательно, ложные срабатывания? - спросите вы и будете правы. Однако, в данной задаче ложные срабатывания не приведут к проблемам.
Когда мы находим совпадение в хэш-таблице - мы все равно идем в базу данных за заказами. Если их там не окажется (по причине коллизии в хэштаблице), мы возвратим пользователю пустой список.
Однако, мы исключим большое количество пользователей, которых в этой таблице точно нет.
Размеры такой хэш-таблицы можно подобрать исходя из ваших требований и ограничений.

https://en.wikipedia.org/wiki/Bloom_filter

#algo #doc #wiki #practices #ru