В языке Erlang используется другой подход, при котором модули встроены в рабочий цикл выполнения программы. То есть в Erlang применен весьма зрелый подход к модульной декомпозиции. Модули Erlang можно остановить, перезапустить и обновить, не создавая при этом никаких проблем. В Erlang даже поддерживается запуск более одной версии модуля в любой момент времени, что позволяет обновить модуль более изящным способом.
Возможности модулей в Erlang действительно впечатляют, но, даже если повезет воспользоваться платформой с такими возможностями, все равно придется столкнуться с недостатками, присущими обычным совместно используемым библиотекам. По-прежнему будут действовать строгие ограничения на использование новых технологий, ограничения на независимые расширения, модули могут скатываться в сторону таких технологий объединения, при которых возникнет чрезмерная взаимосвязанность, к тому же у них отсутствуют стыки, позволяющие принимать такие меры, которые бы не нарушали безопасность архитектуры.
Следует поделиться еще одним, последним наблюдением. Технически, может быть, и можно создать четко определенные независимые модули внутри отдельно взятого монолитного процесса. И все же свидетельств этому крайне мало. Сами модули вскоре становятся тесно связанными со всем остальным кодом, из-за чего исчезает одно из их ключевых преимуществ. Наличие у процесса разделительных границ требует в этом отношении соблюдения строгой гигиены (или как минимум чтобы было затруднительно выполнять неверные действия!). Разумеется, я не хочу сказать, что это должно стать основным поводом для разделения процессов, но интересно заметить, что обещание разделения модулей в границах одного процесса в реальном мире выполняется крайне редко.
И пусть модульная декомпозиция в границах процесса может быть именно тем, чего вы хотели добиться вдобавок к декомпозиции вашей системы на сервисы, сама по себе она не поможет решить все проблемы. Если вы пользуетесь лишь языком Erlang, то качество реализации его модулей может устроить вас на весьма продолжительный срок, но я подозреваю, что многие из вас находятся в совершенно другой ситуации. Для всех остальных мы станем рассматривать модули, предлагающие такие же преимущества, как и общие библиотеки.
Перед тем как завершить главу, я должен заявить, что микросервисы не похожи на бесплатный обед или универсальное решение, но их нельзя назвать и негодным вариантом вроде золотого молотка. У них существуют те же сложности, что и у всех распределенных систем, и даже если как следует научиться управлять распределенными системами (о чем, собственно, и будет идти речь в данной книге), легкой жизни я все равно не обещаю. Если вы смотрите на все это с позиции монолитной системы, то, чтобы раскрыть все те преимущества, о которых уже говорилось, придется совершенствоваться в вопросах развертывания, тестирования и мониторинга. Также нужно будет изменить взгляд на расширение своих систем и убедиться в том, что они остаются устойчивыми. И не стоит удивляться, если у вас заболит голова от таких вещей, как распределенные транзакции или теорема CAP!
У каждой компании, организации и системы есть свои особенности. В решении вопроса о том, подойдут вам микросервисы или нет и в какой степени нужно проявлять энтузиазм при их внедрении, сыграют роль многие факторы. В каждой главе этой книги я буду стараться дать вам рекомендации, выделяя потенциальные проблемы, что поможет вам проложить верный путь.
Теперь, я надеюсь, вы знаете, что такое микросервис, чем он отличается от других композиционных технологий и что собой представляют некоторые его ключевые преимущества. В каждой из следующих глав мы будем рассматривать подробности того, как достичь этих преимуществ и при этом избежать ряда наиболее распространенных подвохов.
Нам предстоит рассмотреть множество тем, но с чего-то ведь нужно начать. Одной из основных сложностей, с которой приходится сталкиваться при переходе к микросервисам, является изменение роли тех, кто зачастую направляет развитие наших систем, — я имею в виду архитекторов. В следующей главе будут рассмотрены некоторые иные подходы к этой роли, которые могут обеспечить наибольшую отдачу от применения новой архитектуры.
2. Архитектор развития
Мы уже увидели, что микросервисы дают широкое поле для выбора и, соответственно, вынуждают принимать множество решений. Например, сколько различных технологий нужно применять, можно ли разным командам использовать различные идиомы программирования и следует ли разбивать или объединять сервисы. Как прийти к принятию этих решений? С более высокими темпами перемен и более изменчивой средой, допускаемой этой архитектурой, роль архитектора должна измениться. В данной главе я буду отстаивать свой взгляд на роль архитектора и надеюсь взять штурмом эту никому пока не известную высоту.
Ты все еще используешь это слово. А я думаю, что оно значит совсем не то, что ты о нем думаешь.
У архитекторов весьма важная задача. Они отвечают за координацию технического представления, помогающего нам дать клиентам именно ту систему, в которой они нуждаются. В одних организациях архитекторам приходится работать с одной командой, в таком случае роли архитектора и технического лидера зачастую сливаются в одну. В других организациях они могут определять представление о всей программе работы в целом, координировать взгляды команд, разбросанных по всему миру или, может быть, действующих под крышей всего одной организации. Но, на каком бы уровне они ни работали, точно определить их роль весьма трудно, и даже несмотря на то, что в компаниях стать архитектором считается карьерным ростом для разработчика, эта роль попадает под огонь критики намного чаще любой другой. Архитектор гораздо чаще других может напрямую повлиять на качество создаваемых систем, условия работы своих коллег и способность организации реагировать на изменения, и все же зачастую нам представляется, что в получении этой роли нет ничего хорошего. Почему же так происходит?
Наша отрасль еще сравнительно молода. Похоже, мы забыли об этом и все еще создаем программы, запускаемые на том, что примерно 70 лет называется компьютерами. Поэтому мы постоянно оглядываемся на другие профессии в попытке объяснить, чем занимаемся. Мы не врачи и не инженеры, а также не водопроводчики или электрики. Мы находимся в некой золотой середине, поэтому обществу трудно понять нас, а нам трудно понять, к какой категории мы относимся.
Мы заимствуем понятия из других профессий, называя себя инженерами или архитекторами. Но так ли это на самом деле? Архитекторы и инженеры отличаются строгостью и дисциплиной, о которых мы можем только мечтать, и важность их роли в обществе ни у кого не вызывает сомнений. Помнится, разговаривал я с приятелем за день до того, как он стал квалифицированным архитектором. «Завтра, — сказал он, — если я, сидя в баре, дам тебе какой-нибудь совет насчет того, как что-нибудь построить, и окажусь не прав, меня привлекут к ответственности. Мне могут предъявить иск, поскольку с точки зрения закона теперь я квалифицированный архитектор и должен нести ответственность за свои промахи». Важность данной работы для общества определяет то, что ею должны заниматься квалифицированные специалисты. В Великобритании, к примеру, прежде чем назваться архитектором, нужно проучиться семь лет. Но эта работа опирается на фундамент тысячелетних знаний. А у нас такого нет. В том числе и поэтому я считаю разные IT-сертификации совершенно бесполезной затеей, поскольку о том, как выглядит совершенство в нашем деле, мы знаем крайне мало.
Кому-то из нас хочется признания, поэтому мы заимствуем названия из других профессий, у которых уже есть столь вожделенное нами признание. Но это может быть вредным вдвойне. Во-первых, это означает, что мы знаем, чем занимаемся, хотя мы толком этого не понимаем. Не хочу сказать, что здания и мосты никогда не рушатся, но это происходит крайне редко по сравнению с тем количеством обрушений, которые испытывают наши программы, что делает сравнение с инженерами совершенно некорректным. Во-вторых, стоит только взглянуть пристальней, и аналогии очень быстро исчезнут. Посмотрим с другой стороны. Если бы строительство моста было похоже на программирование, то на полпути обнаружилось бы, что противоположный берег на 50 метров дальше и там на самом деле грязь, а не гранит, а вместо пешеходного мостика мы строим автомобильный мост. Наши программы не подчиняются физическим законам, с которыми приходится иметь дело архитекторам или инженерам, мы создаем то, что можно гибко изменять и адаптировать, а также развивать по ходу изменения пользовательских требований.
Наверное, наименее подходящим будет название «архитектор». Смысл профессии в том, что он вычерчивает подробные планы, в которых должны разбираться другие специалисты, и предполагает, что эти планы будут осуществлены. В нем сочетаются художник и инженер, курирующий создание того, что обычно составляет единую концепцию, авторитет архитектора подавляет все другие мнения, за исключением тех редких возражений инженеров-строителей, которые основываются на законах физики. В нашей отрасли такого рода архитектор может натворить ужасных дел. Кучи блок-схем, груды страниц документации, созданные без учета будущего в качестве информационной базы при строительстве совершенной системы. Такой архитектор абсолютно не представляет, насколько сложно все это будет реализовать, не знает, будет ли это все вообще работать, не говоря уже о малейшей возможности что-либо изменить по мере постижения смысла задачи.
Сравнивая себя с инженерами или архитекторами, мы скатываемся к оказанию самим себе медвежьей услуги. К сожалению, сейчас мы застряли на слове «архитектор». Поэтому самое лучшее в данной ситуации — переосмыслить его применительно к нашей среде.