Пять монументальных статей о размере микросервиса:
- "Microservices and [Micro]services" by Vaughn Vernon
- "Monolith -> Services: Theory & Practice" by Kent Beck
- "Tackling Complexity in Microservices" by Vladik Khononov
- "About Bounded Contexts and Microservices" by Alberto Brandolini
- "Размер микросервиса", Сергей Баранов

#DDD #MSA

Всем привет 👋
В рамках книжного клуба { между скобок } мы организовали интервью с тем самым Мартином Клеппманном книгу которого мы прочитали. Обсудим книгу, поговорим про будущее data systems и о новых исследованиях Мартина:
📍 https://www.inkandswitch.com/local-first/
📍https://automerge.org/

Встречаемся 30 июня в 20:00 по мск

Martin Kleppmann is a researcher in distributed systems and security at the University of Cambridge, and author of the bestselling book Designing Data-Intensive Applications (O'Reilly Media). Previously he was a software engineer and entrepreneur, co-founding and selling two startups, and working on large-scale data infrastructure at LinkedIn.

Ссылка на подключение будет чуть позже в чате https://tttttt.me/backend_megdu_skobkah

Также закидывайте ваши вопросы для Мартина в гугл форму https://forms.gle/ZCGNfZ42JJDNsEcd8

Кто дотнет умеет, норм пример в статье?

Quickly find out the log correlation in your microservice with the Dotnet example

https://betterprogramming.pub/microservice-tracing-log-in-the-distributed-system-96f49bcb7bd

UPD от @Robo_Net (спасибо):

«В доке дотнета есть более актуальная версия, которая входит в стандартную библиотеку https://docs.microsoft.com/en-us/dotnet/core/diagnostics/distributed-tracing-instrumentation-walkthroughs и по ссылочкам внизу тоже много примеров. Если конечно нужен актуальный дотнет, а не под старый фреймворк»

Эффект траектории

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

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

Рассказал про Intelligent Swarming
В конце концов всем нам приходится заниматься поддержкой того, что пилим, вот есть такой подход к суппорту, который в целом должен (но не обязан) снизить нагрузку на ключевых экспертов с одновременным ускорением решения проблем)

https://www.youtube.com/watch?v=zfnuFSAqC40

Тут мануалы:
https://www.serviceinnovation.org/intelligent-swarming/

И вдогонку занятная преза

«AWS DevOps Series Module 7 SRE and Incident Management»

Без каких инструментов современному веб проекту будет не просто?

Для домашних проектов все эти рекомендации скорее оверхед чем польза, но чем серьезнее становится проект и аудитория - тем важнее эти советы и правила.

Никогда не забывайте делать резервные копии.
⁃ Бекап должен быть максимально полезным, а значит содержать в себе только те данные, которые заново воспроизвести будет не возможно или долго-дорого.
⁃ Бекап должен быть подтвержден тестами на работоспособность сохраненной копии данных.
⁃ Бекап должен быть эксплуатирован, развертка из бекапа должна проверяться с какой-то переодичностью
⁃ Бекап должен быть безопасным. В идеале зашифрован.
⁃ Используйте специальный софт, а не bash скриптики с кроном. (хотя это тоже работает до определенного момента), но лучше - https://habr.com/ru/company/flant/blog/420055/
⁃ Используйте несколько источников хранения бекапов. Бывает так, что одного может не оказаться в какой-то момент (не доверяйте слепо облакам).

Фиксируйте ошибки приложения проактивно.
⁃ Если приложение упало, вы можете об этом никогда не узнать, если не мониторите access логи сервера.
⁃ Если приложение работает не корректно у клиента, при этом это современное spa приложение, вы об этом не узнаете примерно никогда, если не настроите правильный мониторинг такого поведения (читай сбор ошибочного поведения со стороны фронтенда) или до тех пор пока к вам не придет сам пользователь с жалобой (нужно дать возможность сообщать о багах из веб морды).
⁃ Хорошим тоном и практикой является подключение публичной sentry для фиксации ошибок, например вот так можно начать - https://habr.com/ru/post/508686/

Мониторинг работы сервера и приложения.
⁃ Чем больше всего нужно, тем больше за этим нужно наблюдения, к сожалению.
⁃ Хорошим стартом будет базовый grafana + prometheus + экспортеры метрик для фиксации работы приложения, сервера и инфраструктурных слоев.
⁃ Если есть опыт и желание, можно обойтись zabbix.
⁃ Уведомление о том, что сервер сломался и(или) что-то подходит к пиковым характеристикам можно реализовать либо через туже grafana, либо через alertmanager.
⁃ Использования облачных grafana или других инструментов для сбора и анализа метрик тоже хорошая история, если вы им доверяете (!)
⁃ Логи кстати тоже надо мониторить, тут подойдут какие-нибудь graylog или loki, или еще что-то ибо решений прям очень много.
⁃ Ну и внутреннего мониторинга не достаточно, нужно проверять что приложение работает из вне. Для этого есть saas сервисы, ну или можно реализовать самостоятельно.

