Микросервисы / распределенные системы
3.64K subscribers
105 photos
1 video
21 files
306 links
Мысли, новости и ссылки по распределенным система и распределенной разработке.

Если есть вопросы или предложения, пишите @sergey486
Download Telegram
Это настолько жизненно, что решил репостнуть :)
Forwarded from I’m CTO, bitch
Месяц назад решил я вспомнить молодость и сделать сам какую-нибудь задачку из бэклога. За плечами почти 20 лет опыта в IT в самых разных ролях, могу не только рукой водить, но и руками поработать.

Выбрал я значит несложную таску. Там даже оценка от разрабов «3 часа» стояла. Отличная, понятная, полезная задача. Тогда ещё подумал, что управлюсь минут за 30. Как же сильно я ошибался...

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

Начал разбираться с кодом. Тот ещё треш. Посмотрел по истории, выяснил, что сервис написал Егор, которого мы 2 года назад уволили за то, что он выдавал себя за программиста. Задача оказалась плёвая, всего три строки кода написать пришлось. Только ушло у меня на эти три строки полторы грёбаных недели по 5 часов в день.

Выкатил изменения на прод. Барабанная дробь... и ничего. Проверяю на проде — нет изменений. Лезу на сервер, в коде нужные строчки есть, а открываю в браузере — их словно нет. Ещё неделю разбираюсь с хитрым кешем. Дописываю ещё пару строк в код. Заработало! Но через час прибежали саппорты с жалобами от клиентов, что сервис сломался. Смотрю в метрики и в логи — там тишина, никаких ошибок. Позже выяснили, что логирование ошибок там никто не настраивал.

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

Задеплоил на хероку и забыл.
Работает и работает, развивать не нужно.

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

И сначала я еле исходники нашел (этот сервис написать было моей личной инициативой, облегчающей жизнь коллегам,- написал и забыл).
А теперь оказалось, что оно чета собираться перестало, а у хероку за это время обновилась немного админка и надо разобраться и интеграционные точки; логины/пароли/ключи локальные протухли…

В общем - сервис еще немного полежит 😴
Самого недавно предупредили, думал фигня, а нет, все больше знакомых попадается, за сегодня уже три таких сообщения пришло (на скриншоте то, что прилетело мне, я уж думал с новым годом поздравить решили 😂)
В общем - просто предупреждение.

❗️НОВЫЙ ВИД СКАМА!

Вам приходит сообщение от друга (его взломали и запустили рассылку среди всех чатов), якобы, друг, переходи по ссылке и получи БЕСПЛАТНЫЙ телеграм премиум.

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

Самое интересное, что после отправки сообщений, они удаляют их! И вы даже можете не подозревать, что вас кто-то взломал!

КАК ОБЕЗОПАСИТЬ СЕБЯ? 👇

1. ЕСЛИ УЖЕ ПОПАЛИСЬ, ТО ПЕРЕХОДИМ В НАСТРОЙКИ —> УСТРОЙСТВА —> И ОТКЛЮЧАЕМ ВСЕ НЕИЗВЕСТНЫЕ АКТИВНЫЕ СЕАНСЫ
2. БУДЬТЕ БДИТЕЛЬНЫ И НЕ ПЕРЕХОДИТЕ НИ ПО КАКИМ ССЫЛКАМ!
👤Аутентификация клиентов и ее место в современной архитектуре

На ARCHDAYS’22 Алексей Хмельницкий, CEO
RooX,
рассказал о новом для России классе систем управления доступом — CIAM (Customer Identity and Access Management):

▪️Как цифровизация повлияла на управление доступом;
▪️Чем клиенты компании отличаются от ее сотрудников с точки зрения аутентификации;
▪️Как учесть эти отличия в архитектуре.

Смотрите запись доклада и подписывайтесь на канал👈
Надо пробовать 🙂

Hurl is a command line tool that runs HTTP requests defined in a simple plain text format.

