[Перевод] Когда использовать микросервисы: отвечают Сэм Ньюмен и Мартин Фаулер
Что бывает, когда два легендарных теоретика микросервисов, Мартин Фаулер и Сэм Ньюмен, встречаются, чтобы побеседовать о стратегии разработки под такую парадигму? За минимальное время можно составить впечатление о самых свежих представлениях на тему микросервисов. Ниже мы обсудим взгляды на разработку приложений, которые изложил Сэм Ньюмен, когда Мартин Фаулер задал, казалось бы, простой вопрос: «Когда следует использовать микросервисы?»
Убедитесь, что у вас есть «действительно веская причина» для внедрения микросервисов
Когда для разработки приложений требуется высокий уровень масштабирования и беспрецедентная гибкость разработки, архитектурный стиль микросервисов может устранить зависимости, присущие монолитным приложениям — те самые, из-за которых страдают масштабируемость и гибкость. Однако, как отметил Мартин Фаулер в недавней беседе с Сэмом Ньюменом, идеологи микросервисов тратят много времени на разговоры о том, когда не следует использовать микросервисы, но не всегда говорят, когда такая стратегия разработки приложений может быть желательна.
Ньюмен в ответ отметил, что разработчикам следует рассматривать возможность внедрения микросервисов только при наличии «действительно веских причин» для этого. Он говорит, что разработчики склонны слишком зацикливаться на новейшем техническом инструменте (таком как микросервисы) как на идеале, который должен быть реализован во что бы то ни стало. Напротив, Ньюмен рекомендует разработчикам сосредоточиться на результате, достижимом при помощи технического инструмента. В связи с этим Ньюмен говорит, что разработчики должны убедиться в том, что использование конкретной технологии является практически оправданным, прежде чем тратить время и средства на внедрение технологии.
Как говорит Ньюмен, «Архитектура микросервисов выбирается сознательно, чтобы реализовать систему в этом стиле ради достижения искомого результата. Есть какая-то выгода, которую, на ваш взгляд, даст вам микросервисная архитектура». Поэтому мой критерий отбора таков: «Что именно вам даст архитектура микросервисов?».
Самые убедительные «плюсы» микросервисов
Среди наиболее бесспорных «плюсов», которые может дать архитектура микросервисов — такие:
1. Дополнительные возможности для масштабирования приложений,
2. Возможность независимого развертывания,
3. Помощь в сокращении «радиуса поражения» при отказах сервисов,
4. Позволяет разработчикам «купить» новую серию опций и вариантов, которые могут сделать разработчики приложений.
По словам Ньюмена, микросервисы позволяют «завлечь» пользователя рядом опций, которые привлекательны для каждого. Однако он напоминает нам, что мы буквально «покупаем» эти опции, т.е. в разработке приложений с микросервисами есть элемент затрат, элемент работы и элемент времени. Поэтому мы должны быть уверены, что результаты, которые мы надеемся получить от архитектуры микросервисов, явно будут стоить этих затрат.
Начните с небольших изменений и сохраните однопроцессный монолит в качестве опции «по умолчанию»
Ньюмен делает еще один вывод, который разработчики часто упускают из виду. Он говорит, что разработчики трактуют архитектуру микросервисов как «распределённую» систему, и поэтому считают, что она лучше, чем монолитная конструкция. Однако Ньюмен напоминает нам, что монолитные архитектуры на самом деле тоже являются распределёнными системами: «Если вы думаете об обычном монолитном приложении с одним процессом, или если вы считываете информацию из базы данных на отдельном компьютере, то это распределённая система. Если вы заливаете данные из этого процесса в браузер — это распределенная система. Это очень просто. Поэтому по умолчанию я рассматриваю очень простую топологию развертывания — монолит с одним процессом — и если я думаю, что сервисная архитектура может быть целесообразна, я просто попробую реализовать один из сервисов как микросервис».
Ньюмен говорит, что по умолчанию он использует однопроцессное монолитное приложение с простой топологией развёртывания. Он говорит, что такая архитектура позволяет избежать многих сложностей при развёртывании и других проблем на начальном этапе. В то же время он говорит, что если вам интересно попробовать микросервисы, то не стоит рассматривать эту затею как запредельно сложное мероприятие — и не стоит пытаться сделать всё и сразу. Он предостерегает: не превращайтесь в организацию, которая решит внедрить микросервисы и потратит шесть месяцев на перестройку всей своей системы с нуля. Напротив, Ньюмен рекомендует организациям просто попробовать переоборудовать один модуль из монолита в микросервис и посмотреть, как это работает.
Ньюмен добавляет: «Давайте сделаем мою систему немного более распределенной, лишь чуть-чуть, и посмотрим, что это даст. Смогу ли я с этим справиться? Могу ли я немного сгладить тот «ужас», который возникает в распределённых системах, и получу ли я от этого какие-то преимущества?».
Топ-3 причины, по которым следует использовать микросервисы
Учитывая все это, Ньюмен выделяет следующие три основные причины, по которым организациям следует использовать архитектурный стиль микросервисов:
(1) Необходимость независимого развертывания новых функциональных возможностей со сведением простоев к нулю
Микросервисы чрезвычайно полезны, когда требуется внести изменения в функциональность — и развернуть эту функциональность таким образом, чтобы остальная часть системы не менялась. В микросервисной архитектуре это позволяет развертывать новую функциональность без простоев. Необходимость в развертывании без простоев, безусловно, применима к бизнесу, основанному на принципах SaaS, где организации необходимо постоянно поддерживать работоспособность своих программных продуктов.
(2) Необходимость изолировать конкретные данные и их обработку путём разделения данных
Многие организации, например, в сфере здравоохранения и финансовой индустрии, нуждаются в защите информации на уровне PHI и PII. Они также должны придерживаться определенных стандартов безопасности данных и соответствия (таких как GDPR и SOC2). Реализация «права на забвение» — еще одна распространённая проблема. В микросервисной архитектуре вы изолируете данные и обработку, применимую к этим данным, что позволяет достичь разделения данных. Так удаётся легко определить, какие службы затрагивают информацию PII и требуют большего контроля, управления и аудита.
(3) Необходимость обеспечения высокой степени автономности команды
Мартин Фаулер дополнил эту точку зрения следующим замечанием: «С организационной точки зрения, когда я обсуждаю микросервисы с людьми, то, конечно, именно на этой области я больше всего концентрируюсь. С увеличением размера команды координировать людей становится все труднее […] Поэтому вам нужно устанавливать барьеры, а микросервисы как бы вынуждают вас к неудобному способу работы — что, собственно, и нужно в любом случае, когда команда больше». Чтобы узнать больше по этой теме, ознакомьтесь с этим постом DreamFactory, где мы описываем путь Amazon, Netflix, Uber и Etsy к микросервисам.
Снижение стоимости, временных затрат и сложности внедрения микросервисов
Один из самых важных моментов, который Сэм Ньюмен доносит до нас в этой дискуссии, — это необходимость проанализировать практичность реализации, прежде чем полностью спускаться в кроличью нору и разрабатывать полноценную систему на базе микросервисов. Другими словами, разрушение монолита, разработка и интеграция микросервисов — это дорогостоящее и трудоемкое мероприятие, поэтому важно, чтобы преимущества микросервисов стоили затрат.
Этот фактор «затраты-выгоды» бывает жизненно важным, и именно он не позволяет многим малым и средним организациям воспользоваться многочисленными преимуществами архитектуры приложений на основе микросервисов. Зачастую огромные преимущества разработки приложений в духе микросервисов слишком дорого обходятся небольшим компаниям. К счастью, благодаря современным инструментам управления API, таким как DreamFactory, разработка микросервисов в малых и средних предприятиях стала проще и доступнее, чем когда-либо.
