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

Программирующий архитектор

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

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

Принципиальный подход

Правила нужны для того, чтобы им следовало дурачье и ими руководствовались мудрые люди.

Приписывается Дугласу Бадеру (Douglas Bader)

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

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

Стратегические цели

Роль архитектора сложна и без того, чтобы определять стратегические цели, поэтому, к счастью, обычно нам не нужно делать еще и это! Эти цели должны задавать общее направление деятельности компании и то, как она сама себя представляет в роли творца счастья своих клиентов. Это должны быть цели самого высокого уровня, которые могут не иметь ничего общего с технологиями. Определяться они должны на уровне компании или ее ведущего подразделения. В них закладываются намерения вроде «открыть новые рынки сбыта в Юго-Восточной Азии» или «дать клиенту максимальную возможность работать в режиме самообслуживания». Главное здесь то, к чему стремится ваша организация, а ваша задача — обеспечить технологическую поддержку данных устремлений.

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

Принципы

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

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

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

Инструкции

Инструкции описывают способы соблюдения принципов. Это набор подробных практических предписаний для выполнения задач. Зачастую они будут носить сугубо технологический характер и должны быть достаточно простыми и понятными любому разработчику. Инструкции могут включать в себя правила программирования, требования о том, что все регистрационные данные должны фиксироваться централизованно, или предписание использовать технологию HTTP/REST в качестве объединяющего стандарта. Из-за своей чисто технологической сути ин­струкции изменяются чаще принципов.

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

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

Объединение принципов и инструкций

Чьи-то принципы становятся чьими-то инструкциями. К примеру, использование HTTP/REST можно назвать принципом, а не инструкцией, и в этом не будет ничего плохого. Дело в том, что ценность представляет наличие всеобъемлющих идей, дающих представление о ходе развития системы, и наличие достаточной детализации, позволяющей описать способы осуществления этих идей. Возможно, в объ­единении принципов и инструкций не будет ничего плохого, если речь идет о небольшой группе команд или даже об одной команде. Но для более крупных организаций, в которых могут применяться различные технологии и рабочие инструкции, для разных мест могут понадобиться разные инструкции, и при этом все они будут соответствовать общему набору принципов. Например, у .NET-команды может быть один набор инструкций, а у Java-команды — другой наряду с наличием набора инструкций, общего для обеих команд. А вот принципы у них должны быть общими.

Практический пример

В ходе работы с одним из наших клиентов мой коллега, Эван Ботчер (Evan Bottcher), разработал схему, показанную на рис. 2.1. На рисунке продемонстрирована взаимосвязь целей, принципов и инструкций в очень ясной форме. В течение нескольких лет инструкции будут меняться, в то время как принципы останутся прежними. Такую схему можно распечатать на большом листе бумаги и повесить на видном месте.

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

Необходимый стандарт

При проработке инструкций и размышлении насчет компромиссов, на которые необходимо пойти, нужно определить и такой очень важный момент, как допустимая степень изменчивости вашей системы. Одним из основных способов определения неизменных качеств для всех сервисов является установка критериев отбора тех из них, поведение и качество которых не выходят за рамки допустимого. Какой же из сервисов станет добропорядочным жителем вашей системы? Какими возможностями он должен обладать, чтобы гарантировать управляемость системы, и то, что один негодный сервис не приведет к сбою всей системы? Ведь здесь как с людьми: добропорядочность жителя в одних условиях не определяет то, на что он может стать похож в каких-либо других условиях. И тем не менее есть некие общие характеристики подходящих сервисов, которых, на мой взгляд, очень важно придерживаться. Существует ряд ключевых областей, в которых допустимость слишком больших отклонений может привести к весьма жарким временам. Согласно определению Бена Кристенсена (Ben Christensen) из компании Netflix, когда мы мысленно рисуем себе крупную картину, «должна быть стройная система из множества мелких деталей с автономными жизненными циклами, способная представлять собой единое целое». Следовательно, нужно найти разумный баланс оптимизации автономии отдельно взятого микросервиса, не теряя при этом из виду общую картину.

Рис. 2.1. Практический пример принципов и инструкций

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

Мониторинг

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