Hurl can run HTTP requests but can also be used to test HTTP responses. Different types of queries and predicates are supported, from XPath and JSONPath on body response, to assert on status code and response headers.

https://github.com/Orange-OpenSource/hurl
(a) design principles of microservices
(b) architectural smells
(c) architectural refactorings

Freshening the Air in Microservices: Resolving Architectural Smells via Refactoring
University of Pisa, Pisa, Italy
10.1007/978-3-030-45989-5
Пообщались с другом о производительности в разработке.
Сколько бы я не пытался рассуждать на эту тему, всегда рассуждения уходят в сторону производительности производственной системы, а все метрики – это метрики ее эффективности, того, как построена система, в которой мы проектируем и разрабатываем. Примеры приведенных метрик никогда не должны использоваться против людей. Круто же, когда мы просто не пропускаем код, усложняющий продукт? Это автоматом учит людей писать более понятный код. Code Review с этим не поможет, при Code Review ты уже мысленно закончил задачу, если реквест кто-то не принял - ты исправляешь код, но исправление не учит как писат более простой код, – это разные режимы решения, разное давление контекста, разные подходы к работе.

Q: Придумали ли уже что-то в мире для сравнения производительности разработчиков?

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

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

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

То есть объективно оценить производительность разработчика в отрыве от окружающего контекста имхо не получится.
Сложную задачу нужно делить на части 🙂

Разработка состоит из трех частей:
1. Знание требуемых технологий
2. Знание предметной области продукта
3. Социальные навыки (умение быть частью команды)

Знание технологий можно оценить даже тестами;

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

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

В дальнейшем диалоге немного развивалсь мысль и получились такие варианты:

Сложность кода (цикломатическая сложность например). То есть буквально, коммита кода общая сложность выросла, упала или осталась на прежнем уровне. Инструменты для подсчета есть (sonarqube тот же).

Среднее время на разработку при решении задачии, в которой программист принимает участие. Показывает и навык декомпозиции, то есть навык управления сложностью (чем крупнее задача тем выше уровень неопределенности и выше риски; разумная тактика – снижать риски, а за счет декомпозиции мы получаем снижение рисков почти бесплатно), и дисциплину. Тут и софтскилы видно, – будет человек брать задачу которую не понимает (чем выше оценка, тем ниже уровень понимания того, что нужно сделать) или не будет.

Тестовое покрытие, – после коммита тестовое покрытие упало, осталось как было или выросло (sonar тоже умеет считать).
И вообще-то, если сложность выросла или покрытие упало, надо бы такие коммиты отвергать автоматом. Это применение паттерна Build Threshold (сборка падает при нарушении правил проекта - протечки в архитектуре, медленные тесты, нарушение соглашений об оформлении кода).

Еще можно посмотреть через паттерны Short-Lived Branches (бранчи должны быть короткоживущими, в идеале — не более нескольких дней и никогда дольше итерации) и Commit Often (каждый член команды регулярно чекинится в транк - как минимум один раз в день, после готовности каждой задачи) и договориться внутри команды, – если вчера не коммитил, поясни почему. Это провоцирует задать вопрос если затупил, а если человек изворачивается члены команды это тоже быстро заметят.
Несколько [не]очевидных атрибутов качества (не только) микросервисов

Я опишу с прицелом в микросервисы, но все то же самое актуально для любой [распределенной] системы 🙂

Стоимость исполнения (Execution cost)
Аддитивный атрибут, вычисляемый как денежная стоимость ресурсов, используемых для работы микросервиса.
Сильно зависит от выбранной платформы (aws, google cloud). Стоимость может быть оценена во время проектирования и скорректирована по результатам оценки во время выполнения.

Время отклика (Response time, latency)
Время отклика измеряется измерением времени, прошедшего между отправкой запроса и получением ответа.
Следует сравнивать со временем отклика монолита на тот же запрос.
При измерении синхронных вызовов учитывается максимальное время ответа, а для асинхронных вызовов учитывается среднее время, затраченное на вызов.

