Микросервисные архитектуры как очередной этап развития инфраструктурных решений в ИТ придают новый импульс процессам цифровизации бизнеса. Какое место в цепочке эволюции подходов к ИТ-архитектуре они занимают? В каком направлении развивается эта область? Какие требования предъявляют микросервисы бизнесу и ИТ-специалистам?
Ускоряющаяся цифровизация пространства вокруг нас заставляет бизнес пересматривать операционные модели, чтобы отвечать растущим ожиданиям клиентов. Компании всех отраслей стремятся обеспечивать доступность своих услуг через цифровые каналы и наращивают конкурентоспособность благодаря внедрению технологических инноваций.
Микросервисы как подход к ИТ-архитектур вместе с контейнерными средами разработки, а также DevOps стали важнейшими инструментами современной цифровой трансформации.
Почему? Микросервисный подход позволяет создавать приложения, которые способны работать на новом уровне устойчивости, масштабируемости, а также адаптироваться к любой ИТ-инфраструктуре. Именно эти качества подхода позволяют бизнесу разворачивать любые желаемые операционные модели в ответ на вызовы, связанные со стремительной цифровизацией окружения.
Компании находят в микросервисах эффективное средство от вечной головной боли, вызванной тем, что даже небольшие, но необходимые трансформации в ИТ требуют существенных ресурсных затрат и не гарантируют успех.
Однако путь к достижению этого уровня развития технологий не был легким и прямым.
Из эры монолитов...
ИТ-ландшафт любой компании можно условно разделить на две части — бизнес-приложения и оборудование, «железо» (вычислительные мощности, системы хранения данных, сетевые компоненты и другие).
Длительное время заботы по обеспечению уровней устойчивости и производительности, необходимых для решения критически важных для бизнеса задач (а иногда и сами задачи, такие как процессинг платежей), лежали непосредственно на «железе».
Но на определенном этапе развития ИТ данные функции начали переходить на уровень ПО. Так началась эпоха монолитных решений, где вся функциональность сосредоточена в программных модулях, которые тесно связаны между собой на уровне кода и разделяют ресурсы ИТ-инфраструктуры.
При этом поддержание качества сервиса обеспечивается программными механизмами, такими как кластеризация высокой надёжности, и в меньшей степени — возможностями дорогостоящего оборудования.
Типичное монолитное приложение состоит из СУБД, сервера приложения и клиентской части, при этом все процессы полностью реализованы на этих двух-трёх слоях без функционального деления. Например, практически любая АБС (автоматизированная банковская система) до недавнего времени представляла собой такой типичный ИТ-монолит.
С течением времени этот подход себя изживает. Причиной тому являются серьёзные присущие ему недостатки. Так, если происходит отказ любой составляющей монолита, это приводит к отказу всей системы и приложение «падает», а бизнес-процессы, замкнутые на нем, останавливаются.
Второй недостаток монолита: любое наращивание функциональности требует больших объемов тестирования всех компонентов приложения. Также монолиты в какой-то момент перестали успевать за скоростью развития цифровых технологий.
...через SOA к микросервисам!
В начале «нулевых» ИТ-архитекторы крупных компаний начали активно применять сервисно-ориентированный подход (SOA) к разработке ПО. Это можно считать стартовой вехой глобального направления развития ИТ-архитектуры, которое позднее приведёт к появлению и распространению такого понятия, как микросервисы.
Что такое микросервис? В общем случае это отдельное достаточно компактное приложение, наследующее концепцию SOA и нацеленное на реализацию конкретной функциональной задачи.
Вместо двух-трёх слоёв, где сосредоточены все бизнес-процессы монолитного решения, системы с микросервисной архитектурой могут состоять из десятков мини-приложений, чётко специализированных в функциональном смысле и взаимодействующих друг с другом по стандартным протоколам.
Одно из ключевых преимуществ такого подхода — бóльшая устойчивость системы в целом. Отказ одного микросервиса внутри решения на базе микросервисной архитектуры оказывает заметно меньшее влияние на другие процессы в той же системе в сравнении с монолитными решениями.
Так, если отдельный микросервис, ответственный за обработку, например, заявок на кредит (в случае банковского приложения на микросервисной архитектуре) выйдет из строя, все остальные инструменты продолжат работу.
Кроме того, на микросервисах быстрее запускается новый функционал за счёт ускоренного цикла разработки с нуля и повторного использования созданных ранее наработок посредством API. Соответственно, примерять любые технологические новинки и обкатывать бизнес-модели становится проще и дешевле.
Наконец, в микросервисных архитектурах можно использовать совершенно разные технологические стандарты и языки программирования. Это не всегда бывает оправдано, но, по крайней мере, возможно.
SOA позволяет различным частям микросервисного приложения «жить» на разных серверах и базах данных. SOA также позволяет предоставлять сервисы различным командам или поставщикам и управлять ими независимо друг от друга.
Логическая архитектура
Сервисно-ориентированный подход в целом и микросервисный в частности создает понятие абстракции сервиса, означающее, что способ реализации скрыт от пользователей и, по сути, не важен, пока приложение решает поставленные задачи.
В этой парадигме бизнес-приложения могут быть составлены из различных взаимодействующих между собой программных компонентов из разных физических точек размещения (облака, ресурсы on-premise). Кроме того, грамотное управление API позволяют обновлять функционал приложения, не влияя на качество сервиса для конечных пользователей.
Микросервисный подход и облачные модели развертывания компонентов предоставляют свободу проектирования современных бизнес-приложений как серии независимых взаимодействующих функций.
Например, микросервисный интернет-магазин может строиться по следующей схеме: в одном облаке может находиться микросервис, который загружает данные о товарах в базу данных, в другом — микросервис каталога, поддерживающий просмотр пользователями, а микросервис поиска и транзакций для оплаты располагается в ИТ-системе продавца на его инфраструктуре.
Микросервисные минусы
Несмотря на преимущества микросервисов, у них есть и ряд системных недостатков, которые необходимо учитывать.
Во-первых, сложные и объемные бизнес-процессы вовлекают в себя целый каскад микросервисов, его тестирование — очень ресурсоемкий и длительный процесс. К этому нужно быть готовым на организационном уровне, заложив в проект соответствующие сроки и бюджеты.
Во-вторых, особенности архитектуры связности различных микросервисов в рамках единого бизнес-приложения может привести к накладным расходам, связанных с сетевым взаимодействием, в отличие систем, размещенных внутри одного физического сервера или в рамках одной ИТ-системы on-premise.
Задержка при коммуникации между микросервисами будет всегда: минимизировать ее можно только за счет грамотного планирования на уровне архитектуры решения. Для этого требуется привлекать комплекс специальных инструментов и доверять проектирование опытным специалистам.
Наконец, для разработки, запуска и поддержки микросервисных архитектур требуется адаптация культуры непрерывной разработки, внедрения и поддержания информационной безопасности. Это серьезный культурный и организационный сдвиг, к которому нужно быть готовым.
Ошибки восприятия и безудержное развитие
Одна из главных ошибок при работе с микросервисами сегодня — воспринимать их как сугубо инфраструктурное решение. Многие специалисты полагают, что можно взять любой бизнес-софт, упаковать в контейнер, через API подключить к бизнес-приложению — и все, микросервисная архитектура реализована.
На практике это не так. Микросервисное приложение в подлинном значении термина должно проектироваться с учетом специфики функциональной архитектуры и возможностей облачных платформ. Только так можно получить от микросервисов максимум по всем ключевым параметрам.
Но несмотря на все сложности адаптации микросервисов, тренд к их адаптации есть, и отката не предвидится. По данным опроса, проведенного MITSloan Management совместно с Accenture Research, 67% руководителей высшего звена хотели бы заменить все базовые legacy-системы, 70% за сохранение существующих legacy-компонентов как можно дольше. 50% хотели бы получать «лучшее из двух вариантов».
Существуют подходы, объединяющие лучшие практики из legacy и микросервисной парадигмы для получения масштабируемой, гибкой и устойчивой ИТ-архитектуры, которая позволяет работать как с современными приложениями, так и с устаревшими монолитными ИТ-решениями.
Спец по микросервисам: кто он?
Микросервисные архитекторы играют роль своего рода «градостроителей», только в ИТ-пространстве. Они в общих чертах определяют «планировку» всего приложения в рамках имеющейся ИТ-инфраструктуры.
Они продумывают зонирование компонентов приложения, следят за тем, чтобы компоненты были взаимосогласованными, но сохраняли высокий уровень независимости друг от друга.
Поскольку они должны быть в курсе новых технологических веяний и неявных проблем, им необходимо хорошо знать «внутреннюю кухню» разработчиков — оптимально иметь собственный опыт работы в данной области.
Архитекторы рекомендуют определенные инструменты и технологий, определяют видение архитектуры продукта, принимая решения совместно с командой, разрабатывающей конкретные микросервисы.
Поскольку реализация микросервиса может меняться со временем, задействуя новые подходы и инструменты архитекторы должны обеспечивать техническое руководство, чтобы команда разработчиков следовала основным принципам реализации микросервиса.
Как правило, архитекторами становятся тим-лиды команд разработчиков с опытом проектирования. Набор навыков для работы с микросервисными архитектурами можно назвать базовым для всех программистов.
Сегодня к нему добавляется расширенный технологический кругозор, бэкграунд разработки высоконагруженных приложений (high load), а также глубокое знание шаблонов проектирования.
