Сборник статей «Microservices: Science and Engineering»

Part I Opening
- Microservices: The Evolution and Extinction of Web Services?
- Size Matters: Microservices Research and Applications

Part II Migration
- Migrating to Microservices
- Assessing Your Microservice Migration

Part III Modeling
- Microservices Anti-patterns: A Taxonomy
- Modeling Microservice Conversations with RESTalk
- Graphical and Textual Model-Driven Microservice Development

Part IV Development and Deployment
- A Formal Approach to Microservice Architecture Deployment
- Autonomic Decentralized Microservices: The Gru Approach and Its Evaluation
- A Hybrid Approach to Microservices Load Balancing

Part V Applications
- Towards the Digital Factory: A Microservices-Based Middleware for Real-to-Digital Synchronization
- Using Microservices to Customize Multi-tenant Software-as-a-Service
- You Are Not Netflix

Part VI Education
- DevOps and Its Philosophy: Education Matters!

Продолжается прием заявок на выступления на ArchDays. Если вам есть чем поделиться, оставляйте заявку. Если сомневаетесь, можете написать мне напрямую и задать интересующие вопросы (@sergey486)

Формирование программы в самом разгаре!

SAGA - подборка ссылок из обсуждений чата канала:

🔷 Первоисточник по SAGA: "SAGAS" by Hector Garcia-Molina, Kenneth Salem

🔷 Перевод первоисточника по SAGA: "Гектор Гарсия-Молина и Кеннет Салем — «Саги»" / Михаил Ланкин

🔷 Applying the Saga Pattern • Caitie McCaffrey • GOTO 2015

🔷 Saga distributed transactions pattern

🔷 Process Manager Pattern

🔷 Compensating Transaction pattern

🔷 Пример реализации SAGA на Enterprise Integration Patterns (source code)

🔷 Пример реализации Process Manager от сообщества Microsoft (комментарий Greg Young). Альтернативы и обоснование.

🔷 Patterns and implementations for a banking cloud transformation

🔷 Несколько реализаций саг:
- https://axoniq.io
- https://eventuate.io/abouteventuatetram.html
- https://github.com/eclipse/microprofile-lra
- https://github.com/jbosstm/narayana/tree/master/rts/lra

🔷 Awesome workflow engines

🔷 "A long-running transaction model of workflow" by Quanzhou Hu; Jia Liu; Yi Zhuang; Yi Liu

🔷 "The CORBA Activity Service Framework for supporting extended transactions" by Iain Houston, M. C. Little, Ian Robinson, Santosh K. Shrivastava, Stuart M. Wheater

🔷 "What are long running processes?" by Bernd Rücker

🔷 Чем отличается SAGA от Process Manager:
- https://event-driven.io/en/saga_process_manager_distributed_transactions/

- https://stackoverflow.com/a/33652837

- https://blog.devarchive.net/2015/11/saga-vs-process-manager.html?m=1

🔷 "Eventually consistent" by Werner Vogels

🔷 "ACID properties of transactions"

🔷 "Atomicity :: Chapter 12. Berkeley DB Transactional Data Store Applications"

🔷 "Atomic - indivisible, not capable of being cut/divided into smaller pieces"

🔷 "Consistency Models"

🔷 интервью "Modeling Uncertainty with Reactive DDD" by Vaughn Vernon reviewed by Thomas Betts, в котором V.Vernon предлагает использовать Process Manager Pattern для обработки процессов, охватывающих несколько агрегатов в условиях Eventual Consistency.

Посмотреть реализацию в исполнении V. Vernon, включая ProcessTimedOut (о чем часто спрашивают), можно здесь:
- Java
- .Net

🔷 "Camunda Platform 8 Docs :: BPMN coverage"

🔷 Eclipse Microprofile стандарт имеет понятие LRA - Long Running Application. это есть их интерпретация саг

🔷 Microprofile-compatible фреймворки а-ля micronaut.io

🔷 RedHat развивает референс имплементацию Microprofile в виде своего фреймворка quarkus.io

🔷 Red Hut Summit "Saga: The new era of transactions in a
microservices architecture" by Giovanni Marigi, Mauro Vocale. BOSTON, MA | MAY 7-9, 2019

🔷 Вот пример Camunda. их интерпретация и имплементация саг )). Там всё очень упрощено и декларативно.

🔷 Architecture standard определяет сагу в пункте 21.2.7. Ensuring Global Consistency with Saga Patterns

Спасибо, что развиваете отрасль с помощью нашего чата!

#DistributedSystems #Многоликий

Всем привет!

В прошлом году на ArchDays @varkulevich рассказал о своем проекте, «Онто». Сейчас позиционируется как «Облачная платформа для совместной работы, позволяющая объединить команды и данные в реальном времени».

