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

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

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

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

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

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

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

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


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

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

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

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

Это важные вопросы, а ответы на них далеко не всегда лежат на поверхности.
Микросервисы / распределенные системы
Мы тут в @ru_arc_chat затронули интересную тему целей разработки и целей бизнеса. Пример – видеоплатформа. Слева - бизнес, справа – разработчики. Полное деление на бизнес и IT. Здесь Player разработкой воспринимается как продукт, являясь платформой, а…
Про совместную работу заказчика и разработки можно процитировать Кента Бека, книга Экстремальное Программирование, глава «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
Напомню, что в 2019 году на ArchDays Илья Волынкин (https://www.youtube.com/watch?v=pQns6OXIi6k) поделился подготовленным в недрах Maxima Telecom документом «Тенденции развития и использования СУБД»:
https://www.dropbox.com/sh/59mlyrplctl8gwv/AAAAyDtkGsexk5SNEDs6TQAXa?dl=0&preview=Тенденции+развития+СУБД.docx
Forwarded from Russian Association of Software Architects (Eugene Lukianov)
Хорошая подборка моделей согласованности.

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


https://jepsen.io/consistency
Docker рассказали и показали в нотации Team Topologies как они структурировали компанию.

Как известно - структура компании ищет свое отражение в технической архитектуре :)

https://www.docker.com/blog/building-stronger-happier-engineering-teams-with-team-topologies/
An index for the unified microservices patterns

Авторы заморочились, всё со ссылками, интересной аналитикой 👍

https://vocal.media/01/unified-microservices-patterns-ump
Нужно ли представителям бизнеса понимать IT-ландшафт при переходе на микросервисы и если да, то зачем? 😉
Forwarded from Code of Architecture
Дочитаем Database Internals 📗

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

Вместе с ними разберем 12 — 14 главы. Поговорим о:

— механизмах, необходимых для работы eventually consistent систем, в которых существуют реплики и расхождение их состояний;
— методах перехода от моделей консистентности с одним объектом и одной операцией к выполнению многих операций атомарно.

Также обсудим книгу в целом, поделимся впечатлениями и инстайми от прочитанного.

Встречаемся в этот четверг 18 августа в 18:00 на нашем ютуб-канале.

Не забудьте включить уведомления, чтобы не пропустить начало 🔔
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
Raft - Understandable Distributed Consensus
- https://thesecretlivesofdata.com/raft/

- простая и понятная интерактивная визуализация алгоритма.

#DistributedSystems