Какую архитектуру выбрать при разработке сложного приложения для крупного бизнеса
Быстрая реализация бизнес-идей позволяет компаниям повышать лояльность своих клиентов, становиться успешнее конкурентов. Чтобы ускорить процесс развития продукта, внедряют микросервисы, и это оказывается эффективным решением. О преимуществах такого подхода, который уже отлично зарекомендовал себя на практике, RSpectr рассказал руководитель проектов компании iiii Tech («Форайз») Ростислав Буртыль.
ДВА ПОДХОДА
Микросервисы – вариант сервис-ориентированной архитектуры ПО, который обеспечивает взаимодействие независимых друг от друга небольших, слабо связанных и легко изменяемых модулей.
Монолитная архитектура представляет собой единый модуль, работающий автономно, независимо от других приложений.
ДЛЯ КРУПНОГО БИЗНЕСА С ШИРОКОЙ ФИЛИАЛЬНОЙ СЕТЬЮ И ОГРОМНЫМ КОЛИЧЕСТВОМ РУТИННЫХ ОПЕРАЦИЙ ОПТИМАЛЬНЫМ РЕШЕНИЕМ В БОЛЬШИНСТВЕ СЛУЧАЕВ СТАНЕТ МИКРОСЕРВИСНАЯ АРХИТЕКТУРА
Возьмем в качестве примера любого представителя ритейла, который имеет подразделения не только в России, но и в странах ЕАЭС: Беларуси, Армении, Казахстане.
По своему опыту я знаю, что много времени тратится на маркировку. С каждым годом она становится обязательной для большего количества товаров и не только в вещевом ритейле, но и, например, в сегменте медицинских изделий.
При этом законодательство о маркировке не только различается в государствах, где находятся представительства ритейлера, но и меняется в рамках одной страны.
ПОЭТОМУ ЕМУ ТРЕБУЕТСЯ ТАКОЙ MVP (MINIMUM VIABLE PRODUCT, МИНИМАЛЬНО ЖИЗНЕСПОСОБНЫЙ ПРОДУКТ), В КОТОРЫЙ МОЖНО БЫСТРО ВНЕСТИ ИЗМЕНЕНИЯ И ПРИ ЭТОМ ПРОДОЛЖАТЬ РАЗВИВАТЬ ФУНКЦИОНАЛ
Зачастую бизнес такого масштаба имеет не одну информационную систему для оптимизации рабочих процессов, а в среднем 10-15 и даже более. Это CRM для сбора клиентской базы, одно или несколько решений для логистики и складского хранения, обмена документами с поставщиками, клиентами и многое другое.
ПРЕИМУЩЕСТВОМ МИКРОСЕРВИСОВ В ЭТОМ СЛУЧАЕ БУДЕТ ГАРМОНИЧНАЯ ИНТЕГРАЦИЯ С СУЩЕСТВУЮЩИМ ПАРКОМ IT-СИСТЕМ
Если приложений к интеграции много, удобнее разделить интеграционное взаимодействие на разные сервисы дорабатываемой системы.
БОНУСЫ МИКРОСЕРВИСОВ
Экономия на найме сотрудников. Использование микросервисов позволяет отдать часть работы на аутсорсинг. Например, при разработке или развитии приложения на микросервисах можно сочетать сотрудников с различными компетенциями и уровнем. Так получается больше пространства для маневра как в технологиях, так и в поиске специалистов.
Кроме того, это позволяет более гибко управлять расходами. К примеру, Python-разработчик уровня middle будет стоить существенно дешевле Java-разработчика того же уровня. Таким образом происходит оптимизация расходов, компания получает гибкость в подборе персонала или подрядчиков.
Скорость тестирования. Когда используется подход, подразумевающий регулярное развитие приложения, микросервисы выиграют в скорости выпуска новых фичей, его не нужно будет каждый раз тестировать целиком.
Нет ограничений в стеке технологий при развитии приложения. Микросервисы могут сочетать разные технологии и языки программирования. Один сервис может быть написан на Java, а другой – на Python.
МОНОЛИТ: ПЛЮСЫ И МИНУСЫ
В монолитной архитектуре даже самые незначительные на первый взгляд корректировки могут занять много времени. Причина в цикле разработки ПО:
ДАЖЕ ПРИ НЕБОЛЬШОМ ИЗМЕНЕНИИ КОДА НЕОБХОДИМО ПРОВОДИТЬ РЕГРЕССИОННОЕ ТЕСТИРОВАНИЕ ФУНКЦИОНАЛА
Проверять работоспособность всей системы, так как заранее неизвестно, как модифицированный код мог повлиять на другие ее функции.
При регулярных изменениях это создаст дополнительную нагрузку на команду тестирования. Придется проверять все составляющие архитектуры, а во время ее обновления могут приостанавливаться некоторые бизнес-процессы компании.
ДЛЯ ПРЕДСТАВИТЕЛЕЙ БИЗНЕСА ПРОСТОИ ДАЖЕ В НЕСКОЛЬКО ЧАСОВ ЧРЕВАТЫ МНОГОМИЛЛИОННЫМИ ПОТЕРЯМИ
При этом нельзя утверждать, что монолит категорически не подходит для крупного бизнеса.
У него тоже есть ряд преимуществ: разработка минимально жизнеспособного продукта (MVP) на нем происходит быстрее за счет менее гибкой структуры решения, объединения всех функций на одной платформе, отсутствия необходимости прописывать алгоритм взаимодействия отдельных сервисов. Кроме того, в большинстве случаев его проще поддерживать – не требуется большого количества специалистов с разным стеком.
Однако монолит сложнее масштабировать, и в случае ошибок в коде может рухнуть работа всей системы. Таким образом,МОНОЛИТНОЕ ПРИЛОЖЕНИЕ БУДЕТ ЭФФЕКТИВНО В НАЧАЛЕ РАЗВИТИЯ БИЗНЕСА.
Например, такая архитектура может хорошо подойти для стартапов, которым необходимо быстро и с минимальными затратами проверить гипотезу.
ПОЧЕМУ МИКРОСЕРВИСЫ НЕ ВНЕДРЯЮТСЯ ПОВСЕМЕСТНО
Не всегда крупные холдинги выбирают микросервисную архитектуру. Все зависит от целей приложения, так как они имеют и ряд недостатков. Например, на начальном этапе их сложнее разрабатывать: необходимо создать некий фундамент, или ядро приложения.
На микросервисах это занимает больше времени в сравнении с монолитом: нужно продумать архитектуру будущих сервисов и решить вопросы взаимодействия их между собой – то, как они будут обмениваться информацией. Ведь каждый отдельный сервис не знает о том, что делают другие, и имеет в распоряжении очень ограниченный набор данных.
На монолите такие задачи в принципе не приходится решать, а потому микросервисная архитектура потребует более высокой квалификации как архитектора проекта, так и разработчиков.
Также поддержка решения на микросервисах может потребовать более высокой компетенции инженеров, отвечающих за эксплуатацию приложения, поиск и анализ ошибок в его работе. Это будет сложнее ввиду распределенности функций на разные кусочки системы.
ЕЩЕ ОДНА ПРИЧИНА, ПО КОТОРОЙ БИЗНЕС МАССОВО НЕ ПЕРЕХОДИТ НА МИКРОСЕРВИСЫ, – НЕ ПРЕДПОЛАГАЕТСЯ ВЫСОКОЙ НАГРУЗКИ И РЕГУЛЯРНЫХ ДОРАБОТОК ПРОГРАММЫ
Например, на сайте или в приложении сети частных клиник редко что-то меняется, поэтому их потребности можно закрыть и решением на базе монолита.
Для бизнеса же с большой нагрузкой часто необходимо обеспечить высокую доступность решений. Это достигается за счет горизонтальной масштабируемости.
Приложение должно выдерживать большой поток пользователей и при этом обеспечивать высокую скорость отклика.
ЕСЛИ САЙТ ИЛИ ПРИЛОЖЕНИЕ БУДЕТ РАБОТАТЬ МЕДЛЕННО ИЛИ С ОШИБКАМИ – ПОКУПАТЕЛЬ ПРОСТО УЙДЕТ БЕЗ ПОКУПОК. ЭТО ОСОБЕННО ВАЖНО В ПЕРИОД РАСПРОДАЖ, КОГДА ИНТЕРНЕТ-МАГАЗИНЫ И ПРИЛОЖЕНИЯ ПЕРЕГРУЖЕНЫ
Для таких целей микросервисы подойдут лучше. Они могут выдерживать более высокие нагрузки, потому что проще масштабируются из-за своей распределенности. Если же такое решение создано на базе монолита, масштабировать его будет сложнее, и в час Х оно может подвести.
