Мы уже увидели, что микросервисы дают широкое поле для выбора и, соответственно, вынуждают принимать множество решений. Например, сколько различных технологий нужно применять, можно ли разным командам использовать различные идиомы программирования и следует ли разбивать или объединять сервисы. Как прийти к принятию этих решений? С более высокими темпами перемен и более изменчивой средой, допускаемой этой архитектурой, роль архитектора должна измениться. В данной главе я буду отстаивать свой взгляд на роль архитектора и надеюсь взять штурмом эту никому пока не известную высоту.
Неверные сравнения
Ты все еще используешь это слово. А я думаю, что оно значит совсем не то, что ты о нем думаешь.Иниго Монтойя, герой книги У. Голдмана «Принцесса-невеста»
У архитекторов весьма важная задача. Они отвечают за координацию технического представления, помогающего нам дать клиентам именно ту систему, в которой они нуждаются. В одних организациях архитекторам приходится работать с одной командой, в таком случае роли архитектора и технического лидера зачастую сливаются в одну. В других организациях они могут определять представление о всей программе работы в целом, координировать взгляды команд, разбросанных по всему миру или, может быть, действующих под крышей всего одной организации. Но, на каком бы уровне они ни работали, точно определить их роль весьма трудно, и даже несмотря на то, что в компаниях стать архитектором считается карьерным ростом для разработчика, эта роль попадает под огонь критики намного чаще любой другой. Архитектор гораздо чаще других может напрямую повлиять на качество создаваемых систем, условия работы своих коллег и способность организации реагировать на изменения, и все же зачастую нам представляется, что в получении этой роли нет ничего хорошего. Почему же так происходит?
Наша отрасль еще сравнительно молода. Похоже, мы забыли об этом и все еще создаем программы, запускаемые на том, что примерно 70 лет называется компьютерами. Поэтому мы постоянно оглядываемся на другие профессии в попытке объяснить, чем занимаемся. Мы не врачи и не инженеры, а также не водопроводчики или электрики. Мы находимся в некой золотой середине, поэтому обществу трудно понять нас, а нам трудно понять, к какой категории мы относимся.
Мы заимствуем понятия из других профессий, называя себя инженерами или архитекторами. Но так ли это на самом деле? Архитекторы и инженеры отличаются строгостью и дисциплиной, о которых мы можем только мечтать, и важность их роли в обществе ни у кого не вызывает сомнений. Помнится, разговаривал я с приятелем за день до того, как он стал квалифицированным архитектором. «Завтра, — сказал он, — если я, сидя в баре, дам тебе какой-нибудь совет насчет того, как что-нибудь построить, и окажусь не прав, меня привлекут к ответственности. Мне могут предъявить иск, поскольку с точки зрения закона теперь я квалифицированный архитектор и должен нести ответственность за свои промахи». Важность данной работы для общества определяет то, что ею должны заниматься квалифицированные специалисты. В Великобритании, к примеру, прежде чем назваться архитектором, нужно проучиться семь лет. Но эта работа опирается на фундамент тысячелетних знаний. А у нас такого нет. В том числе и поэтому я считаю разные IT-сертификации совершенно бесполезной затеей, поскольку о том, как выглядит совершенство в нашем деле, мы знаем крайне мало.
Кому-то из нас хочется признания, поэтому мы заимствуем названия из других профессий, у которых уже есть столь вожделенное нами признание. Но это может быть вредным вдвойне. Во-первых, это означает, что мы знаем, чем занимаемся, хотя мы толком этого не понимаем. Не хочу сказать, что здания и мосты никогда не рушатся, но это происходит крайне редко по сравнению с тем количеством обрушений, которые испытывают наши программы, что делает сравнение с инженерами совершенно некорректным. Во-вторых, стоит только взглянуть пристальней, и аналогии очень быстро исчезнут. Посмотрим с другой стороны. Если бы строительство моста было похоже на программирование, то на полпути обнаружилось бы, что противоположный берег на 50 метров дальше и там на самом деле грязь, а не гранит, а вместо пешеходного мостика мы строим автомобильный мост. Наши программы не подчиняются физическим законам, с которыми приходится иметь дело архитекторам или инженерам, мы создаем то, что можно гибко изменять и адаптировать, а также развивать по ходу изменения пользовательских требований.
Наверное, наименее подходящим будет название «архитектор». Смысл профессии в том, что он вычерчивает подробные планы, в которых должны разбираться другие специалисты, и предполагает, что эти планы будут осуществлены. В нем сочетаются художник и инженер, курирующий создание того, что обычно составляет единую концепцию, авторитет архитектора подавляет все другие мнения, за исключением тех редких возражений инженеров-строителей, которые основываются на законах физики. В нашей отрасли такого рода архитектор может натворить ужасных дел. Кучи блок-схем, груды страниц документации, созданные без учета будущего в качестве информационной базы при строительстве совершенной системы. Такой архитектор абсолютно не представляет, насколько сложно все это будет реализовать, не знает, будет ли это все вообще работать, не говоря уже о малейшей возможности что-либо изменить по мере постижения смысла задачи.
Сравнивая себя с инженерами или архитекторами, мы скатываемся к оказанию самим себе медвежьей услуги. К сожалению, сейчас мы застряли на слове «архитектор». Поэтому самое лучшее в данной ситуации — переосмыслить его применительно к нашей среде.
Эволюционное видение для архитектора
Требования у нас изменяются куда быстрее, чем у тех, кто проектирует и строит здания, то же самое можно сказать об инструментах и методах, имеющихся в нашем распоряжении. Создаваемые нами продукты не имеют фиксированной отметки времени. Будучи запущенным в эксплуатацию, программный продукт продолжит развиваться по мере изменений способов его применения. Нужно признать, что после того как большинство создаваемых нами продуктов попадают к потребителям, мы вынуждены реагировать на все замечания последних и подстраивать продукты под них, поэтому нашу продукцию нельзя признать незыблемым творением искусства. Следовательно, архитекторам нужно избавиться от мысли о создании совершенного конечного продукта, а вместо этого сфокусироваться на содействии созданию программной структуры, в которой могут появляться подходящие системы, способные расти по мере более глубокого осмысления стоящих перед нами задач.
Хотя до сей поры мое повествование касалось в основном предостережений о неправомерности слишком близкого сравнения самих себя с представителями других профессий, есть все же одна понравившаяся мне аналогия по поводу роли IT-архитектора, и поэтому я считаю, что лучше дать краткое изложение того, во что бы мы хотели превратить эту роль. Первым, кто разделил со мной идею о том, что следует представлять себе создателя программной структуры скорее градостроителем, чем архитектором, был Эрик Дорненбург (Erik Doernenburg). Роль градостроителя должна быть знакома любому, кто когда-либо играл в SimCity. Она предполагает изучение информации из множества источников с последующей попыткой оптимизировать планировку города в соответствии с насущными нуждами жителей, но при этом не упуская из виду будущие потребности. Нам интересен сам метод, с помощью которого градостроитель влияет на развитие города. Он не говорит: «Постройте именно здесь именно это здание», вместо этого он разбивает город на зоны, точно так же, как в симуляторе SimCity можно сделать одну часть города промышленной зоной, а другую — зоной жилой застройки. А потом уже пускай другие решают, какие именно здания сооружать. Конечно, тут есть ряд ограничений: если нужно построить фабрику, она должна находиться в промышленной зоне. Вместо того чтобы тревожиться о происходящем в одной из зон, градостроитель намного больше времени станет уделять работе над тем, как люди и коммуникации перемещаются из одной зоны в другую.
Город не раз сравнивали с живым существом. Со временем город меняется. Он изменяется и развивается по мере того, как им различными способами пользуются обитатели или его формируют внешние силы. Градостроитель изо всех сил старается предвидеть эти изменения, но признает бесполезность попыток установить непосредственный контроль над всеми аспектами происходящего.
Тут должно просматриваться вполне очевидное сравнение с разработкой программных средств. Поскольку программами кто-то пользуется, мы должны реагировать на процесс их использования и вносить в них изменения. Всего, что может произойти, предвидеть невозможно, и поэтому вместо планирования готовности к любым неожиданностям нужно составлять такой план, который позволит вносить изменения, и избавляться от чрезмерного желания определить окончательный вид каждого компонента. Наш город (то есть программная система) должен быть достаточно подходящим и удобным местом для всех, кто им пользуется. Люди часто забывают, что система должна быть приспособлена не только под пользователей, она должна быть приспособлена и под тех, кто ее разрабатывает, и под тех, кто будет ее эксплуатировать, кому нужно работать в рамках этой системы и быть уверенными в том, что они могут внести в систему все необходимые изменения. Заимствуя высказывание у Фрэнка Бушмана, хочу сказать, что в обязанности архитектора входит обеспечение пригодности системы и для разработчиков.
Градостроителю точно так же, как и архитектору, нужно знать, когда его плану не следуют. Поскольку раздавать предписания на каждом шагу — не его прерогатива, градостроитель должен свести к минимуму внесение собственных корректур в основное направление развития, но, если кто-нибудь задумает построить очистные сооружения в жилой зоне, градостроитель должен быть в состоянии воспрепятствовать этому намерению.
Итак, нашим архитекторам, подобно градостроителям, нужно установить общее направление и вмешиваться в детали реализации в крайних случаях и по весьма конкретному поводу. Они должны гарантировать не только соответствие системы текущим целям, но и ее способность стать платформой для будущих изменений. Они должны сделать так, чтобы и пользователи, и разработчики были одинаково довольны системой. Похоже, предстоит решить нелегкую задачу. Так с чего же начать?
Зонирование
Итак, чтобы на минутку продолжить метафору с архитектором в качестве градостроителя, выясним, что же собой представляют зоны. Это границы сервисов или, возможно, собранных в крупные модули групп сервисов. В качестве архитекторов нам нужно больше заботиться не о том, что происходит внутри зоны, а о том, что происходит между зонами. То есть нужно тратить время на обдумывание вопросов общения сервисов друг с другом или того, как можно будет обеспечить подходящее отслеживание общей жизнеспособности системы. Многие организации приняли микросервисы, чтобы добиться максимальной автономности команд разработчиков, и эта тема будет раскрыта в главе 10. Если ваша организация относится к их числу, то для принятия правильного частного решения придется больше полагаться на команды.
Но между зонами, или блоками, на традиционной архитектурной блок-схеме нам нужно проявлять особую осторожность, поскольку недопонимание в этой области приводит к возникновению всевозможных проблем, устранение которых может оказаться весьма нелегкой задачей.
В пределах отдельно взятого сервиса можно будет вполне смириться с тем, что команда, ответственная за данную зону, выберет другую технологию стека или хранения данных. Но здесь можно пострадать от проблем совершенно иного рода. Разрешая командам выбирать подходящий им инструментарий для работы, будьте готовы к тому, что при необходимости поддержки десяти различных технологий стека станет труднее нанимать людей на работу или переводить их из одной команды в другую. Аналогично, если каждая команда выберет собственное хранилище данных, вам может не хватить опыта для запуска любого из этих хранилищ в масштабе системы. К примеру, компания Netflix при выборе технологий хранения данных придерживается в основном стандарта Cassandra. Может, для всех случаев этот вариант и не самый подходящий, но в компании Netflix считают, что ценность накопленных за счет использования Cassandra инструментария и опыта важнее необходимости поддержки и эксплуатации в масштабе компании нескольких других платформ, которые могли бы лучше подойти для решения конкретных задач. Netflix — это весьма яркий пример, в котором масштаб, вероятно, является первостепенным фактором, но главное — ухватить саму идею.
Однако между сервисами может получиться полный беспорядок. Если будет решено для одного сервиса выставить REST через HTTP, для другого — использовать буферы протокола, а для третьего — Java RMI, то их объединение станет просто кошмаром, поскольку пользующимся ими сервисам придется поддерживать сразу несколько стилей обмена данными. Поэтому я и стараюсь закрепить в качестве руководства к действию обязанность волноваться за все, что происходит между блоками, и снисходительно относиться ко всему, что делается внутри них.
Программирующий архитектор
Если нужно гарантировать, что создаваемые системы не вызывают дискомфорта у разработчиков, архитекторам нужно разбираться в том влиянии, которое имеют их решения. Как минимум это означает, что следует вникать в дела команды, а в идеале это должно означать, что нужно с этой командой еще и заниматься программированием. Тем из вас, кто занимался программированием с компаньоном, не составит труда в качестве архитектора влиться на непродолжительный срок в команду и заняться программированием в паре с кем-нибудь из ее членов. Если хотите быть в курсе хода работ, это должно стать обычной практикой. Не могу не подчеркнуть, насколько важно для архитектора вникать в работу команды! Это куда эффективнее, чем перезваниваться с этой командой или просто просматривать созданный ею код.
Насколько часто нужно погружаться в работу подведомственной вам команды (или команд), зависит главным образом от ее количественного состава. Но главное, чтобы это стало постоянной практикой. Если, к примеру, вы работаете с четырьмя командами, проведите по полдня с каждой из них в течение каждых четырех недель, чтобы гарантировать, что у вас сложились взаимопонимание и хорошие взаимоотношения с их членами.
Принципиальный подход
Правила нужны для того, чтобы им следовало дурачье и ими руководствовались мудрые люди.Приписывается Дугласу Бадеру (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)): «Руководство обеспечивает уверенность в достижении целей предприятия путем сбалансированной оценки потребностей заинтересованных сторон, существующих условий и возможных вариантов, установления направления развития через приоритизацию и принятие решений, постоянного мониторинга соответствия фактической продуктивности и степени выполнения требований установленным направлению и целям предприятия».
Применительно к ИТ руководство может касаться многих аспектов. Мы же хотим уделить особое внимание техническому руководству, что, по моему разумению, и является задачей архитектора. Если одной из задач, выполняемых архитектором, является обеспечение наличия технической концепции, то руководство имеет отношение к тому, чтобы обеспечить соответствие создаваемого этой концепции и участвовать в развитии концепции, если необходимо.
Архитекторы несут весьма многогранную ответственность. Они должны обеспечить наличие набора принципов, которые могут послужить руководством для разработки, а также соответствие этих принципов стратегии организации. Они должны также удостовериться в том, что эти принципы не требуют таких рабочих инструкций, которые будут в чем-то ущемлять разработчиков. Они должны двигаться в ногу с новыми технологиями и знать, когда нужно идти на разумные компромиссы. Это очень высокая ответственность. Кроме всего этого, им еще нужно вести за собой людей, то есть удостовериться в том, что коллеги, с которыми они работают, уяснили принятые решения и готовы к их выполнению. К тому же, как уже упоминалось, им нужно уделить время командам, чтобы осознать степень влияния их решений, и, возможно, даже вникнуть в создаваемый код.
Слишком большая ответственность? Конечно. Но я твердо придерживаюсь того мнения, что они должны справиться с ней самостоятельно. Чтобы частично разгрузить архитектора и уточнить концепцию, с ним вместе может работать толковая группа представителей руководства.
Обычно руководство является групповой деятельностью. Оно может осуществляться в ходе неформальной беседы с небольшой командой или — с целью широкого охвата — проводиться в форме более структурированных регулярных совещаний с формальными участниками группы. Я думаю, что именно здесь должны быть рассмотрены и при необходимости изменены те самые принципы, о которых говорилось ранее. Эту группу должен возглавлять технолог, и состоять она должна преимущественно из людей, выполняющих работу, в отношении которой осуществляется руководство. Группа должна также отвечать за отслеживание технических рисков и управление ими. Наиболее предпочтительной моделью для меня является та, в которой руководит группой архитектор, но при этом основная часть группы состоит из технологов от каждой исполнительной команды, как минимум руководящих командой. Архитектор должен убедиться в том, что группа работает, но за руководство отвечает группа в целом. Это приводит к разделению нагрузки и обеспечению более высокого уровня заинтересованности. Это также гарантирует, что информация свободно поступает из команд в группу, в результате чего принимаются толковые и осмысленные решения.
Временами группа может принимать решения, с которыми архитектор не согласен. Как в таком случае он должен поступать? Я, который бывал ранее в подобной роли, могу вас уверить в том, что это самая непростая ситуация, с которой приходится сталкиваться. Зачастую я склоняюсь к тому, что нужно соглашаться с решением группы. Я считаю, что сделал все возможное, чтобы убедить людей, но в конечном счете был недостаточно убедителен. Группа чаще всего намного мудрее индивидуума, и я не раз убеждался в том, что не прав! И представьте себе, насколько могут опуститься руки у группы, которой дали свободу для принятия решения, но в конечном счете его проигнорировали. Однако иногда я отвергал решение группы. Но почему и когда? Как выбрать линию поведения?
Вспомните, как детей учат кататься на велосипеде. Вы не можете ехать на нем за них. Вы наблюдаете за тем, как их шатает из стороны в сторону, но если каждый раз, когда вам будет казаться, что они могут упасть, вы станете поддерживать велосипед, они никогда не научатся ездить. И в любом случае они падают гораздо реже, чем вы ожидаете! Если же вы видите, что они вот-вот выедут на дорогу с интенсивным движением или въедут в ближайший пруд с утками, приходится вмешиваться. Так же, будучи архитектором, вы должны хорошо понимать, когда, образно говоря, ваша команда зарулит в пруд с утками. Вам также нужно знать о том, что, даже будучи уверенным в своей правоте и в необходимости остановить команду, вы можете совершить подкоп под собственную позицию, а также создать у группы ощущение, что у них нет права голоса. Иногда приходится смириться с тем решением, с которым вы не согласны. Понимание того, когда это нужно, а когда не нужно делать, дается нелегко, но временами оно просто жизненно необходимо.
Формирование команды
Пребывание в роли главного лица, ответственного за техническую концепцию вашей системы и обеспечение выработки данной концепции, не означает принятия технологических решений. Это придется делать тем людям, с которыми вы работаете. В основном роль технического лидера сводится к тому, чтобы помочь команде повысить мастерство, разобраться в концепции, а также убедиться, что ее члены тоже могут быть активными участниками уточнения и реализации концепции.
Содействие окружающим вас людям в их карьерном росте может принимать множество форм, большинство из которых выходит за рамки данного повествования. Но есть один аспект, где архитектура микросервисов особенно актуальна. При работе с крупными монолитными системами у людей меньше возможностей получить повышение и чем-нибудь овладеть. А при работе с микросервисами имеется множество автономных наборов исходного кода, имеющих собственные жизненные циклы. Помочь людям получить повышение, возложив на них ответственность за отдельные сервисы, — это отличный способ посодействовать им в достижении личных карьерных целей и в то же время облегчить нагрузку на тех, кто перегружен работой!
Я твердо верю в то, что замечательные программы создают выдающиеся люди. Если заботиться только о технологической стороне дела, то можно упустить из виду более половины общей картины происходящего.
Резюме
Подводя итог сказанному в данной главе, хочу перечислить все, что считаю основными аспектами, за которые отвечает архитектор развития.
• Концепция. Следует обеспечить наличие четко воспринимаемой технической концепции системы, что поможет последней отвечать требованиям потребителей и вашей организации.
• Чуткость. Нужно чутко воспринимать влияние ваших решений на потребителей и коллег.
• Сотрудничество. Нужно взаимодействовать с как можно большим числом коллег и сотрудников, чтобы стало легче определять, уточнять и реализовывать положения концепции.
• Приспособляемость. Следует обеспечить внесение в техническую концепцию изменений в соответствии с требованиями, которые выдвигают потребители или организация.
• Автономность. Нужно найти разумный баланс между стандартизацией и возможностью автономности в работе ваших команд.
• Руководство. Следует обеспечить соответствие реализуемой системы технической концепции.
Архитектор развития понимает, что справиться со своей нелегкой задачей он может, лишь постоянно поддерживая баланс. Внешние события так или иначе воздействуют на вас, и понимание того, где нужно им сопротивляться, а где — плыть по течению, зачастую приходит только с опытом. Но наихудшей реакцией на события, подталкивающие нас к изменениям, будет проявление еще большей жесткости или косности мышления.
Хотя многие советы, приведенные в данной главе, применимы к архитектору любых систем, микросервисы дают нам более широкие возможности для принятия решений. Поэтому способность успешно справляться со сбалансированностью компромиссов приобретает весьма большое значение.
В следующей главе мы воспользуемся вновь приобретенными знаниями о роли архитектора и приступим к обдумыванию путей поиска правильных границ для наших микросервисов.