Недавно Андрей Гордиенков, тренер учебного центра Luxoft Training, взял интервью у Сандера Хугендорна по поводу микросервисной архитектуры.

"САНДЕР ХУГЕНДОРН (НИДЕРЛАНДЫ) — ментор, тренер, архитектор программного обеспечения, программист, оратор и писатель. Сандер работает в сфере разработки программного обеспечения более 30 лет, свою первую коммерческую программу написал в 18 лет на Паскале.

Сотрудничает с крупными консультационными IT-компаниями в течение 20 летВ настоящее время работает в Capgemini. Многочисленные клиенты из разных стран высоко ценят его как «активатора» инноваций в разработке программного обеспечения.

Сандер был тренером для организаций, команд, проектов и физических лиц. Представил более 300 учебных курсов в течение последних 15 лет по различным темам, таким как Agile, Scrum, Канбан, оценка программного обеспечения, архитектура программного обеспечения, микросервисы, шаблоны проектирования, моделирование и UML, написание кода и тестирование.

Оригинал интервью на английском языке опубликован в блоге Сандера.

Стоит ли применять микросервисы?

Андрей Гордиенков: В вашей статье «Микросервисы. Хорошие, плохие, злые» вы описали различные аспекты разработки. У читателей могло создаться впечатление, что использование микросервисной архитектуры приведет к следующему:

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

Итак, вопрос: стоит ли применять микросервисы и почему они – будущее архитектуры?

Сандер Хугендорн: Применение микросервисной архитектуры охватывает гораздо больше, чем «просто» разработку программного обеспечения. Оно требует междисциплинарного подхода, при котором множество различных ролей работают в тесном сотрудничестве для разработки, построения, тестирования и развертывания системы, которую вы строите. В этом участвует не только архитектор, но и аналитики, дизайнеры, чья задача разбить домен на ограниченные контексты и спроектировать API, которые будут предлагать ваши компоненты. Это также включает в себя работу по развертыванию системы в производственной среде. Это не разовое мероприятие, а непрерывный поток новых и обновленных приложений и компонентов. Так что для того чтобы прийти к микросервисной архитектуре, требуется много различных навыков, знаний и опыта во многих темах, в том числе в моделировании, архитектуре программного обеспечения, автоматизированном тестировании, проектировании и развертывании API, предметно-ориентированном проектировании и непрерывной поставке. И последнее, но не менее важное: так как каждый компонент может быть построен с использованием различных языков и технологий, то в конечном итоге у вас может получиться «лоскутное одеяло» из технологий. Тем не менее из-за соображений, упомянутых вами выше, я бы этого не рекомендовал. Использование множества различных языков и технологий не является обязательным требованием.
Целесообразность движения к микросервисам во многом зависит от того, откуда вы сами к ним идете. Один из моих клиентов пытается избавиться от своего мэйнфрейма. Они медленно перестраивают всю функциональность с мэйнфрейма на новую микросервисную архитектуру. Для них возможность поставлять небольшие части системы одну за другой очень ценна и оправдывает непрерывные исследования и расходы, связанные с тем, как же все-таки это сделать. Для другого клиента наиболее ценной частью микросервисов является способность разбить их сложно поддерживаемую систему, состоящую из 7 миллионов строк кода, на ряд гораздо лучше изолированных и удобных в сопровождении ограниченных контекстов в рамках единой системы. Они не будут двигаться в направлении отдельных развертываемых компонентов.

Не лучше ли сначала построить монолитную систему?

А.Г.: В недавнем сообщении в своем блоге Мартин Фаулер (Martin Fowler) заявил, что лучше вначале построить монолит, и когда вы начнете понимать границы вашего домена, то сможете разделить ваше приложение на микросервисы лучшим образом. Что вы думаете об этом совете? Применяли ли вы его в своей практике?
С.Х.: Как я уже говорил в ответе на предыдущий вопрос, существует много различных ситуаций, в которых микросервисы применимы либо не применимы. Я не думаю, что есть золотое правило, которое поможет решить, стоит ли стремиться к микросервисам. Клиент, о котором я упоминал – тот, который хочет избавиться от своего мэйнфрейма – не будет вначале строить монолит: они пытались, но система получилась настолько большой и трудно поддерживаемой, что проект провалился. Также потому, что они не смогли распознать ограниченные контексты в этой попытке.
В микросервисах хорошо то, что они заставляют вас думать в категориях малых компонентов и ограниченных контекстов. Это, на мой взгляд, одно из самых больших преимуществ применения этого архитектурного стиля, независимо от того, развертываете ли вы их все по отдельности или используете для разбиения системы на модули. Я предполагаю, что Мартин Фаулер не имел в виду буквальное построение монолита в начале, скорее он пытался подчеркнуть, что важно иметь возможность разбить ваш домен на модули.

Если разбить приложение на небольшие части, будет ли это – микросервисная архитектура?

