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

Технологическая разнородность

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

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

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

Рис. 1.1. Микросервисы позволяют упростить использование разнообразных технологий

Разумеется, использование нескольких технологий не обходится без определенных издержек. Некоторые организации предпочитают накладывать на выбор языков ограничения. В Netflix и Twitter, к примеру, в качестве платформы используется преимущественно Java Virtual Machine (JVM), поскольку они очень ценят надежность и производительность этой системы. В этих организациях также разрабатываются библиотеки и инструментальные средства для JVM, существенно упрощающие работу в масштабе платформы, но сильно усложняющие ее для сервисов и клиентов, не работающих на Java-платформе. Но для всех заданий ни в Twitter, ни в Netflix не используется лишь один набор технологий. Еще одним аргументом в противовес опасениям по поводу смешения различных технологий является размер. Если я действительно могу переписать свой микросервис за две недели, то вы также можете снизить риск применения новой технологии.

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

Устойчивость

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

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

Устойчивость в ее лучших проявлениях и методы борьбы с отказами будут рассматриваться в главе 11.

Масштабирование

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

Рис. 1.2. Можно расширять только те микросервисы, которые в этом нуждаются

Именно по этой причине микросервисами воспользовалась компания Gilt, занимающаяся продажей через Интернет модной одежды. Начав в 2007 году с использования монолитного Rails-приложения, к 2009 году компания столкнулась с тем, что используемая система не в состоянии справиться с возлагаемой на нее нагрузкой. Разделив основные части своей системы, Gilt смогла намного успешнее справляться со всплесками трафика, и теперь компания использует 450 микросервисов, каждый из которых запущен на нескольких отдельных машинах.

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

Простота развертывания

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

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

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

Решение организационных вопросов

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

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

Компонуемость

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

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

Оптимизация с целью последующей замены

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

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

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

А как насчет сервис-ориентированной архитектуры?

Сервис-ориентированная архитектура (Service-oriented Architecture (SOA)) представляет собой подход в проектировании, при котором несколько сервисов работают совместно для предоставления некоего конечного набора возможностей. Под сервисом здесь обычно понимается полностью отдельный процесс операционной системы. Связь между такими сервисами осуществляется через сетевые вызовы, а не через вызовы методов в границах процесса.

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

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

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

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

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

Другие технологии декомпозиции

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

Совместно используемые библиотеки

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

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

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

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

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

Модули

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

В качестве одной из технологий подхода к модульной декомпозиции стоит упомянуть спецификацию динамической плагинной (модульной) шины для создания Java-приложений — Open Source Gateway Initiative (OSGI). В самом языке Java понятие «модули» отсутствует, и чтобы увидеть его добавленным к языку, придется, видимо, ждать выхода Java 9. Спецификация OSGI, появившаяся в качестве среды, позволяющей устанавливать дополнительные модули (плагины) в Eclipse Java IDE, используется в данное время в качестве способа подгонки модульной концепции в Java посредством библиотеки.

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

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

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

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

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

Никаких универсальных решений

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

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

Резюме

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

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

2. Архитектор развития

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

Неверные сравнения

Ты все еще используешь это слово. А я думаю, что оно значит совсем не то, что ты о нем думаешь.

Иниго Монтойя, герой книги У. Голдмана «Принцесса-невеста»

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

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

Мы заимствуем понятия из других профессий, называя себя инженерами или архитекторами. Но так ли это на самом деле? Архитекторы и инженеры отличаются строгостью и дисциплиной, о которых мы можем только мечтать, и важность их роли в обществе ни у кого не вызывает сомнений. Помнится, разговаривал я с прия­телем за день до того, как он стал квалифицированным архитектором. «Завтра, — сказал он, — если я, сидя в баре, дам тебе какой-нибудь совет насчет того, как что-нибудь построить, и окажусь не прав, меня привлекут к ответственности. Мне могут предъявить иск, поскольку с точки зрения закона теперь я квалифицированный архитектор и должен нести ответственность за свои промахи». Важность данной работы для общества определяет то, что ею должны заниматься квалифицированные специалисты. В Великобритании, к примеру, прежде чем назваться архитектором, нужно проучиться семь лет. Но эта работа опирается на фундамент тысячелетних знаний. А у нас такого нет. В том числе и поэтому я считаю разные IT-сертификации совершенно бесполезной затеей, поскольку о том, как выглядит совершенство в нашем деле, мы знаем крайне мало.

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

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

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

Эволюционное видение для архитектора

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

Хотя до сей поры мое повествование касалось в основном предостережений о неправомерности слишком близкого сравнения самих себя с представителями других профессий, есть все же одна понравившаяся мне аналогия по поводу роли IT-архитектора, и поэтому я считаю, что лучше дать краткое изложение того, во что бы мы хотели превратить эту роль. Первым, кто разделил со мной идею о том, что следует представлять себе создателя программной структуры скорее градостроителем, чем архитектором, был Эрик Дорненбург (Erik Doernenburg). Роль градостроителя должна быть знакома любому, кто когда-либо играл в SimCity. Она предполагает изучение информации из множества источников с последующей попыткой оптимизировать планировку города в соответствии с насущными нуждами жителей, но при этом не упуская из виду будущие потребности. Нам интересен сам метод, с помощью которого градостроитель влияет на развитие города. Он не говорит: «Постройте именно здесь именно это здание», вместо этого он разбивает город на зоны, точно так же, как в симуляторе SimCity можно сделать одну часть города промышленной зоной, а другую — зоной жилой застройки. А потом уже пускай другие решают, какие именно здания сооружать. Конечно, тут есть ряд ограничений: если нужно построить фабрику, она должна находиться в промышленной зоне. Вместо того чтобы тревожиться о происходящем в одной из зон, градостроитель намного больше времени станет уделять работе над тем, как люди и коммуникации перемещаются из одной зоны в другую.

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

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

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

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

Зонирование

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

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

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

Однако между сервисами может получиться полный беспорядок. Если будет решено для одного сервиса выставить REST через HTTP, для другого — использовать буферы протокола, а для третьего — Java RMI, то их объединение станет просто кошмаром, поскольку пользующимся ими сервисам придется поддерживать сразу несколько стилей обмена данными. Поэтому я и стараюсь закрепить в качестве руководства к действию обязанность волноваться за все, что происходит между блоками, и снисходительно относиться ко всему, что делается внутри них.