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

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

Для управления платформой на базе микросервисов используются «конфиг серверы». Конфиг сервер может быть микросервисом в задачи которого входит распространение конфигурации системы между другими микросервисами.

Стек:
- конфиг сервер - ZooKeper
- регистратор сервисов - Eureka
- API шлюз - Zuul

Вывод: книга – отличное пособие для Java разработчиков, желающих развернуть микросервисную архитектуру у себя на проекте. Большая часть книги – это описание конкретных примеров использования и создания микросервисов на базе Java Spring. Около трети книги рассматривает теоретические аспекты построения микросервисной архитектуры. В книге много иллюстрирующих изображений, котороые помогают понять как может быть описана архитектура микросервисной системы.

Конспект книги «Functional and reactive domain modeling»

Книга начинается с краткого введения в Доменно-ориентированный дизайн (DDD) кратко рассмотрены следующие моменты:
Доменная модель (модель предметной области) – это вся информация, необходимая для перевода бизнес-задачи на язык программирования.
Bounded context (ограниченный контекст) – реализация принципа слабого зацепления на уровне модулей. Та граница внутри которой существует модель предметной области.
Domain Driven design разделяет два понятия Entity (Сущность) и Value Object (объект-значение)
Value Object – это объект связанный с конкретным значением, которое является его состоянием.
Entity – понятие более выского уровня, относящееся к доменной модели и имеющее свою собственную идентичность (неповторимость)
Service (сервис) в том числе доменный сервис – понятие более высокого уровня объединяет несколько сущностей и объектов-значений.
Сущности имеют свою собственную, внутренне присущую им идентичность. Объекты-значения — нет.
Объект-значение имеет внутреннюю иммутабельность и могут свободно перераспределяться между сущностями
Понятие эквивалентности идентификаторов относится к сущностям; понятие структурной эквивалентности — к объектам-значениям; ссылочной эквивалентности — к обоим.
Сущности имеют историю; у объектов-значений нулевой жизненный цикл.
Объект-значение всегда должен принадлежать одной или нескольким сущностям, он не может жить собственной жизнью.
Объекты-значения должны быть неизменяемыми; сущности почти всегда изменяемы.
Чтобы распознать объект-значение, мысленно замените его на integer.
Объекты-значения не должны иметь собственной таблицы в БД.
Предпочитайте объекты-значения сущностям при моделивании домена.

Доменный объект - это объекты в объектно-ориентированных компьютерных программах, выражающие сущности из модели предметной области
Доменные объекты могут создаваться через фабрики, которые создают агрегаты.
Агрегат является самым сложным из всех тактических инструментов DDD. Агрегатом называется кластер из объектов сущностей или значений. То есть эти объекты рассматриваются как единое целое с точки зрения изменения данных.
Агрегаты сохраняются в репозиториях, которые представлены базами данных (неважно SQL или NO SQL)
Словарь – важный элемент DDD содержит основные определения и термины предметной области.
Основные принципы проектирования доменных моделей в функциональном стиле
- Модель иммутабельна и представлена через алгебраические типы данных (АТД)
- поведение модели реализуется через функции в модуле, где модуль представляет из себя блок бизнес логики
- поведение оперирует над АДТ

Далее в книге идет обзорное рассмотрение функциональной парадигмы.
В основе функционального программирования лежит функциональная композиция. Например, f(g(h)) – это функциональная композиция функций одной переменной. Идея в том, что целое состоит из взаимодействия частей.
Функции высшего порядка – такие функции, которые принимают в качестве аргументов другие функции. Частным примером является функция map которая применят к списку значений какую-либо функцию и возвращает список измененных значений. Такие функции называются «комбинаторы».
Сайд эффект – любые действия функции, которые меняют внешнее окружение.
Чистые функции – такие функции, которые не имеют сайд эффектов.

Подстановочная модель вычислений (substitution model) – модель вычислений при которой происходит подстановка значений констант на место их идентификаторов
Ссылочная прозрачность и ссылочная непрозрачность — это свойства частей компьютерных программ. Выражение называется ссылочно прозрачным, если его можно заменить соответствующим значением без изменения поведения программы
Рассуждения в терминах эквивалентности (Equational reasoning) – парадигма в рамках которой и функции и их значения являются одним и тем же и их можно свободно заменять друг другом.