А.Г.: Если я разобью свое приложение на небольшие части и при этом оно будет функционировать – не важно как, но будет, смогу ли я назвать это микросервисной архитектурой? Или это просто «лоскутное одеяло»? Что делает микросервисную архитектуру настоящей архитектурой?

С.Х.: Лично меня на самом деле не волнует, является ли нечто микросервисной архитектурой или нет. Так же как меня на самом деле не волнует, «гибкий» проект или нет. Вопрос в том, можете ли вы извлечь выгоду из предложенных идей и концепций. Если в Agile использование непрерывной приоритизации, коротких итераций и мультидисциплинарных команд для вас работает, то неужели вам действительно важно, называются ли они Scrum, XP, Smart или Crystal Clear?
На мой взгляд, стоит делить большие системы на небольшие независимые части и определять четкие границы между ними, потому что это помогает создавать более высококачественный, более удобный в сопровождении проверяемый код. И это позволяет выбрать различные технологии, такие как механизмы устойчивости и типы баз данных. В любом случае развертываемые компоненты облегчают непрерывную поставку и обеспечивают высокую масштабируемость, но не для всех. Поэтому, пожалуйста, извлекайте выгоду из идей и концепций, не взирая на то, можете ли вы называть это микросервисной архитектурой или нет.

Насколько ценно использование правильных инструментов при разработке микросервисов?

А.Г.: Не могли бы вы поделиться своим видением того, насколько ценно использование правильных инструментов при разработке микросервисов? Могут ли они помочь и направить к правильному управлению и разработке микросервисной архитектуры? Чтобы избежать пресловутый шаблон, когда, вероятно, никто не имеет ни малейшего представления, как компоненты связаны между собой и как этот большой шар грязи действительно работает, понимаете? Я знаю, что «серебряной пули нет», но инструменты способны помочь разработчикам так же, как хороший API помогает и направляет их в ходе разработки. Я имею в виду Swagger, APIary, хранилище имен, брокеры MQ – думаю, вы поняли идею. Вы можете написать свой код в блокноте, но это контрпродуктивно. Итак, еще раз, могут ли инструменты направить разработчиков и помочь им избежать некоторых глупых ошибок?

С.Х.: Прежде всего нет такого инструмента, который будет делать работу за вас. При реализации микросервисной архитектуры приходится много думать и использовать большое количество различных методов и технологий. Так как микросервисы довольно новые (хотя некоторые утверждают, что они существуют гораздо дольше), инструменты, которые вам помогут, появятся, когда производители увидят возможность заработать. Мы уже видим новые инструменты для организации непрерывной доставки и настройки конвейеров развертывания, такие как Go-CD; для открытия API и документации, такие как Swagger. Я думаю, что производители начнут создавать все больше и больше инструментов для полной автоматизации процессов вокруг реализации микросервисной архитектуры, в основном на основе облака. Интегрированные среды разработки (IDE) будут предлагать лучшую поддержку разработки микросервисов. Но в настоящее время большинство организаций используют довольно традиционные инструменты разработки, которые мы уже знаем из «гибких» проектов.

Почему стоит посетить тренинг по микросервисной архитектуре?

А.Г.: 25 сентября в Москве Вы проводите тренинг «Проектирование, разработка, тестирование и развертывание микросервисной архитектуры» . Не могли бы Вы объяснить, почему стоит его посетить, чем он может быть полезен компаниям, которые даже не собираются переходить на микросервисы? Ведь можно просто купить книгу Сэма Ньюмана «Building Microservices» и следовать инструкциям. Будет ли этого достаточно?

С.Х.: Мне очень нравится книга Сэма, он дает очень хороший обзор того, с чем будет сталкиваться компания, когда приступит к реализации микросервисной архитектуры. Так что книга – хорошее начало. Но всегда полезно посетить учебный курс, как мой, чтобы увидеть реальные примеры проблем, с которыми вы столкнетесь на пути к микросервисам. Во время учебного курса я представлю основы микросервисов, их преимущества и недостатки. Мы будем обсуждать различные сценарии того, когда стоит задуматься об использовании микросервисов, а когда нет. Я сделаю акцент на проектировании компонентов и услуг, создании приложений, которые используют микросервисы в корпоративных средах, в том числе во время автоматизации бизнес-процессов, «умных» сценариях использования и предметно-ориентированном проектировании с ограниченными контекстами, а также на том, как их проектировать и строить. Подробно расскажу о проектировании API и о том, как тестировать микросервисы, в том числе с помощью автоматизированного тестирования. Мы обсудим настройку конвейеров развертывания и развертывание микросервисов. Все это будет проиллюстрировано примерами из реальной жизни (и смешными анекдотами). Так что я надеюсь, что из моего учебного курса вы многое узнаете, даже если вы (пока еще) не создаете микросервисы.