Макро-польза микро-сервисов: мост от legacy-архитектур к современному IT

Рассказывает Антон Херувимов, Technology Delivery Lead в компании Accenture Russia.

Цифровая трансформация, новые возможности digital-инструментов и архитектуры современных ИТ-систем создают парадигму современных технологий (New IT — так называет её компания Accenture). Она включает в себя самые продвинутые технологии (облака, ИИ, аналитику данных, машинное обучение и т. д.) и процессы (Agile, DevOps и Design Thinking), а также подразумевает несколько стадий трансформации сложной ИТ-инфраструктуры крупных компаний. Одним из первых шагов к её реализации становится адаптация слоя ИТ-микросервисов на базе существующих legacy-платформ.

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

Микросервисы для большого ИТ-будущего

Термин «микросервисная архитектура» (Microservice Architecture) обрёл популярность в последние несколько лет. Это способ разработки приложений через объединение независимо развёртываемых ИТ-сервисов. Такой подход позволяет построить вокруг сложившихся бизнес-процессов и потребностей автономный сервис. Благодаря использованию стандартных протоколов взаимодействия, например HTTP-вызовов через API и брокеров сообщений, микросервисы могут быть написаны на разных языках программирования и использовать различные технологии хранения БД.

При традиционном подходе к созданию ИТ-системы по принципу «монолита» управление больше фокусируется на технологиях. Команды формируются по технологическому принципу — разработчики, администраторы БД, аналитики данных и т. д. Такой подход вызывает серьёзные трудности при реализации бизнес-функциональности в ИТ-систему, поскольку их нужно производить через кросс-командное взаимодействие.

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

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

В реальности добавление новой функции или процесса так или иначе затрагивает остальные, но принцип микросервисной архитектуры позволяет выпускать готовые релизы в разное время и даёт каждой команде возможность работать в собственном ритме. То есть параллельно могут разрабатываться две функциональности, например поиск и способы доставки, при этом изменения в одном могут происходить хоть каждый день, а изменения в другом требуют больше времени — например из-за того, что релиз должен быть синхронизирован с запуском бизнес-процессов. В рамках микросервисного подхода на это уходит примерно одна неделя с выводом в фазу production.

По сути, микросервисы — это слой между существующей ИТ-инфраструктурой и клиентской частью интерфейса. Его можно с успехом применять практически в любой области и для решения самых разнообразных задач. Также при выборе стратегии ИТ-развития компании в пользу полного отказа от «коробочного» подхода, микросервисы могут стать надёжным и эффективным ядром новой digital-платформы для успешного роста бизнеса в 21 веке.

6 главных преимуществ микросервисной архитектуры

1. Новое качество масштабируемости. При возникновении соответствующей потребности не нужно масштабировать всю систему, разбирая её до основания, — достаточно внести необходимые изменения только на определённом участке.
2. Повышение стабильности. Поскольку микросервисы независимы друг от друга, сбои и дефекты в одном из них никак не влияют на работу остальных, система функционирует с минимальными сбоями и простоями.
3. Упрощение. Вместо единого и сверхсложного массива ИТ, компании работают с более управляемой архитектурой, где каждый компонент отвечает за свою функцию.
4. Мультиплатформенность. Микросервисы могут работать на любом устройстве, а также в on-premise и облачных средах.
5. Повторное использование. Микросервисы могут перепрофилироваться для других целей и задач после начального запуска.
6. Возможность использовать разные технологии. Agile-команды в компаниях могут работать как небольшие стартапы, не ограничиваясь одной определённой платформой или технологией благодаря микросервисам. Через микросервисы организации могут объединять различные технологии для создания действительно лучшего из всех возможных решений на настоящий момент, что значительно ускоряет внедрение инноваций.

Трудности внедрения микросервисов

По сравнению с «монолитами» микросервисы открывают следующий уровень гибкости операций через создание новых бизнес-процессов вокруг уже существующих legacy-систем. Именно поэтому сегодня многие нацелены на микросервисную трансформацию — её преимущества слишком очевидны.

Однако существует ряд подводных камней при реализации такого перехода.

Сохранение целостности компании

Главный вызов — не утратить полезные наработки, накопленные данные и опыт прошлых лет, сохранив капитальные инвестиции в ИТ-инфраструктуру прошлого поколения. То есть компания должна ускорить своё развития и «не развалиться» в процессе трансформации к современному подходу.

Большое количество микросервисов

Когда компании необходимо 10–20 микросервисов, их адаптацией и развитием управлять не так сложно. Но если организация требует для своих задач внедрения 100+ микросервисов, появляется ранее не существовавший класс задач. Как избежать дублирования функциональности, сохранить масштабируемость и управляемость, а также не допустить превращения новой архитектуры в такой же монолит, от которого изначально пытались уйти?

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

Баланс гибкости и хаоса

Третья проблема микросервисов — высокий уровень гибкости при работе над развитием платформы. Это необходимое условие микросервисного подхода, но если его не контролировать, резко возрастает риск развития хаоса в архитектуре системы. Разобраться в принципах устройства такого «хаоса», возникшего в рамках работы по микросервисным проектам, — зачастую отдельный ИТ-проект. Правильнее с самого начала работы ограничить рамки, пусть даже это немного отложит выпуск первой функциональности, чтобы потом не потратить несколько месяцев на демонтаж «окаменелостей» из микросервисов.

Переход к микросервисам в рамках концепции enterprise agility — это также вопрос корпоративной культуры, которая помогает сохранять необходимый баланс свободы и контроля.

Свободное творчество и практический эффект совместимы только при культурных сдвигах в работе компании. Архитектура, процессы, персонал — все необходимые факторы для развития микросервисов должны выстраиваться в комплексе.

Время и результаты

Перевод ИТ-ландшафта организаций на новую архитектуру не происходит за одну ночь. Как раз наоборот, иногда для этого требуется довольно длительное время, в каких-то случаях — целые годы. Мало какие вещи в современном мире настолько же сложны, как современные ИТ-системы, адаптированные к бизнес-моделям компаний, а также конкретные способы их привязки друг к другу. Тем не менее, несмотря на общую трудоёмкость демонтажа legacy-систем, полагаться на «олдскульные» ИТ в эпоху, когда парадигма New IT развивается семимильными шагами, — значит обрекать бизнес на медленную агонию. Отсюда и вытекает потребность в микросервисной архитектуре.

Продвинутые микросервисные архитектуры в их образцовом исполнения представлены сегодня в таких компаниях, как Google, Amazon и Netflix. Так, Amazon вносит изменения в свои продукты каждые 11,6 секунд, а Netflix постоянно проводит выборочные отключения вычислительных узлов для проверки влияния подобных аварий на общее качество продукта, получаемого абонентами.

Очевидно, что более консервативным организациям подобный переход только предстоит осуществить. Они совмещают старую архитектуру и новейшие подходы к развёртыванию приложений, что в терминологии Gartner называется Bimodal IT — что-то вроде переходной фазы, сочетающей элементы legacy и современных IT-систем.

Между тем, в последующие 10–20 лет legacy-модели должны быть полностью заменены на новейшие решения компаниями, которые хотят сохранить свою конкурентоспособность. В этой перспективе микросервисы и монолитные системы могут сосуществовать как привитая ветвь и ствол дерева, на котором ей предстоит прорасти и в будущем заменить собой отмирающую основу. Такой подход позволяет гарантировать, что корневая система останется незатронутой и медленно, но верно, перейдёт от старого владельца (legacy-систем) к новому (микросервисы и парадигма New IT).