Монолит первый

Когда я слышу истории о командах, использующих архитектура микросервисовя заметил общую закономерность.

1. Почти все истории успеха микросервисов начинались с монолита, который стал слишком большим и был разбит.
2. Почти все случаи, когда я слышал о системе, созданной с нуля как микросервисная система, заканчивались серьезными проблемами.

Эта закономерность заставила многих моих коллег утверждать, что не стоит начинать новый проект с микросервисами, даже если вы уверены, что ваше приложение будет достаточно большим, чтобы оправдать его.
.

Микросервисы — полезная архитектура, но даже их сторонники говорят, что их использование влечет за собой значительные
МикросервисПремиумчто означает, что они полезны только с более сложными системами. Эта премия, по сути, стоимость управления набором сервисов, замедлит работу команды, отдавая предпочтение монолиту для более простых приложений. Это приводит к весомому аргументу в пользу стратегии «сначала монолит», когда вы должны изначально создавать новое приложение как монолит, даже если вы считаете, что впоследствии оно, скорее всего, выиграет от архитектуры микросервисов.

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

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

Я слышал о разных способах реализации стратегии «сначала монолит». Логичным способом является тщательное проектирование монолита, уделяя внимание модульности в программном обеспечении, как на границах API, так и на способе хранения данных. Сделайте это хорошо, и переход на микросервисы будет относительно простым делом. Однако я бы чувствовал себя гораздо более комфортно с этим подходом, если бы услышал достаточное количество историй, где это сработало.

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

Другой распространенный подход — просто заменить монолит полностью. Мало кто считает это подходом, которым можно гордиться, однако есть преимущества в строительстве монолита как
ЖертвеннаяАрхитектура. Не бойтесь создать монолит, от которого вы потом откажетесь, особенно если монолит может быстро вывести вас на рынок.

Другой путь, с которым я столкнулся, — начать всего с пары крупнозернистых сервисов, больших, чем те, которые вы ожидаете получить в итоге. Используйте эти крупнозернистые сервисы, чтобы привыкнуть к работе с несколькими сервисами, наслаждаясь тем фактом, что такая грубая гранулярность уменьшает объем межсервисного рефакторинга, который вам нужно сделать. Затем, когда границы стабилизируются, разбейте их на более мелкозернистые сервисы.

Хотя большинство моих контактов склоняются к подходу «сначала монолит», ни в коем случае не единогласно. Контраргумент заключается в том, что начало работы с микросервисами позволяет вам привыкнуть к ритму разработки в среде микросервисов. Требуется много, возможно, слишком много дисциплины, чтобы построить монолит достаточно модульным способом, который можно было бы легко разбить на микросервисы. Начиная работу с микросервисами, вы приучаете всех к разработке в отдельных небольших командах с самого начала, а разделение команд границами сервисов значительно упрощает масштабирование усилий по разработке, когда это необходимо. Это особенно актуально для замены систем, когда у вас больше шансов на раннем этапе разработать достаточно стабильные границы. Хотя доказательств мало, я считаю, что вам не следует начинать работу с микросервисами, если у вас нет достаточного опыта создания системы микросервисов в команде.

Я не чувствую, что у меня достаточно примеров, чтобы твердо определить, как решить, использовать ли стратегию «сначала монолит». Это только начало в микросервисах, и примеров, на которых можно поучиться, относительно немного. Поэтому любые советы по этим темам следует рассматривать как предварительные, как бы уверенно они ни утверждали.

Благодарности

Я позаимствовал большую часть этих мыслей у своих коллег: Джеймса Льюиса, Сэма Ньюмана, Тиягу Паланисами и Эвана Ботчера. Комментарии Стефана Тилкова к более раннему черновику сыграли решающую роль в прояснении моих мыслей. Чад Карри создал прекрасных драконов-глифи. Стивен Лоу, Патрик Куа, Жан Роберт Д’Аморе, Челси Комло, Ашок Субраманиан, Дэн Сивец, Прасанна Пендсе, Киф Моррис, Крис Форд и Флориан Селлмайр обсуждали черновики в нашем внутреннем списке рассылки.