Я твердо верю в то, что замечательные программы создают выдающиеся люди. Если заботиться только о технологической стороне дела, то можно упустить из виду более половины общей картины происходящего.
Подводя итог сказанному в данной главе, хочу перечислить все, что считаю основными аспектами, за которые отвечает архитектор развития.
• Концепция. Следует обеспечить наличие четко воспринимаемой технической концепции системы, что поможет последней отвечать требованиям потребителей и вашей организации.
• Чуткость. Нужно чутко воспринимать влияние ваших решений на потребителей и коллег.
• Сотрудничество. Нужно взаимодействовать с как можно большим числом коллег и сотрудников, чтобы стало легче определять, уточнять и реализовывать положения концепции.
• Приспособляемость. Следует обеспечить внесение в техническую концепцию изменений в соответствии с требованиями, которые выдвигают потребители или организация.
• Автономность. Нужно найти разумный баланс между стандартизацией и возможностью автономности в работе ваших команд.
• Руководство. Следует обеспечить соответствие реализуемой системы технической концепции.
Архитектор развития понимает, что справиться со своей нелегкой задачей он может, лишь постоянно поддерживая баланс. Внешние события так или иначе воздействуют на вас, и понимание того, где нужно им сопротивляться, а где — плыть по течению, зачастую приходит только с опытом. Но наихудшей реакцией на события, подталкивающие нас к изменениям, будет проявление еще большей жесткости или косности мышления.
Хотя многие советы, приведенные в данной главе, применимы к архитектору любых систем, микросервисы дают нам более широкие возможности для принятия решений. Поэтому способность успешно справляться со сбалансированностью компромиссов приобретает весьма большое значение.
В следующей главе мы воспользуемся вновь приобретенными знаниями о роли архитектора и приступим к обдумыванию путей поиска правильных границ для наших микросервисов.
3. Как моделировать сервисы
Рассуждения моего оппонента напоминают мне о язычниках, которые на вопрос о том, на чем стоит мир, отвечали: «На черепахе». А на чем тогда стоит черепаха? «На другой черепахе».
Итак, вам известно, что такое микросервисы, и, будем надеяться, вы понимаете, в чем их основные преимущества. Теперь, наверное, вам не терпится приступить к их созданию, не так ли? Но с чего начать? В этой главе будет рассмотрен подход к определению границ ваших микросервисов, что, надеюсь, позволит максимизировать их положительные качества и избежать ряда потенциальных недостатков. Но сначала нам нужно что-нибудь, с чем можно будет работать.
Книги о замыслах лучше воспринимаются, если в них есть примеры. Там, где это возможно, я буду делиться с вами историями из реальной жизни, но в то же время я пришел к выводу, что не менее полезно иметь под рукой какую-либо вымышленную область, с которой можно будет работать. В книге мы еще не раз будем обращаться к этой области, наблюдая за тем, как в ней работает концепция микросервисов.
Итак, перед нами современный онлайн-продавец MusicCorp. Совсем недавно компания MusicCorp занималась традиционной розничной торговлей, но, когда бизнес по продаже грампластинок рухнул, их усилия все больше стали сосредотачиваться на онлайн-торговле. У компании имеется сайт, и в ней зреет стремление удвоить свои онлайн-продажи. Ведь все эти iPod всего лишь дань моде (плееры Zune, конечно, лучше), и истинные музыкальные фанаты готовы ждать доставки на дом компакт-дисков. Качество превыше удобства, не так ли? Исходя из этого, можно ли говорить о каком-то стриминговом сервисе Spotify, который, по сути, может пользоваться успехом только у подростков?
Несмотря на некоторое отставание от общих тенденций, у MusicCorp большие амбиции. К счастью, в компании было принято решение о том, что завоевать мир будет легче всего путем максимального упрощения внесения изменений. И для победы нужны микросервисы!
Перед тем как команда из MusicCorp рванет по дистанции, создавая сервис за сервисом в попытке доставлять всем подряд восьмидорожечные ленты, притормозим и немного поговорим о наиболее важном основном замысле, которого нужно придерживаться. Как создать хороший сервис? Если вы уже испытали на себе горечь поражения при создании сервис-ориентированной архитектуры, то вполне можете понять, к чему я клоню. Но на случай, если сия участь вас миновала, хочу выделить две основные концепции: слабую связанность и сильное зацепление. Конечно, в книге будут подробно рассматриваться и другие замыслы и инструкции, но все усилия по их воплощению в жизнь будут тщетны, если неверно истолкованы эти две концепции.