Когда мы начали ассоциацию, Артем предложил попробовать Онто для наших нужд. И я благополучно отложил это предложение в долгий ящик, пока недавно @GKruglov не упомянул, что расчехлил protege для построения онтологий.

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

Пройдет в следующую пятницу, 2-го сентября в 19:00
Ссылка на регистрацию: https://us02web.zoom.us/meeting/register/tZIsfuCupzsuGNK77B7qpBLC2AbDDJGswQN8

Кучка ссылок
Питч о проекте на ФРИИ https://sprint.iidf.ru/startups/onto/
Сайт проекта: https://ontonet.ru/
Инструкция пользователя https://ontonet.ru/startingtour
Пользовательские ситуации: https://ontonet.ru/case
Техническая документация по проекту: https://ontonet.ru/info
Платформа: https://ontonet.online/
Бэклог идей пользователей https://idmsykl.ducalis.io/rice-feature-priorities/summary

Спасибо команде «Онто» за то, что рассказали про инструмент, лично мне было интересно и познавательно, навело на ряд мыслей.

Кому еще интересно, ловите видео.

https://youtu.be/T6ZTB5jBnNw

Для подписчиков канала скидка 20% на конференцию ArchDays по промокоду microservices_arch

https://archconf.ru/welcome_from_sergey

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

Расскажу подробнее в следующих постах.

Всем привет! На прошлой неделе у нас не было постов, потому что мы готовили документы для формального учереждения организации и таки учередили ее.
Теперь мы не просто канал, а целая региональная общественная организация "Объединение ИТ-Архитекторов".
Учередители:

- Баранов Сергей @sergey486
- Круглов Геннадий @GKruglov
- Лукьянов Евгений @elukianov
- Закревский Иван @emacsway

Почитать устав и ознакомиться с целями можно тут. По вопросам вступления обращаться в Joining Bot: @ru_arc_bot

Такая вот интересная штука
https://arxiv.org/pdf/2009.01702.pdf

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

Кто хотел сравнение SOA и MSA, такое попалось

Особенно порадовал пункт «Administration level» :)

В прошлую пятницу прошла конференция ArchDays.

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

Мы постарались максимально обыграть онлайн участие, отстроить звук, поставили экраны покрупнее, закупили попкорн и колу 🙂

Все презентации доступны по ссылке: https://archdays.ru/program/

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

Огромная благодарность спикерам, участникам, нас было 250 человек очно и 270 человек онлайн.

Взялся перевести статью «Microservices: The Evolution and Extinction of Web Services?» за авторством Luciano Baresi и Martin Garriga со своими дополнениями (курсивом). Это не дословный перевод, а перессказ, так что кое-что будет опущено, а кое-что наоборот раскрыто глубже (где это требуется для понимания обозначенных тезисов). Статья длинная, хочу проверить, замотивирует ли меня публикация в этот канал к тому, чтобы довести перевод до конца 🙂

Здесь буду публиковать кусочки по мере готовности, а затем все выложу в блог.
Приглашаю к конструктивному обсуждению в комментарии.
Буду выкладывать под тегом #msaevolutionwspub1 .. 2,3

———


Microservices: The Evolution and Extinction of Web Services?
Luciano Baresi and Martin Garriga

Abstract

Еще 20 лет назад SOA и Web Services были на пике популярности. Это был самый настоящий хайп. Особенность хайпа в том, что его применяют ради хайпа, а не для пользы дела, в массе своей даже не разобравшись в сути явления или технологии. Такое положение дел привело к тому, что количество определений и трактовок SOA и Web Services было примерно равно количеству внедрений 🙂 Это, в свою очередь, приводило к тому, что проблема подгонялась под решение. Сегодня то же самое происходит с микросервисами. Авторы статьи исследуют эволюционный путь от SOA к микросервисам на основе анализа литературы, как академической, так и научно-популярной.

Подгонка проблемы под решение выглядит примерно так: «мы решили распилить монолит на микросервисы, как обосновать это бизнесу?». Здесь «решение» уже выбрано, осталось найти под него проблему, а если проблем нет, то создатьпридумать её 🙂

Введение

Основная мысль заключается в том, что при широком внедрении SOA появились и новые стандарты: WSDL, BPEL, целью которых было убрать барьеры между системами в гетерогенной среде с целью снижения сложности решения задач интеграции. На практике такие решения оказались несостоятельными, главным образом из-за невозможности (by design) своевременно реагировать на постоянно меняющиеся бизнес-требования [1].

Сегодня то же с микросервисами. Авторы акцентируют внимание, что определение микросервисов как «SOA done right» не вполне корректно, потому что в микросервисах фокус смещается с reuse и composition на independence, replaceability и autonomy. В таком случае сервисы становятся микро с точки зрения их вклада в приложение, а не по количеству строк кода.