Реактивная модель
В рамках определения реактивной модели в книге раскрываются стандартные понятия.
Реактивная модель – модель ориентированная на потоки данных и распространение изменений. В основе модели лежит обмен сообщениями.
Основные атрибуты реактивной модели:
- отзывчивость (responsive) – реакция на действия пользователя
- эластичность (elastic) – возможность обрабатывать разную нагрузку
- отказоустойчивость (resilient) - устойчивость к ошибками
- обмен сообщениями и событиям


Обмен сообщениями подразумевает обмен событиями (Event) и командами (Command).
Доменные события обычно представлены одним из двух вариантов:
- идентификация по типу – каждому событию сопоставлен тип в системе
- собственное состояние – вся информация о событии находится внутри события.

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


Далее в книге идет описание как в рамках языка Scala реализуются основные концепции управления и проводится связь между языком и перечисленными ранее парадигмами:
- управление «эффектами»
- управление задержками
- управление ошибками.
Основные момент связанные со Scala:
- Мощная система типов
- Функциональная парадигма как основная
- Алгебраические типы данных
- Модули как члены первого класса
Далее глубоко рассмотрены функциональные паттерны для реализации реактивных моделей, в основе лежат монады и функторы (примечание, без понимания монад и функторов читать раздел бессмысленно). Так же рассмотрены вопросы построения модулей и модулеризации приложения.
Способы создания реактивных доменных моделей
- promise и future - Под future обычно имеется в виду представление переменной, доступное только для чтения, а под promise — изменяемый контейнер с одиночным присваиванием, который передаёт значение future.
- явный обмен сообщениями
- модель акторов (например, на базе Akka) – стиль обмена «отправил и забыл» позволяет организовать асинхронное, событийно-ориентированное и неблокирующее взаимодействие. Акторы – однопоточные упрощенные модели вычислений. Конкурентность достигается за счет использования большого количества акторов.
- потоковая модель

Акторы:
- извлекают сообщение из «почтового ящика»
- создают новых акторов
- обновляют собственное состояние
- отправляют сообщения другим акторам
Целостность доменных моделей
При использовании стандартного CRUD для хранения состояния моделей в реляционных СУБД есть одна проблема – в БД сохраняется конечный результат вычислений, при этом не существует возможности определить «как» этот результат был получен. Например, при выполнении цепочки банковских транзакций в БД сохраняется конечная цифра – баланс. Это проблема, так как не позволяет делать «трассировку» состояний. Это блокиурет возможность отследить исторические изменения, сделать откат транзакции и т.д. Так же реляционные БД обычно имеют существенные ограничения по гарантированию целостности данных за пределами одной ноды.
Чтобы избежать данных проблем используется два варианта моделей, обеспечивающих целостное состояние:
- CQRS – разделение операций чтения и записи на два потока
- Event sourcing – сохранения в БД не конечного состояния, а набора «событий», которые привели к этому состоянию.
Основные принципы доменного моделирования:
- мысли выражениями
- сначала абстракция, затем вычисления
- используй наиболее простую абстракцию, которая подходит
- показывай «что делать», скрывай «как делать»
- изолируй с помощью bounded context
- предпочитай future акторам
- прогнозирую на ближайшую перспективу

Вывод: книга обзорно рассматривает основные понятие связанные с функциональным программированием и DDD. Затем подробно показывает как с помощью основных инструментов SCALA реализовать DDD с помощью функционального программирования. В книге подробно рассматриваются основные паттерны и приемы функционального проектирования. Рассматриваются вопросы построения целостных моделей, вопросы тестирования. Книга требует хорошего понимания SCALA и функционального программирования, использовать книгу как учебник по SCALA не получится.

А вот это уже интересно, кажется MS окончательно отчаялся починить свои отношения с docker-nvidia и просто добавит в WSL2 возможность прямого обращения к GPU.
https://devblogs.microsoft.com/directx/directx-heart-linux/

Иначе как "китайским чудом" назвать TikTok я не могу, пару лет назад его оценивали в 75 млрд. долларов, а сегодня он уже переваливает за 100 млрд.
https://www.bloomberg.com/news/articles/2020-05-20/tiktok-owner-s-value-surpasses-100-billion-in-private-markets

