Пятничное чтиво
Завтра выступаю на RubyConfBY, расскажу о визуализации зависимостей в проекте и почему визуализация не работает прямо сейчас. Старые записи стримов можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.
—————————————
Seven Microservices Anti-patterns
Статья из разряда “если у нет подходящего опыта и культуры - микросервисы усложнят жизнь”. Ошибки, которые вынесли во время разработки
- Cohesion Chaos - когда в сервисы начинают пихать логику, которой не должно быть;
- Not taking Automation Seriously - отсутствие автоматизации в деплое и сборе метрик;
- Layered Services Architecture - попытка сделать сервис для сохранения и сервис для отображения, а еще сервис для бизнес логики и так далее;
- Relying on Consumer Sign-off - я не понял посыл, но вроде похоже на то, что привязка к консьюмингу разных частей может привести к задержкам в производстве сервиса (поправьте пожалуйста, если ошибся);
- Manual Configurations Management - отказ использования сервиса с конфигурациями и ручная настройка конфигов каждого из сервисов;
- Versioning Avoidance - отсутствие версионирования для эндпоинтов и для событий;
- Building a gateway in every service - личный фаворит, прямой вызов каждого сервиса из клиентов, вместо использования единого gateway (иногда спасает gateway для конкретного консьюмера, Backends For Frontends)
Для каждого из пунктов найдете подробное описание и пару картинок для понимания о чем говорится.
—————————————
Обзор архитектуры и сервисов Тинькофф-журнала
Статья - пример существующего медиа приложения, которое переросло вордпресс. Тиньков рассказывает об опыт, который можно взять себе на вооружение. Хотелось бы больше технических подробностей (как коммуникации между частями системы происходят). С другой стороны, интересно посмотреть как функциональность разбилась на сервисы и как это эволюционировала.
—————————————
The Entity Service Antipattern
В первой статье говорилось о “Layered Services Architecture”, поэтому ссылки закрывает статья о “The Entity Service Antipattern”. Такой паттерн описывается в “Microsoft's .NET microservices architecture ebook” и туториалах к Spring. Главная идея - проектируем сервис для онлайн шоппинга, который обращается к 4 сервисам, предоставляющим CRUD интерфейс для данных: order, cart, product, accounts (пример из статьи). В этом случае можно написать еще один сервис, который будет обращаться к двум из них: product, accounts. При этом повторение кода в product и accounts не будет дублироваться, а основная работа с данными будет в этих entity services.
В статье описывается, почему подобный подход может усугубить ситуацию и приводится восемь аргументов против паттерна.
——— одной строкой ———
- solnic опубликовал новый Open Source Status Update
Завтра выступаю на RubyConfBY, расскажу о визуализации зависимостей в проекте и почему визуализация не работает прямо сейчас. Старые записи стримов можно найти по ссылке. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.
—————————————
Seven Microservices Anti-patterns
Статья из разряда “если у нет подходящего опыта и культуры - микросервисы усложнят жизнь”. Ошибки, которые вынесли во время разработки
- Cohesion Chaos - когда в сервисы начинают пихать логику, которой не должно быть;
- Not taking Automation Seriously - отсутствие автоматизации в деплое и сборе метрик;
- Layered Services Architecture - попытка сделать сервис для сохранения и сервис для отображения, а еще сервис для бизнес логики и так далее;
- Relying on Consumer Sign-off - я не понял посыл, но вроде похоже на то, что привязка к консьюмингу разных частей может привести к задержкам в производстве сервиса (поправьте пожалуйста, если ошибся);
- Manual Configurations Management - отказ использования сервиса с конфигурациями и ручная настройка конфигов каждого из сервисов;
- Versioning Avoidance - отсутствие версионирования для эндпоинтов и для событий;
- Building a gateway in every service - личный фаворит, прямой вызов каждого сервиса из клиентов, вместо использования единого gateway (иногда спасает gateway для конкретного консьюмера, Backends For Frontends)
Для каждого из пунктов найдете подробное описание и пару картинок для понимания о чем говорится.
—————————————
Обзор архитектуры и сервисов Тинькофф-журнала
Статья - пример существующего медиа приложения, которое переросло вордпресс. Тиньков рассказывает об опыт, который можно взять себе на вооружение. Хотелось бы больше технических подробностей (как коммуникации между частями системы происходят). С другой стороны, интересно посмотреть как функциональность разбилась на сервисы и как это эволюционировала.
—————————————
The Entity Service Antipattern
В первой статье говорилось о “Layered Services Architecture”, поэтому ссылки закрывает статья о “The Entity Service Antipattern”. Такой паттерн описывается в “Microsoft's .NET microservices architecture ebook” и туториалах к Spring. Главная идея - проектируем сервис для онлайн шоппинга, который обращается к 4 сервисам, предоставляющим CRUD интерфейс для данных: order, cart, product, accounts (пример из статьи). В этом случае можно написать еще один сервис, который будет обращаться к двум из них: product, accounts. При этом повторение кода в product и accounts не будет дублироваться, а основная работа с данными будет в этих entity services.
В статье описывается, почему подобный подход может усугубить ситуацию и приводится восемь аргументов против паттерна.
——— одной строкой ———
- solnic опубликовал новый Open Source Status Update