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

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

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

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

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

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

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

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

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