Strangler Pattern
Я тут много пишу про микросервисную архитектуру, но сам в это же время разрабатывал монолит для нового сервиса. Делали мы это специально, не тратя время на выстраивание межсервисных коммуникаций. Встает вопрос — как теперь масштабироваться. Задача перехода от монолитной к микросервисной архитектуре — решенная задача, сегодня речь пойдет об одном из подходов — Strangler pattern.
Основная идея паттерна состоит в том, что вы не беретесь “переписывать” весь монолит за раз, а просто блокируете написание новой функциональности в нем.
Новые фичи начинают с точки зрения разработки стоить дороже, ведь их теперь нужно выносить в отдельный микросервис. И не просто писать новый код в новом микросервисе, но и выносить из монолита зону ответственности, в которую новая функциональность входит.
Функциональность, которая выезжает из монолита, при этом заменяется “походом” в новые сервисы. Монолит превращается в фасад.
Старый код при этом может какое-то время оставаться в монолите и даже использоваться как фолбек или дополнительная сверка работы новой логики.
Дополнительные затраты на вынос старой логики из монолита размазываются во времени и не сильно влияют на time-to-market продукта.
Через какое-то время монолит переписывается, зоны ответственности разъезжаются по микросервисам, снижается связанность.
Есть минусы/консерны у подхода, заслуживающие внимания:
— Большая фича в новой концепции может стоить очень дорого из-за того, что придется переписать большой кусок монолита.
— Можно неправильно выделить зоны ответственности из монолита, потому что будет желание “переписать поменьше”.
— Дополнительно могут возникать затраты на вынос из монолита зон ответственности, от которых ваша функциональность зависит, например, хранилища каких-то данных.
https://microservices.io/patterns/refactoring/strangler-application.html
https://serverspace.ru/about/blog/pattern-mikroservisa-strangler/
https://www.geeksforgeeks.org/strangler-pattern-in-micro-services-system-design/
Я тут много пишу про микросервисную архитектуру, но сам в это же время разрабатывал монолит для нового сервиса. Делали мы это специально, не тратя время на выстраивание межсервисных коммуникаций. Встает вопрос — как теперь масштабироваться. Задача перехода от монолитной к микросервисной архитектуре — решенная задача, сегодня речь пойдет об одном из подходов — Strangler pattern.
Основная идея паттерна состоит в том, что вы не беретесь “переписывать” весь монолит за раз, а просто блокируете написание новой функциональности в нем.
Новые фичи начинают с точки зрения разработки стоить дороже, ведь их теперь нужно выносить в отдельный микросервис. И не просто писать новый код в новом микросервисе, но и выносить из монолита зону ответственности, в которую новая функциональность входит.
Функциональность, которая выезжает из монолита, при этом заменяется “походом” в новые сервисы. Монолит превращается в фасад.
Старый код при этом может какое-то время оставаться в монолите и даже использоваться как фолбек или дополнительная сверка работы новой логики.
Дополнительные затраты на вынос старой логики из монолита размазываются во времени и не сильно влияют на time-to-market продукта.
Через какое-то время монолит переписывается, зоны ответственности разъезжаются по микросервисам, снижается связанность.
Есть минусы/консерны у подхода, заслуживающие внимания:
— Большая фича в новой концепции может стоить очень дорого из-за того, что придется переписать большой кусок монолита.
— Можно неправильно выделить зоны ответственности из монолита, потому что будет желание “переписать поменьше”.
— Дополнительно могут возникать затраты на вынос из монолита зон ответственности, от которых ваша функциональность зависит, например, хранилища каких-то данных.
https://microservices.io/patterns/refactoring/strangler-application.html
https://serverspace.ru/about/blog/pattern-mikroservisa-strangler/
https://www.geeksforgeeks.org/strangler-pattern-in-micro-services-system-design/