Вы создали компанию и заказали для неё сайт. Вы оказались неплохим бизнесменом: продажи растут, клиентов все больше, открываете новые филиалы. Приходится усложнять устройство сайта, чтобы удовлетворить запросы посетителей.

Внезапно возникает проблема: объём кода вырос до полного собрания сочинений Толстого, обновления разрабатываются до скончания веков, очень сложно добавить новую технологию. Программисты хватаются за голову и за неделю тратят годовой запас кофе. Что пошло не так?

Не пугайтесь, это стандартная проблема для сложного программного обеспечения. Возможно, вам пора поменять архитектуру продукта и с монолитной перейти на микросервисную. Она позволяет минимизировать расходы на поддержку программы при помощи разделения ее на небольшие сервисы. С такими может справиться и небольшая команда программистов.

Монолитный подход считается классическим и подразумевает, что вся работа приложения реализуется на одной кодовой базе. Такой подход относительно прост в разработке и позволяет быстро реализовывать необходимый функционал, не задумываясь над проблемами коммуникации компонентов.

Приложения, построенные на монолитной архитектуре (или просто монолиты) — не просто огромные приложения с одной функцией. Они содержат отдельные классы и функции, однако те крепко связаны друг с другом. Изъятие одного модуля неизбежно вызывает изменения в работе всей системы.

Хоть монолитная архитектура и устоялась в качестве привычной для многих сервисов, она имеет ряд значимых недостатков:

Сложности возникают и с командой проекта.

При разработке монолитов команда обычно делится на три группы, каждая из которых отвечает за одну из частей приложения: пользовательский интерфейс; серверную часть и базу данных. Чем больше приложение, тем больше команда. Каждому участнику потребуется владеть экспертизой по всем бизнес-функциям, что со временем все труднее. Намного больше требуется времени для добавления нового программиста в работу — пока изучишь весь километровый код.

Распространение облачных сервисов к началу 2010-х годов привело к разочарованию разработчиков в классическом варианте архитектуры приложений. В ответ программисты предложили архитектуру микросервисов как распределенную систему простейших и легко заменяемых модулей. Они должны работать, как рабочие у конвейера: выполнять одну элементарную функцию и передавать задачу дальше. При этом микросервисы выстраиваются не иерархично, а симметрично.

Сервисы связываются между собой и с клиентами с использованием лёгких протоколов, например, HTTP или вообще — текстовыми сообщениями. В результате создается простая для настройки система, которую проще регулярно обновлять. Ключевая идея микросервиса — независимость от окружающей среды и высокий уровень повторного использования.

Каждый отдельный сервис можно программировать на том языке, который будет удобен команде. Такая независимость позволяет делить разработку компонентов системы между самостоятельными командами.

Решается проблема с новыми специалистами. Пришедший в команду разработчик осваивает функциональные особенности только того микросервиса, с которым ему предстоит работать, а не изучает систему целиком. Даже разработку одного микросервисного приложения можно разбить между несколькими самодостаточными командами с различными компетенциями.

Отказ одного сервиса не приводит к остановке системы в целом. Когда же ошибка исправлена, необходимое изменение можно развернуть только для соответствующего сервиса — вместо повторной настройки всего приложения. Правда, для этого на этапе проектирования требуется тщательно продумать связи между сервисами для достижения максимальной независимости друг от друга. В случае ошибки пользователи должны получать корректные оповещения о временной недоступности определенного сервиса без ущерба для всей системы.

Вспомним про закон Конвея: микросервисная архитектура позволяет привести разработчиков в гармонию. Структура команд повторяет устройство конечного продукта и не ставит искусственные границы.

Из крупнейших компаний мира на микросервисную архитектуру перешли Amazon, Google, Netflix и Twitter. В России их попробовали «М.Видео-Эльдорадо», «МегаФон» и не только.

О нашем опыте ухода от монолитной архитектуры читайте во второй части обзора.