Канал с историями про деврел, чтобы было интересно и полезно
Связаться: @adolgushev
База знаний: devrel.ru
Услуги: devrelagency.ru
Post #476
635
ДЕ @devrel_ru
Showing posts older than #477 · Back to latest
Микросервисы — это сервис-ориентированная архитектура программного обеспечения, при которой серверные приложения строятся из множества узкоспециализированных, легковесных сетевых сервисов. Заявленные преимущества — лучшая модульность, меньшая нагрузка на тестирование, более гибкая композиция функциональности, изоляция окружений и автономность команд разработки. Противоположность этому подходу — монолитная архитектура, где значительный объём функциональности сосредоточен в одном сервисе, который тестируется, развертывается и масштабируется как единое целое.
В Twilio Segment мы рано приняли микросервисы как лучшую практику. В ряде случаев это отлично сработало — но, как вы скоро узнаете, в других оказалось не так уж хорошо.
На раннем этапе развития Twilio Segment мы дошли до переломного момента в одном из ключевых компонентов продукта. Казалось, мы падали с дерева микросервисов, задевая каждую ветку по пути вниз. Вместо того чтобы ускорять работу, небольшая команда увязла в лавинообразно растущей сложности. Ключевые преимущества архитектуры превратились в обузы. Скорость разработки резко упала, а количество дефектов — взлетело.
В конце концов команда оказалась в ситуации, когда двигаться вперёд стало невозможно: три инженера на полной ставке тратили большую часть времени просто на то, чтобы система продолжала работать. Нужно было что-то менять. Эта статья — история о том, как мы сделали шаг назад и выбрали подход, который лучше соответствовал требованиям продукта и потребностям команды.
Изначально микросервисная архитектура решила реальную проблему - изолировала очереди и убрала “head-of-line blocking”, когда один упавший адресат тормозит всех.
Но дальше начался рост репозиториев, расхождение версий общих библиотек, рискованные обновления и операционная нагрузка. К тому же каждый сервис обладал своим профилем ресурсов и ручной настройки автоскейла.
В итоге команда объединила 140 сервисов в один монолит, собрала монорепо и стабилизировала тесты через запись/воспроизведение HTTP-трафика.
Microservices is a service-oriented software architecture in which server-side applications are constructed by combining many single-purpose, low-footprint network services. The touted benefits are improved modularity, reduced testing burden, better functional composition, environmental isolation, and development team autonomy. The opposite is a Monolithic architecture, where a large amount of functionality lives in a single service which is tested, deployed, and scaled as a single unit.
Twilio Segment adopted this as a best practice early-on, which served us well in some cases, and, as you’ll soon learn, not so well in others.
In the early days of Twilio Segment, we reached a tipping point with a core piece of Twilio Segment’s product. It seemed as if we were falling from the microservices tree, hitting every branch on the way down. Instead of enabling us to move faster, the small team found themselves mired in exploding complexity. Essential benefits of this architecture became burdens. As our velocity plummeted, our defect rate exploded.
Eventually, the team found themselves unable to make headway, with 3 full-time engineers spending most of their time just keeping the system alive. Something had to change. This post is the story of how we took a step back and embraced an approach that aligned well with our product requirements and needs of the team.