Можно выбрать применение механизма активной доставки данных, при котором каждому сервису нужно доставлять данные в центр. Для метрик это может быть Graphite, а для отслеживания работоспособности — Nagios. Или можно принять решение об использовании систем опроса, самостоятельно собирающих данные из узлов. Внутри приемника технологию нужно сделать непрозрачной и не требующей от ваших систем мониторинга изменений с целью ее поддержки. Журналирование здесь входит в ту же категорию: оно должно осуществляться в одном месте.

Интерфейсы

Выбор небольшого числа определенных технологий интерфейса помогает инте­грировать новых потребителей. Лучше всего иметь один стандарт. Два — тоже неплохо. А вот наличие 20 различных стилей объединения уже никуда не годится. Это относится не только к выбору технологии и протокола. Если, к примеру, выбор пал на HTTP/REST, что вы будете использовать, глаголы или существительные? Как станете работать со страничной организацией ресурсов? Как будете справляться с управлением версиями конечных точек?

Архитектурная безопасность

Мы не можем позволить, чтобы один плохо работающий сервис нарушил общую работу. Нужно убедиться в том, что наши сервисы сами себя защищают от вредных нисходящих вызовов. Чем больше окажется сервисов, неспособных правильно обработать потенциально сбойный характер нисходящих вызовов, тем более хрупкими будут наши системы. Это означает, что вам как минимум нужно будет выдвинуть требование, чтобы каждый нисходящий сервис получил соб­ственный пул подключений, и вы даже можете дойти до того, чтобы сказать, что каждый из сервисов должен использовать предохранитель. Более подробно этот вопрос будет обсуждаться в главе 11 при рассмотрении микросервисов в более широком масштабе.

Игра по правилам важна и тогда, когда речь заходит о кодах. Если предохранители полагаются на HTTP-коды, а в отношении одного из сервисов принято решение о возврате для ошибок кодов вида 2XX или коды 4XX перепутаны с кодами 5XX, то все меры безопасности окажутся тщетными. Те же опасения возникнут, даже если вы не используете HTTP. Знание того, в чем заключается разница между подходящим и корректно обработанным запросом, плохим запросом, при котором сервис удерживается от каких-либо действий по отношению к нему, и запросом, который может быть в порядке, но точно этого сказать нельзя, поскольку сервер не работал, является ключом уверенности в возможности быстрого отказа и отслеживания возникших проблем. Если наши сервисы будут пренебрегать этими правилами, система получится более уязвимой.

Управление посредством кода

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

Экземпляры

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

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

Подгоняемый шаблон сервиса

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

Есть два микроконтейнера с открытым кодом на основе JVM-машины — Dropwizard и Karyon. Они делают схожую работу, составляя набор библиотек для обеспечения таких свойств, как проверка работоспособности, обслуживание HTTP-протокола или экспортирование метрик. То есть вы получаете готовый сервис, укомплектованный встроенным сервлет-контейнером, который можно запустить из командной строки. Великолепный способ, чтобы пуститься в путь, почему бы им не воспользоваться? Раз уж все это имеется, почему бы не взять что-нибудь вроде Dropwizard или Karyon и не добавить дополнительные свой­ства, чтобы добиться соответствия вашему контексту?

Например, вам может потребоваться предписать использование предохранителей. В таком случае можно будет интегрировать такую библиотеку предохранителей, как Hystrix. Или у вас может практиковаться обязательная отправка всех метрик на центральный Graphite-сервер, поэтому нужно будет, наверное, ввести в действие такую библиотеку с открытым кодом, как Metrics из состава Dropwizard, и настроить ее таким образом, чтобы ее средствами показатели времени отклика и частоты появления ошибок автоматически помещались в известное место.

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

