Создание микросервисов

Вспомните, как детей учат кататься на велосипеде. Вы не можете ехать на нем за них. Вы наблюдаете за тем, как их шатает из стороны в сторону, но если каждый раз, когда вам будет казаться, что они могут упасть, вы станете поддерживать велосипед, они никогда не научатся ездить. И в любом случае они падают гораздо реже, чем вы ожидаете! Если же вы видите, что они вот-вот выедут на дорогу с интенсивным движением или въедут в ближайший пруд с утками, приходится вмешиваться. Так же, будучи архитектором, вы должны хорошо понимать, когда, образно говоря, ваша команда зарулит в пруд с утками. Вам также нужно знать о том, что, даже будучи уверенным в своей правоте и в необходимости остановить команду, вы можете совершить подкоп под собственную позицию, а также создать у группы ощущение, что у них нет права голоса. Иногда приходится смириться с тем решением, с которым вы не согласны. Понимание того, когда это нужно, а когда не нужно делать, дается нелегко, но временами оно просто жизненно необходимо.

Формирование команды

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

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

Я твердо верю в то, что замечательные программы создают выдающиеся люди. Если заботиться только о технологической стороне дела, то можно упустить из виду более половины общей картины происходящего.

Резюме

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

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

• Чуткость. Нужно чутко воспринимать влияние ваших решений на потребителей и коллег.

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

• Приспособляемость. Следует обеспечить внесение в техническую концепцию изменений в соответствии с требованиями, которые выдвигают потребители или организация.

• Автономность. Нужно найти разумный баланс между стандартизацией и возможностью автономности в работе ваших команд.

• Руководство. Следует обеспечить соответствие реализуемой системы технической концепции.

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

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

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

3. Как моделировать сервисы

Рассуждения моего оппонента напоминают мне о язычниках, которые на вопрос о том, на чем стоит мир, отвечали: «На черепахе». А на чем тогда стоит черепаха? «На другой черепахе».

Джозеф Баркер (1854)