⬇️ Далее

Привет!
Приглашаем на очную встречу ArchDays Recap 27 июля (ср) в Москве.

🧚ArchDays Recap — новый для нас формат, на котором приглашенные спикеры предыдущих конференций:
— расскажут о дальнейшем развитии истории из выступления;
— раскроют некоторые аспекты выступлений, важность которых была осознана уже после;
— ответят на вопросы из зала или из формы на сайте.

📍Программа и регистрация: https://archconf.ru/recap-27-07-22

Тем временем уже можно подавать заявки на выступление на ArchDays (https://archdays.ru).

Темы в этом году более общие, но при этом, как нам показалось, они совместно полны и взаимоисключающие (насколько это возможно):

1.Процессы проектирования
2. Инструменты проектирования
3. Практики проектирования
4. Обучение архитектуре/развитие в архитектора
5. Soft skills

Если у вас тема огонь и не подходит под тематики, пишите мне, разберемся, как это у нас тематики под огненную тему не нашлось 🖖

💬 "These were elucidated in the mid-70s by Yourdon & Constantine in "Structured Design" and haven't changed. Their argument goes like this:

1. We design software to reduce its cost.
2. The cost of software is ≈ the cost of changing the software.
3. The cost of changing the software is ≈ the cost of the expensive changes (power laws and all that).
4. The cost of the expensive changes is generated by cascading changes — if I change this then I have to change that and that, and if I change that then…
5. Coupling between elements of a design is this propensity for a change to propagate.
6. So, design ≈ cost ≈ change ≈ big change ≈ coupling. Transitively, software design ≈ managing coupling.

(This skips loads of interesting stuff, but I'm just trying to set up the argument for why rapid decomposition of a monolith into micro-services is counter-productive.)"

-- "Monolith -> Services: Theory & Practice" by Kent Beck

Недавно в чате было обсуждение микрофронтендов, свежая статья в тему:

https://medium.com/@anilcanerciyes/microfrontends-module-federation-for-runtime-integration-2bdac86fcf0f

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

Микросервисов тоже слегка рукавом коснулся.

Monolith First строится вокруг простой идеи — восприятие монолита как прототипа.

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

Собираем в @ru_arc список статей для переводов (в том числе с русского на английский).

Мы тут в @ru_arc_chat затронули интересную тему целей разработки и целей бизнеса.

Пример – видеоплатформа.

Слева - бизнес, справа – разработчики. Полное деление на бизнес и IT.

Здесь Player разработкой воспринимается как продукт, являясь платформой, а продуктами являются конкретные позиционирования с конкретной ЦА и конкретными доработками для этой ЦА.

В такой структуре цели бизнеса и разработки будут отличаться.

Цель «сделать универсальный player как самостоятельный продукт» противоречит, например, цели «максимально быстро занять нишу», при том, что первая цель идет от абмиций IT и сам «бизнес» о ней даже не знает, невольно спонсируя движение к этой цели, а не к своей 🙂


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

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

Идет ли цель запилить микросервисы на кубере от целей бизнеса или это наша цель реализовать свои инженерные абмиции?

Требуется универсальная платформа, создающия сильные завимости и, как следствие, – колоссальную координационную нагрузку при планировании и согласовании изменений или лучше несколько простых и конкретных реализаций, но изолированно используемых конкретной бизнес-линией или продуктом?

Это важные вопросы, а ответы на них далеко не всегда лежат на поверхности.

Про совместную работу заказчика и разработки можно процитировать Кента Бека, книга Экстремальное Программирование, глава «on-site customer»:

«Иногда менеджерам заказчика жалко жертвовать одним из реальных сотрудников только для того, чтобы он постоянно находился вместе с разработчиками и отвечал на их вопросы. Менеджеры должны решить, что является для них важным - ускорение и повышение качества или рабочее время одного или двух сотрудников. Если продукт не приносит бизнесу больше, чем приносит ему один из сотрудников предприятия, скорее всего систем не стоит того, чтобы ее разрабатывать и внедрять на производстве».

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

Из нее прекрасно видно, что удаленность заказчиков от команд, разрабатывающих универсальные решения или платформы (внутренние CRM, внутренние системы поиска, даже АБСки и прочие учетные системы) негативно влияет на скорость реализации фичей под конкретный продукт и на скорость закрытия потребностей рынка под конкретный продукт (красные стикеры).

На пробу.

A simple measure of software dependency freshness. It is a single number telling you how up-to-date your dependencies are.

https://libyear.com

#tools

Продолжается прием заявок на доклады конференции по архитектуре IT-решений ArchDays 2022!

В этом году мы возвращаемся в офлайн!
Конференция пройдет 21 октября в Москве + Online-трансляция.

Основные тематики конференции:
1. Процессы проектирования
2. Инструменты проектирования
3. Практики проектирования
4. Обучение архитектуре/развитие в архитектора
5. Soft skills
6. Кейсы

Всего в программе будет около 30 докладов и 4 очных воркшопов.

Подать заявку на выступление: https://archdays.ru/#speaker