Руководитель подразделения .NET Stack компании Ciklum Павло Матусяк рассказывает на портале Information Age, что необходимо знать о модернизации корпоративных приложений и преобразовании их из монолитных в микросервисы.
Бизнес-среда непрерывно меняется, вынуждая компании быстро реагировать, модернизируя корпоративные приложения. Это означает не только ускоренный вывод на рынок продуктов и сервисов, но и оптимизацию для сохранения конкурентоспособности.
Для крупных предприятий это сложно, поскольку их приложения и команды разработчиков по мере роста обнаруживают узкие места. Разделение монолитных приложений на небольшие автономные компоненты, каждый из которых развертывается и поддерживается собственной гибкой командой, поможет компаниям преодолеть препятствия на пути осуществления операций и сотрудничества и поддержать будущие бизнес-инициативы.
Что такое микросервисы
При создании компании ее приложения обычно являются монолитными. На первом этапе это разумно. Такие системы хорошо работают в ограниченном масштабе и требуют меньше забот. Но по мере роста компании должна развиваться и архитектура приложений. Когда система становится большой и сложной, компании обращаются к микросервисам в качестве долгосрочного инфраструктурного решения.
В широком смысле микросервисы — это все более популярный подход к разработке приложений. Он включает создание большого «приложения», которое, в сущности, представляет набор модульных компонентов, или «сервисов», каждый из которых выполняет единственную функцию, некое действие в конкретном бизнес-контексте, которое способствует достижению более широких целей компании.
Сэм Ньюмен, автор теории архитектуры микросервисов, описывает их как «небольшие совместно работающие автономные сервисы, созданные в определенной сфере бизнеса». Действительно, реализация и масштабирование конкретных бизнес-функций играет главную роль в подходе с позиций микросервисов. Каждый модуль имеет простой API, который разработчики могут использовать для решения точно определенной задачи, достижения цели бизнеса и обмена информацией с другими сервисами.
У каждого модуля собственный жизненный цикл и своя база данных, поэтому разработчики могут создавать, тестировать и выпускать каждый микросервис независимо от других. Однако, примерно как и в случае с монолитным приложением, для протекания бизнес-процесса сервисы должны взаимодействовать.
К преимуществам микросервисов относятся безопасность, скорость, гибкость и масштабируемость. Все это создает долгосрочную ценность для бизнеса. Например, микросервисы имеют свой быстрый и независимый цикл выпуска в отличие от сервисов монолитных приложений.
Но главным преимуществом архитектуры микросервисов является организация их функциональности в соответствии с потребностями бизнеса, что расширяет возможности разработчиков по внесению постепенных усовершенствований, минимизации простоев и реагированию на изменение потребностей бизнеса.
Зачем и когда переходить на микросервисы
По мере роста компании создают новые должности и функции и предъявляют более высокие требования к своим приложениям. Монолитные совершенствуются медленнее и требуют больше труда. При их обслуживании команды, состоящие из более чем 20 разработчиков, будут испытывать трудности с организацией совместной работы. Потому что даже небольшие изменения потребуют создания и развертывания совершенно нового приложения, увеличивая нагрузку на разработчиков и расходы компании.
К наиболее часто встречающимся проблемам, свидетельствующим о необходимости перемен, относятся следующие:
- длительные циклы развертывания;
- длительный простой всей системы из-за развертывания новых компонентов продукта;
- отсутствие разделения на модули. Иными словами, небольшие изменения в коде требуют переписывания, тестирования и развертывания других модулей;
- наличие унаследованных технологий;
- проблемы с масштабированием, т. е. невозможность масштабировать часть приложения;
- трудности с запуском проектов новыми разработчиками.
Руководство может также заметить, что обычные, наиболее подходящие для решения этих проблем средства со временем становятся менее эффективными. Например:
- процесс разработки ПО становится не столь линейным;
- увеличение количества работающих над системой разработчиков дает все меньший эффект;
- темпы разработки системы не отвечают требованиям бизнеса.
Микросервисы могут улучшить процессы, связанные с разработкой и обслуживанием ПО, а также усовершенствовать сотрудничество в командах при работе над гибридными проектами, требующими использования многочисленных активов. Таким образом, единый новый подход к ИТ способен повысить масштабируемость и гибкость, сократить время выхода на рынок и стимулировать рост бизнеса. Архитектура микросервисов создает фундамент для новых функций на годы вперед.
Как организовать переход к микросервисам
Осуществить переход можно двумя способами. Либо сохранить солидную базу монолитных приложений и начать создавать микросервисы на ее основе, либо постепенно трансформировать приложения в микросервисы.
В любом случае командам необходимо определить границы каждого микросервиса. Он должен инкапсулировать каждую бизнес-функцию как «привязанный контекст». Для этого командам следует минимизировать зависимости создаваемых микросервисов от монолитных приложений, организовать обмен информацией между сервисами в обход приложений и использовать новую среду, в которой приложения разложены на компоненты.
В таких условиях они могут выделять привязанный контекст для отдельных микросервисов и их баз данных, запускать и останавливать базовые операции (CRUD) для каждого микросервиса, формируя его автономию. При этом нет необходимости делить данные между базами данных нескольких микросервисов для поддержания стабильной производительности.
Для завершения формирования каждого микросервиса необходимо следующее:
- хранение личных данных для каждого микросервиса;
- сокращение числа зависимостей между микросервисами;
-
консистентность данных во всей системе. Следует избегать распределенных транзакций;
- предпочтение асинхронной связи перед синхронной;
- управляемая событиями система (предпочтительно).
После создания API микросервиса обмен информацией с оригинальным монолитным приложением может осуществляться только через него. Это подготовит сервис к полной автономии от приложения. После этого сервис становится изолированным, использующим отдельный процесс. Команды могут повторять эти действия, пока все сервисы не будут отключены от монолитного приложения.
Развертывание сервисов таким способом повышает способность организации предоставлять функции нескольких устройств и приложений. Компании могут также обеспечить бесконечную эволюцию своей архитектуры и поддерживать новые бизнес-процессы, разграничивая имеющиеся и новые модули.
Ведущие компании уже используют преимущества микросервисов и шумно хвастаются результатами. Компания Wix.com отказалась от монолитного приложения, управлявшего всеми ее процессами, в пользу микросервисов и новой корпоративной культуры, повысив масштабируемость и качество обслуживания.
Когда «единая монолитная структура» Best Buy стала узким местом, корпорация спроектировала архитектуру микросервисов, использовав своих сотрудников и идеальные процессы как необходимые компоненты.
Компания Cloud Elements, разрабатывающая платформу интеграции облачных API, применила микросервисы, чтобы соответствовать новым требования бизнеса в периоды роста.
В качестве архитектурного стиля микросервисы ориентированы на скорость разработки ПО от концепции до развертывания (т. е. «выхода на рынок»). Архитектура системы жестко привязана к процессу разработки, организации компании и ее культуре.
Микросервисы можно представить в качестве эволюционного компонента роста компании, с которым взаимодействует каждый элемент. Микросервисы появились в качестве не только ИТ-решения, но и как ответ на запросы современного рынка. Они представляют собой выигрышный вариант для бизнес-лидеров, стремящихся привести свою ИТ-инфраструктуру в соответствие с основными бизнес-целями, независимо от того, что ждет их в будущем.
