Микросервисная архитектура и DevOps

В сентябре 2017-го вышла книжка Нила Форда, Ребекки Персонс и Патрика Куа Building Evolutionary Architectures. Я воспользовался ознакомительной подпиской  Safari Books чтоб полистать эту книжку и постараться разобраться с девятой, наиболее непонятной, характеристикой микросервисной архитектуры по Фаулеру и Льюису (см. Microservices a definition of this new architectural term). О том, чем занимается эта группа я писал уже в апреле прошлого года в заметке [r]evolutionary architecture, но на тот момент ознакомиться с позицией авторов можно было только видеозаписям пары выступлений, презентациям и подкастам. И вот теперь вышла книжка с системным изложением идей достаточно революционных, с одной стороны, и крайней прагматичных с другой. Но давайте обо всем по порядку.

У эволюционной архитектуры есть четкое определение:

An evolutionary architecture supports guided, incremental change across multiple dimensions.

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

Напомню, что оригинальная концепция DevOps сформулирована в виде трех путей (см. например The Three Ways: The Principles Underpinning DevOps by Gene Kim ): непрерывный поток реализации изменений, обратная связь, непрерывные эксперименты и обучение. Авторы Evolutionary Architectures… идут дальше и задаются вопросом: как оценивать результаты экспериментов? Где критерии того, что хорошо и что плохо? И вот здесь они позволяют себе провести довольно смелую интервенцию подходов из области машинного обучения и искусственного интеллекта. А давайте, говорят они, мы воспользуемся инструментом фитнес-функций, используемом в генетических алгоритмах. Фитнес-функция – мера приспособленности решения к [изменяющемуся]контексту, в котором оно используется. Для архитектур таким контекстом является совокупность противоречивых нефункциональных требований и характеристик:

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

В общем, все это выглядело бы довольно абстрактным упражнением, а беглый взгляд на концепцию эволюционирующей архитектуры, возможно, вызвал бы некоторое недоверия к её авторам. Но я не стал бы упрекать их в желании хайпануть на модной ныне теме artificial intelligence, хотя бы потому, что в последующих главах книжки вы найдете довольно внятный рассказ о подходах к проектированию ИТ-решений. Разумеется, этот рассказ приведет нас к концепции микросервисов, впрочем, вполне логично и обоснованно.

Краткий обзор книги приведен здесь: Building Evolutionary Architectures. Support Constant Change, детальное содержание на странице издателя: O’Reilly Media: Building Evolutionary Architectures. Слайды: Keynote_by_Neal_Ford

Группа в Telegram для обсуждения архитектуры ИТ-решений: https://t.me/itarchitect

Один комментарий к “Микросервисная архитектура и DevOps”

  1. ” как оценивать результаты экспериментов? Где критерии того, что хорошо и что плохо? ” а для этого надо добавить в цикл потребителей и получается BizDevOps

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *