Идея построения банковских экосистем и маркетплейсов появилась в поисках роста ARPU (англ. Average revenue per user, средняя выручка на одного пользователя), удержания клиентской базы, привлечения новых клиентов за счет бесшовного предоставления финансовых и нефинансовых сервисов. Даст ли экосистема ожидаемый результат? Однозначного ответа на этот…
Микросервисы или все же лоскутное одеяло? Насколько интеграции чувствительны к доработкам?
Отвечая на первый вопрос, хотелось бы отметить, что в нашем банке мы не гонимся за тотальным покрытием ландшафта микросервисами. Мы видим, что ценность от этого подхода есть прежде всего в областях, где есть высокая вероятность переиспользования (такие темы очевидны в авторизации и аутентификации, подписании документов, сервисах информирования, в платежах, клиентских данных, заявках на продукты и других), а также там, где необходимо быстрое масштабирование и где мы планируем или уже осуществляем работу в облачной инфраструктуре. При этом мы не торопимся переводить наши большие монолитные банковские системы (прежде всего это core-системы) на микросервисы, т.к. эффект тут не очевиден, и если будет интересно, можно будет этот вопрос раскрыть в отдельной более глубокой статье.
Ответ на второй вопрос очень простой – да, интеграции чувствительны к доработкам. Когда-то, уже наверно десятки лет назад, во времена, когда SOA был на таком же хайпе как и сейчас микросервисы, часто реализовывались такие подходы, при которых при разработке интеграции разработчики закладывали избыточный формат обмена, а интегрируемые системы сами решали, что им нужно использовать. У этого подхода есть и плюсы, но и минусов предостаточно – повышенный трафик, нагрузка на КСПД, замедления в формировании сообщения и последующем парсинге, более долгая разработка и др. Если же мы говорим о более простом подходе, подходе «минимализма» - то лишнего делать не следует, вместо этого лучше иметь возможность быстро вносить изменения в код и быстро ставить их в production.