Разумеется, если используются несколько разнородных технологических стеков, то для каждого понадобится соответствующий шаблон сервиса. Правда, это может стать искусным способом ограничения выбора языка в вашей команде. Если име­ющийся шаблон сервиса поддерживает только Java, то на выбор альтернативных стеков у людей может не хватить духу, если при этом им придется самостоятельно проделать существенно больший объем работы. К примеру, в Netflix особое внимание уделяется таким аспектам, как отказоустойчивость, позволяющая гарантировать невозможность сбоя всей системы при выходе из строя какой-либо ее части. Чтобы справиться с такой задачей, нужно проделать большой объем работы и убедиться, что существуют клиентские библиотеки на JVM, предоставляющие командам инструментарий, необходимый для удержания их сервисов в рамках дозволенного. Любое внедрение нового технологического стека будет означать необходимость повторно приложить те же усилия. О подобных повторных усилиях в Netflix заботятся меньше, считая, что порой пойти по неправильному пути очень просто. Если только что реализованный сервис может оказать весьма серьезное влияние на систему, то ошибки, связанные с его отказоустойчивостью, могут создать слишком высокий риск. Netflix смягчает проблему за счет применения попутных (sidecar) сервисов, ведущих локальный обмен данными с JVM-машиной, использующей соответствующие библиотеки.

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

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

Также нужно осознавать опасность, которую может нести совместно используемый код. В стремлении создать многократно используемый код можно внедрить источники связывания сервисов друг с другом. По крайней мере, в одной из организаций я узнал, что их настолько беспокоила данная проблема, что они фактически вручную копировали код шаблона своего сервиса в каждый сервис. Следовательно, на обновление основного сервисного шаблона уходило больше времени, поскольку его нужно было применять в этой системе повсеместно, но их это волновало меньше опасности связывания. Другие команды, с которыми мне приходилось общаться, считали шаблон сервиса общей зависимостью двоичного кода, хотя при этом им нужно было очень постараться, чтобы не скатиться к тенденции DRY (don’t repeat yourself — «не повторяйся»), приводящей к чрезмерной связанности системы! С особенностями этой темы нужно будет разобраться, поэтому более подробно она рассматривается в главе 4.

Технические обязательства

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

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

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

Работа с исключениями

Таковы наши принципы и инструкции, определяющие порядок создания систем. А что происходит, когда система от них отклоняется? Иногда принимается решение о том, что это всего лишь исключение из правила. В таком случае стоит, наверное, зарегистрировать такое решение где-нибудь в рабочем журнале как напоминание на будущее. При возникновении довольно большого количества исключений может появиться смысл изменить принцип или инструкцию, чтобы в них отразилось новое понимание действительности. Например, у нас может существовать инструкция, утверждающая, что для хранения данных нужно всегда использовать MySQL. Но затем возникнет вполне резонный интерес к использованию в качестве широко масштабируемого хранилища системы Cassandra, и тут мы внесем в свою инструкцию поправку, гласящую: «Большинство требований по хранению данных удовлетворять за счет применения MySQL, пока не обнаружится перспектива большого разрастания их объемов, в случает чего применять Cassandra».

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

Руководство и ведущая роль центра

Чтобы справиться со своими задачами, архитекторам нужна руководящая роль. Что подразумевается под руководством? Весьма точное определение этому понятию дается в бизнес-модели по руководству и управлению ИТ на предприятии (Control Objectives for Information and Related Technology (COBIT)): «Руководство обеспечивает уверенность в достижении целей предприятия путем сбалансированной оценки потребностей заинтересованных сторон, существующих условий и возможных вариантов, установления направления развития через приоритизацию и принятие решений, постоянного мониторинга соответствия фактической продуктивности и степени выполнения требований установленным направлению и целям предприятия».

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

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

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

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

Временами группа может принимать решения, с которыми архитектор не согласен. Как в таком случае он должен поступать? Я, который бывал ранее в подобной роли, могу вас уверить в том, что это самая непростая ситуация, с которой приходится сталкиваться. Зачастую я склоняюсь к тому, что нужно соглашаться с решением группы. Я считаю, что сделал все возможное, чтобы убедить людей, но в конечном счете был недостаточно убедителен. Группа чаще всего намного мудрее индивидуума, и я не раз убеждался в том, что не прав! И представьте себе, насколько могут опуститься руки у группы, которой дали свободу для принятия решения, но в конечном счете его проигнорировали. Однако иногда я отвергал решение группы. Но почему и когда? Как выбрать линию поведения?

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

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

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

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

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

Резюме

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

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

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

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

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

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

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

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

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

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