Health management / Fault tolerance / Resiliency to failure
Отказоустойчивость. Способность микросервисного решения справляться со сбоями. Микросервис удовлетворяет этому атрибуту качества путем сохранения своего внутреннего состояния и автоматического рестарта с загрузкой последнего наиболее актуального состояния (предшествующего сбою). Под отказоустойчивостью будем понимать как отказоустойчивость вычислений (рестарт), так и согласованность данных (отсутствие потерь данных).

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

Добра, счастья и благополучия!

🎄🥂
Микросервисы / распределенные системы
Пообщались с другом о производительности в разработке. Сколько бы я не пытался рассуждать на эту тему, всегда рассуждения уходят в сторону производительности производственной системы, а все метрики – это метрики ее эффективности, того, как построена система…
А можно и развить эту тему.
Если рассматривать организацию или команду как единую систему, то при оценке навыков членов команд навык обучения других становится более важным, чем уровень навыка каждого конкретного члена команды в отдельности.
Если один разработчик выполняет задачу в 10 раз быстрее, чем остальные, но не умеет передавать знания — это хуже, чем если он же выполняет в 5 раз быстрее и может научить других делать так же быстро и эффективно.
В первом случае получаем потенциальное бутылочное горлышко и в перспективе: 10x, 1x, 1x, 1x
Во второму случае в перспективе: 5x, 5x, 5x, 5x и рост всех до 10x - это вопрос значительно более короткого промежутка времени.
Попытка переосмыслить 12 factors с учетом накопленного опыта и нынешних реалий.

https://architecturenotes.co/12-factor-app-revisited/
Напишите, пожалуйста, в комментариях, – как вы переводите на русский язык термин Event Sourcing?
Может вместе найдем подходящий термин на русском.
Микросервисы / распределенные системы
Напишите, пожалуйста, в комментариях, – как вы переводите на русский язык термин Event Sourcing? Может вместе найдем подходящий термин на русском.
Варианты за первые 20 минут (из двух каналов) 😈

Хронология событий
Источник событий
Летопись
Снабженец событий
Эвент Сорсинг
Событийный источник
События как источник
Не переводим (Event Sourcing)
Базирующийся на событиях
Проистекающий из событий
Событийно-обусловленный
Событийно генерируемый
Строящийся из событий
Построенный на событиях
Регистрация событий
Генерация событий
Порождение событий
Опубликовали новое видео с ArchDays 2022

Архитектура масштабирования: ускоряем обработку и повышаем доступность данных

Спикер: Сергей Харламов
Архитектор в VK Digital Tech

Основные Тезисы:
Обзор предпосылок масштабирования и разбор цифровых стратегий современных финансовых организаций;
Паттерны проектирования и технологии масштабирования: кэширование, стриминг, захват изменений;
Примеры проектов: запуск новых online-продуктов, повышение доступности Legacy-систем и частные случаи омниканальности.

https://youtu.be/Zxs4jkiAZ1s

💎Не забывайте подписываться, чтобы не пропустить другой интересный контент на канале
Практики безопасности в микросервисах с точки зрения DevOps

Скорее всего после июня вынесу блок по безопасности из курса по проектированию микросервисов в отдельный отднодневный курс, опциональный модуль или вообще запишу серию видео и залью на ютуб всем на радость 🙂 Блок не на массового участника, конечно, под конкретный запрос. По-прежнему в 80% случаев безопасность живет в своем silo и применимость равно как и обозначенная в курсе проблематика безопасности просто не применимы в такой ситуации, да и не встраивается в существующую картину мира, если разработчик или архитектор полностью изолирован от вопросов безопасности.

Одна из основ DevOps – три пути DevOps

Небольой список практик и паттернов из мира DevSecOps, которые крайне полезны, а порой и жизненно необходимы при работе над распределенными системами (хотя будут полезны и сами по себе, конечно).