Авторы определяют следующие, определяющие микросервисы, свойства [2]:
- Независимо понимаемые
- Независимо реализуемые
- Независимо развертываемые
- Возможность одновременного сосуществование нескольких версий одного сервиса
- При необходимости –  изменение топологии в режиме реального времени
- Отдельный микросервис может быть изменен без влияния на работу других микросервисов

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

Рамках статьи авторы преследуют три цели:
- Продемонстрировать эволюционный взгляд на движение от SOA к микросервисам
- Обсудить текущие проблемы с микросервисами

[1] P. Lemberger, M. Morel, Why Has SOA Failed So Often? (Wiley, London, 2013), pp. 207–218. https://doi.org/10.1002/9781118562017.app3
[2] S. Newman, Building Microservices (O’Reilly Media, Sebastopol, 2015)


#msaevolutionwspub1 #msaevolutionwspub #перевод

Веб-сервисы тогда и сейчас

SOA(P) Services

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

Выгоды SOA

- Динамичность (деление нагрузки по нескольким инстансам сервиса)
- Повторное использование (одни и те же сервисы могут повторно использоваться разными системами)
- Модульность (сложные сервисы состоят из более простых)
- Распределенная разработка (параллельная разработка  сервисов по согласованным интерфейсам)
- Интеграция гетерогенных и легаси систем используя стандартные протоколы (SOAP)

Отдельно авторы выделяют использование стандартных языков (BPEL) для оркестрации сервисов в сложные композиции.

Далее авторы описывают причины частых провалов SOA:
- Хайп привел к тому, что внедряли там, где не нужно
- Отсутствие общепринятых стандартов привело к различиям в методах спецификации и реализации

Авторы дают отсылку к материалу «Managing Complexity of Information Systems - 2012 - Lemberger - Why Has SOA Failed So Often» и чтобы раскрыт тему глубже, приведу достаточно объемную цитату из этой статьи:

✏️«Many companies did things in the wrong order. Rather than building a robust and scalable architecture for their stable, core processes, they tried to achieve flexibility prematurely. In the most extreme cases, this led to the so-called alignment trap, namely the IT department spending most of their energy and money on maintaining an architecture that never had the time to become mature because of premature attempts to align IT with ever- changing business requirements (see section 3.3.3). It should be emphasized that an SOA architecture, if useful at all, should only be considered as a last step in any enterprise-architecture maturity model. Robustness considerations should come first.

Among companies that tried to implement SOA, many did not need it in the first place. Companies that do not benefit from flexible business processes have no reason to switch to a service approach, as this will incur heavy financial and organizational risks for an often unpredictable outcome.[...]

[...] It remains true, however, that, independently of any flexibility considerations, a service approach can still be partly motivated by reuse considerations, as an implementation of simplicity through reduction and simplicity through organization principles.»

Как своего рода альтернатива SOAP появился REST (simpler, lightweight, and cost-effective). Основными потребителями REST считались и считаются люди, а не компьютеры, появилась пользовательская композиция (mashups) и произошло отделение решений на базе семантики (планирование, формализация) от решений на базе workflow (mashup, bpel4rest).

Таким образом, большинство обозначенных ранее проблем были решены. И тут вдруг среда, в которой разрабатываются и выполняются сервисы, становится более открытой и динамичной, да еще и постоянно изменяется. И вместе с этими изменениями среды пришли проблемы гибкости и новые вызовы:

- self-configuring
- self-optimizing
- self-healing
- self-adapting
- IoT
- Prosumers

#msaevolutionwspub2 #msaevolutionwspub #перевод

share-as-little-as-possible

Микросервисы появились в ответ на эти вызовы как решение enterprise-уровня. При этом авторы ссылаются на статью Microservices vs. service-oriented architecture Марка Ричардчcа, где отличия SOA и Microservices лежит в плоскости лежащих в их основах идей: SOA реализует идею  share-as-much-as-possible, микросервисы в свою очередь – share-as-little-as-possible («the goal became how to build systems that are replaceable while being maintainable»).


О том же пишет и Мартин Фаулер:

✏️«[...]This emphasis on replaceability is a special case of a more general principle of modular design, which is to drive modularity through the pattern of change. You want to keep things that change at the same time in the same module. Parts of a system that change rarely should be in different services to those that are currently undergoing lots of churn. If you find yourself repeatedly changing two services together, that's a sign that they should be merged.»

Возвращаясь к обозначенным ранее свойствам микросервисов авторы делают вывод, что микросервисы хорошо подходят для сценариев со слабой интеграцией данных и высокой динамикой процессов, что, согласно изложенному в Managing Complexity of Information Systems - 2012 - Lemberger - Why Has SOA Failed So Often и дает возможность быстро внедрять инновации.


#msaevolutionwspub3 #msaevolutionwspub #перевод

FaaS / Serverless