Вот так думаешь создать репозиторий, где собрать основные алгоритмы, а он уже есть - https://github.com/TheAlgorithms

"Сначала они тебя не замечают, потом смеются над тобой, затем борются с тобой. А потом ты побеждаешь." Махатма Ганди. Похоже Microsoft все больше "заимствует" из мира GNU/Linux. На этот раз речь идет о Windows Package Manager... Что дальше?
https://www.theverge.com/2020/5/20/21264739/microsoft-windows-package-manager-preview-download

Я не фанат C&C от Electronic Arts, но меня радует новость, что они решили открыть исходные коды TiberianDawn.dll и RedAlert.dll под GPL. Пока это только намерение, но уже скоро код должен появиться в открытом доступе.
https://www.ea.com/games/command-and-conquer/command-and-conquer-remastered/news/remaster-update-modding

24 мая планирую провести архитектурный стрим для патронов. Это первый из серии стримов на эту тему, подробнее можно прочитать здесь - https://www.patreon.com/posts/vvedenie-v-strim-37323945

Вышла 83 версия Chrome. Мне нравится, что Google планомерно идет по пути ужесточения требований к безопасности, но при этом мне это добавляет работы, потому что в некоторых случаях "безопасность" ломает решения, которые мы используем в своих проектах.
https://www.ghacks.net/2020/05/21/chrome-83-google-starts-rollout-of-redesigned-privacy-and-security-settings/

Интересная новость про долгоиграющие аккумуляторы для электрокаров, которые могут обеспечить большое количество перезарядок. Раньше были двигатели-миллионники, теперь вот батареи. А мне все же интерекен вопрос эксплуатации электрокаров в условиях низких температур, а не количество перезарядок батареи. https://insideevs.com/news/424378/gm-million-mile-ev-battery-almost-there/

Oh, shit...

А тем временем АйтиБорода замутил крутой хакатон - https://itbeard.com//hackathones/pbh

У нас в компании для управления проектами используется GitLab, отличная альтернатива GitHub для личного пользование. Уже вышла 13-ая версия с фокусом на кибербезопасность.
https://siliconangle.com/2020/05/22/gitlab-13-rolls-new-cybersecurity-features-analytics/

Вторая жизнь старых игр. Наверное все знают что OpenAI в своем GYM позволяет тренировать AI на играх от Atari, а вот Nvidia зашла с другой стороны - они заставили искусственный интеллект самому создать игру Pacman, основываясь на записях видео этой игры.
https://www.vice.com/en_us/article/z3evp8/nvidia-says-its-ai-created-a-fully-functional-version-of-pac-man

Конспект по монолитам, зацеплению и связности из "Monolith to Microservices":
- Single-process monolith – приложение которое разворачивается в одном цикле развертывания, как правило имеет один пакет развертывания и сильную связь внутри пакета
- modular monolith – приложение, которое имеет несколько модулей с четко разделенными границами и низким зацеплением модулей, но так же развертывается в рамках одного цикла развертывания
- distributed monolith – приложение которое состоит из нескольких сервисов, но развёртывается в едином цикле развертывания.

“Delivery contention” – проблема монолитов при которой слишком много разработчиков хотят работать над одним и тем же кодом проекта.
Но при этом монолиты гораздо проще разрабатывать, сопровождать, мониторить и развертывать.

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

Зацепление реализации (Implementation coupling) – компонент А так связан с компонентом Б, что при изменении Б необходимо изменить А.

Временное зацепление (Temporal coupling) – это такое зацепление, которое возникает во время работы системы и зависит от порядка действий (их синхронности), например, такое зацепление возникает во время синхронных запросов в распределенных системах, на все время синхронизации компоненты становятся зацепленными.
Временное зацепление можно ослабить за счет кэширования или использования брокера сообщений.

Зацепление развертывание (Deployment coupling) – зацепление возникающих из-за единого цикла развертывания. Если изменения возникли в одном модуле, мы все равно должны повторно развернуть все модули, так как цикл развертывания един.
Решение Hot reload.