Практики первого пути (системное мышление, ускорение потока)
– Dev и Ops не ждут безопасность, безопасность – часть повседневной работы
– Использование SAST/DAST c тонкой настройка для снижения false positive
– Внутренняя база знаний с code snippets защищенного кода (как шифруем, как работаем с сертификатами, как экранируем)
– Использование актуальных версий образов
– Параллельный Security Pipeline для глубокого тестирования
– Использование Unit-тестов для проверки сценариев безопасности
– Stop The Line для дефектов безопасности

Практики второго пути (Shift Left, усиление обратной связи)
– Введение роли Security Champion, – ключевой контакт по всем вопросам ИБ в рамках конкретной команды
– Security Checks by Dev&Ops, так как поиск уязвимостей внешними компаниями не повышает навыки сотрудников, повышают периодические совместные проверки безопасности
– Тестирование безопасности на этапе анализа требований и проработки архитектуры решения, в том числе практики моделирования угроз на уровне команд
– Остановка сборки, если обнаружена серьезная уязвимость. Безопасность — часть процесса обеспечения качества.

Практики третьего пути (культура экспериментов и обучения)
– Обучение разработчиков безопасности, так как беза – сложная область знаний и навыков и ей необходимо обучать
– Проведение в командах совместных сессий по взлому (Mob hacking), организуемых Security Champions
– Анализ метрик безопасности, поиск паттернов и реакция на них; метрики безопасности как часть общей Immune System
– Введение практик Security Knowledge Management
– Проведение ретроспектив после инцидентов (Security Postmortems) с проверкой всех сервисов на наличие уязвимостей, подобных обнаруженной

Про какую практику имеет смысл рассказать/записать в первую очередь?
Forwarded from Code of Architecture
Обсудим архитектурные стили на втором стриме по Distributed Systems 💡

🕓 Но сначала о времени эфира: в этот понедельник начнем в 17:00 по Москве.

На стриме разберем вторую главу Architecture. В ней авторы дают определение software и system architecture, а также рассказывают про архитектурные стили:

— Layered architectures;
— Service-oriented architectures;
— Publish-subscribe architectures.

Также в главе разбирается промежуточный слой (middleware), который играет большое значение в распределенных системах. Далее ван Стин и Таненбаум переходят к рассмотрению системных архитектур, в которых они выделяют:

— Layered-system architectures (простая клиент-серверная архитектура, multitiered architectures);
— Symmetrically distributed system architectures (peer-to-peer системы);
— Hybrid system architectures (здесь рассказывается про cloud computing, edge-cloud computing и blockchain).

Гостями стрима станут наш коллега Алексей Тарасов, которых развивает архитектуру Тинькофф Инвестиций, и Сергей Баранов организатор и создатель конференции ArchDays, а еще автор Agile Mindset и телеграм-канала «Микросервисы — русскоязычное сообщество».

🗓Встречаемся в следующий понедельник 23 января в 17:00 по Москве на нашем ютуб-канале.
Please open Telegram to view this post
VIEW IN TELEGRAM
Оставлю здесь, чтобы скидывать ссылку при необходимости объяснить разницу между layers и tiers.

The basic idea for the layered style is simple: components are organized in a layered fashion where a component at layer Lj can make a downcall to a component at a lower-level layer Li (with i < j) and generally expects a response. Only in exceptional cases will an upcall be made to a higher-level component.
….
Many distributed applications are divided into three layers: (1) a user-interface layer, (2) a processing layer, and (3) a data layer. One approach for organizing clients and servers is then to distribute these layers across different machines…. As a first step, we make a distinction between only two kinds of machines: client machines and server machines, leading to what is also referred to as a (physically) two-tiered architecture.

Источник: M. van Steen and A.S. Tanenbaum, Distributed Systems, 4th ed., distributed-systems.net, 2023.


Layers - логическая граница, tiers - физическая.