Можно наглядно наблюдать, как компании сталкиваются со проблемой управления сложностью современных приложений.
Создание ПО собственной разработки для внутренних нужд, для реализации ключевых бизнес-процессов компании, чаще всего основывается на принципе микросервисной архитектуры. Эта метаструктура приложения очень далека от представления последнего в виде некоторого монолитного объекта, обладающего определенными характеристиками. При использовании микросервисной архитектуры приложение конструируется в виде облака (хотел написать – массива, но слово “облако” гораздо лучше описывает картину) маленьких приложений, хорошо выполняющих только одну функцию. Отдельные экземпляры запущенных микросервисов абсолютно изолированы друг от друга, для их создания и/или удаления используются автоматические средства доставки, контейнеры. Каждый из таких сервисов имеет свои требования к входящим данным, имеет определенный выход, параметры поточной производительности. Сервисы, отвечающие за какую-либо функцию, могут быть неоднородны, т.е. различаться по версиям, появляющимся в результате улучшений или рефакторинга.
Если взглянуть на модель каневин, то можно однозначно сказать, что деятельность по поддержке такого рода приложений явно смещается в сторону снижения определенности. Деятельность по поддержке монолитных приложений в основном своем объеме находится в полностью детерминированном домене, когда нашей основной задачей становится категоризация, на основании результатов которой выполняются определенные работы. В ряде случаев, например при диагностике проблем, выявлении причин инцидентов, мы смещаемся в сторону домена Complicated, когда деятельность осуществляется на основании изучения поведения системы и анализа данных диагностических мероприятий. Выполнение деятельности на основании экспериментов, тестирования гипотез, является редким и, одновременно, наиболее дорогостоящим актом, которого всеми силами стремятся избежать.
Если наше приложение становится облаком сервисов, то все стремятся избежать превращения его внутренней архитектуры в войлочный шар, когда одни компоненты слабо упорядоченным способом взаимодействуют с практически неограниченным множеством других компонент. Если такое произойдет, то такая система будет слабо отличаться от монолитной по степени управляемости в части внесения изменений в компоненты. Этой сложностью важно управлять, и начинают яркой звездой сиять два классических процесса ITIL: управление проблемами (применение которого внутри изолированных продуктовых команд может показаться сначала неэффективным) и управление конфигурациями. Через эти два процесса мы будем пытаться управлять сложностью деятельности по эксплуатации нашего приложения, сохраняя информацию о карте компонент, их параметрах, их входящих и исходящих зависимостях, проводя эксперименты, направленные на диагностику поведения системы.
В противном случае, очень большая доля нашей эксплуатационной деятельности будет сползать в домен Complex, что слабо соответствует термину “рационально”. При всем этом, деятельность по развитию будет находиться в этом же домене и чувствовать себя как рыба в воде, обеспечивая для нас возможности раннего прототипирования, тестирования, обеспечения отказоустойчивости.
На тему микросервисной архитектуры, её преимуществ и недостатков написано уже множество книг и статей, начиная от зарубежных авторов, заканчивая нашими русскоязычными коллегами (есть прекрасные сжатые статьи на хабре). Вышесказанное, в той или иной форме, давно известно всем вовлеченным в эту деятельность. Личный контакт с предметом и чтение литературы на эту тему, сподвигли меня написать сегодняшнюю заметку.
При планировании подобной архитектуры подумайте заранее о том, как вы будете управлять всей вашей системой, учитывая проявления возросшей внутренней сложности. Вам придется подумать не только о схеме бизнес-логики, но и об обрабатываемых данных, об API, о сквозных требованиях (безопасность, надежность, производительность) к архитектурным элементам и формам (блокам), о связях с прочими внешними системами. Вам потребуется обеспечить все это тотальным мониторингом и научить работе со всем этим людей.
Добро пожаловать в реальный мир современного разработчика приложений. 🙂