Доменное зацепление (Domain coupling) – зацепление между реальным (бизнес) доменом и реализацией сервисов. Если для решения бизнес-задачи нужно задействовать несколько сервисов (или микросервисов) они считаются доменно зацепленными.
Решается (по возможности) сокрытием информации. Чем меньше информации нужно для решения поставленной задачи, тем меньше зацепление.
#monolith

Идея монолитности в этой книге представляется как монолитность на уровне процесса развертывания. Если есть единый процесс развертывания, который всегда повторяется, то приложение которое лежит внутри цикла является монолитом.
#monolith

Для иллюстрации монолитных и модульных архитектур интересно разобрать аналогию с человеком, очевидно, что человек - это монолит, но при этом это модульный монолит, так как у нас есть органы, которые отвечают за конкретные функции организма, но при этом замена и разделение на части - это очень проблематичная задача, которая в большинстве случаев приводит к плачевным результатам.
Но когда несколько "монолитных людей" объединяются и решают задачу (например, строители на стройке), то они образуют более сложную структуру, которая является модульной, но для такой структуры нужна возможность управления (на стройке это прораб).
Один человек может решать простые задачи, но при возрастании сложности поставленной задачи, требуется больше людей. Это по сути и есть уход от монолитности к модульности.
В модульных системах - отдельные части это монолиты, но их тогда называют "атомарными" элементами, чтобы подчеркнуть, что это наименьшая функциональная единица архитектуры.
#monlith #архитектурные_стримы

Продолжаю конспект "Monolith to Microservices"
Три важных вопроса при переходе на микросервисную архитектуру:
- Какие цели вы хотите достигнуть благодаря переходу?
- Какие альтернативы для микросервисов существуют?
- Как вы поймете, что с микросервисами стало лучше?

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

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

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




Если приняли решение переходить на микросервисы, то следует учесть следующее:

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

8 шагов управления изменениям по Дж. Коттеру
1. Создать атмосферу безотлагательности действий (изучив рыночную ситуацию, конкурентные позиции компании; выявив и проанализировав реальные и потенциальные кризисы, благоприятные возможности)
2. Сформировать влиятельные команды реформаторов (объединив усилия влиятельных сотрудников, агентов перемен; поощряя деятельность участников сформированной команды). Развернуто и наглядно о том, как выполнять данный шаг написано в статье “Как создать команду реформаторов”.
3. Создать видение (создавая образ желаемого будущего с целью повышения активности сотрудников; разработав стратегию достижения видения). О том, как советует Дж. Коттер формулировать видение и определять стратегию читайте в отдельной заметке.
4. Пропагандировать новое видение (используя доступность изложения, метафоры, аналогии, примеры моделей нового поведения команды реформаторов)
5. Создать условия для претворения нового видения в жизнь (устраняя блокирующие новое поведение препятствия; изменяя структуры и обязанности, противоречащие новому видению; поощряя творческий подход и готовность рисковать)
6. Спланировать и достичь ближайшие результаты (планируя обязательные первые шаги; вознаграждая и пропагандируя первые успехи)
7. Закрепить достижения и расширить преобразования (создавая атмосферу доверия к новым подходам; меняя кадровый состав и проводя кадровые перестановки; распространяя успешный опыт по всей организации)
8. Институциализировать новые подходы (формализуя правила поведения; выстраивая взаимосвязь между результатами и вознаграждениями; создавая условия развития для новых качеств сотрудников).

Процесс цикличен и важно его осуществлять постепенно.

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

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

Конкретные шаги для перехода:
1. Внедрение Domain Driver Design
2. Разделение работы на разумные части (знать когда стоит остановиться)
3. Понять сущности своего дизайна и его границы (Event Storming – техника bottom-up анализа при которой определяется доменные события и обсуждается их влияние на систему)
4. Приоритезация задач на основе доменной модели (самые «востребованные» части не следует брать в работу первыми)
5. Проработать «комбинированные» состояния (часть имеющегося в монолите передается на откуп микросервисам)

6. Реорганизация команды
7. Перевод структур
8. Вносите изменения, а не просто копируйте функциональность
9. Развивайте профессиональные навыки

10. Определите контрольные точки (по которым будем понятно, что движение идет в нужном направлении)
11. Определите качественные характеристики (должны быть измеримыми и достижимыми)
12. Проводите регулярные оценки качества
13. Старайтесь рассматривать варианты решений беспристрастно.
#monlith