Несмотря на то, что статья отражает путь эволюции к микросервисам, авторы затрагивают и технологию FaaS (function-as-a-service) как следующий шаг в развитии. FaaS выражает в себе те же принципы, что микросервисы: isolation, interchangeability, но отличается в подходах к следованию им:

– Обрабатывает запросы без предварительного выделения каких-либо вычислительных мощностей;
– Запросы выполняются в управляемых провайдером контейнерах, которые стартуют по событию и эфемерны (могут существовать только один вызов) [1]

Этот подход позволяет писать и развертывать код без учета среды выполнения, распределения ресурсов, балансировки нагрузки и масштабируемости; всеми этими аспектами занимается провайдер.

Serverless - это эволюция pay-per-use:
Virtual Machines (EC2) -> Containers (Docker) -> Ресурсы на время, необходимое для выполнения вычислений, обычно несколько секунд или миллисекунд

Выгоды очевидны:
– Экономия (модель pay-per-use с гранулярностью 100 ms у основных вендоров)
– Функции используют единую среду выполнения (обычно пул контейнеров)
– Мало кода и stateless by design
– Горизонтальное масштабирование полностью автоматическое, эластичное и быстрое

Все это упрощает масштабируемость и деплой, требующие серьезных усилий в микросервисной архитектуре.

Разумеется, FaaS/Serverless несет с собой и новые вызовы:
– Требуются методы поиска мест, в которых FaaS может принести экономическую выгоду
– Обеспечение изоляции между функциями
– Корректный уровень гранулярности при раскрытии данных и кода
– Работа с состоянием при том, что функции по-определению stateless
– Рост количества инструментов для локального деплоя и тестирования

FaaS/Serverless не подойдет, если [2]:
– Требуется собственная инфраструктура (требования регулятора или компании)
– Требуется реализация длительных операций (например, транзакций)
– Требуется избежать vendor lock (у каждого провайдера свой serverless API и SDK)
– Требуется использовать инфраструктуру еще и под иные нужды

Примеры
– AWS Lambda
– Azure Functions
– Google Firebase

Open Source решения
– IBM/Apache Openwhisk
– Quarkus
– OpenFaaS


[1] M. Roberts, Serverless architectures (2016). http://martinfowler.com/articles/serverless.html
[2] M. Stigler, Understanding serverless computing, in Beginning Serverless Computing (Springer, Berlin, 2018), pp. 1–14

#msaevolutionwspub4 #msaevolutionwspub #перевод

Текущий состав Комитета РОО "Объединение ИТ-Архитекторов" на ArchDays'22:
@emacsway , @elukianov , @GKruglov , @sergey486 .

Надеюсь, что с 10 декабря этот состав расширится.

@elukianov и @GKruglov выступили с докладами. Свою рецензию на один из них я приводил в предыдущем посте. После официальной части последовала неофициальная.

Сложности

Эволюционный взгляд позволяет увидеть, что нового привнесли микросервисы и какие принципы и концепции SOA все еще применимы.

Сложности дизайна

Несмотря на лавинообразное распространение микросервисов (microservitization), авторы указывают на недостаток академических работ в области практик и паттернов проектирования микросервисов [1]. Похоже на то, что использование принципа «design for failure» и паттернов устойчивости (resilience), вроде circuit-breaker и bulkhead, помогают получить такие качества, как:

– responsiveness (используя модель «let-it-crash»)
– fault tolerance
– self-healing
– variability characteristics

Так же исследовательский интерес представляет оценка влияния проектирования на основе stateless-функций на эластичность и масштабируемость.

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

Друга сложность – «security by design». Из-за большого числа небольших сервисов и endpoint'ов поверхность атаки в микросервисной архитектуре значительно больше, чем в SOA. Здесь контроль доступа играет решающую роль, так как каждый микросервис должен иметь возможность быстро устанавливать происхождение и подлинность каждого запроса, что сложно сделать в распределенной системе [2].

[1] S. Hassan, R. Bahsoon, Microservices and their design trade-offs: a self-adaptive roadmap, in IEEE International Conference on Services Computing (SCC)(IEEE, Piscataway, 2016), pp. 813–818
[2] J. Soldani, D. Tamburri, W.J. Van Den Heuvel, The pains and gains of microservices: a systematic grey literature review. J. Syst. Softw. 146, 215–232 (2018). https://doi.org/10.1016/j.jss.2018.09.082

#msaevolutionwspub5 #msaevolutionwspub #перевод

Фотки с ArchDays выложили в группу во вконтакте.
Вступайте, в этом году будем больше анонсов в ВК делать, как минимум митапы точно будем проводить.

UPD: ссылка на саму группу https://vk.com/archdaysconference

Вышел очередной, 27-й technology radar от thoughtworks
Изучаем: https://www.thoughtworks.com/radar