image

Что бывает, когда два легендарных теоретика микросервисов, Мартин Фаулер и Сэм Ньюмен, встречаются, чтобы побеседовать о стратегии разработки под такую парадигму? За минимальное время можно составить впечатление о самых свежих представлениях на тему микросервисов. Ниже мы обсудим взгляды на разработку приложений, которые изложил Сэм Ньюмен, когда Мартин Фаулер задал, казалось бы, простой вопрос: «Когда следует использовать микросервисы?»

Убедитесь, что у вас есть «действительно веская причина» для внедрения микросервисов


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

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

Как говорит Ньюмен, «Архитектура микросервисов выбирается сознательно, чтобы реализовать систему в этом стиле ради достижения искомого результата. Есть какая-то выгода, которую, на ваш взгляд, даст вам микросервисная архитектура». Поэтому мой критерий отбора таков: «Что именно вам даст архитектура микросервисов?».

Самые убедительные «плюсы» микросервисов


Среди наиболее бесспорных «плюсов», которые может дать архитектура микросервисов — такие:
  1. Дополнительные возможности для масштабирования приложений,
  2. Возможность независимого развертывания,
  3. Помощь в сокращении «радиуса поражения» при отказах сервисов,
  4. Позволяет разработчикам «купить» новую серию опций и вариантов, которые могут сделать разработчики приложений.

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

Начните с небольших изменений и сохраните однопроцессный монолит в качестве опции «по умолчанию»


Ньюмен делает еще один вывод, который разработчики часто упускают из виду. Он говорит, что разработчики трактуют архитектуру микросервисов как «распределённую» систему, и поэтому считают, что она лучше, чем монолитная конструкция. Однако Ньюмен напоминает нам, что монолитные архитектуры на самом деле тоже являются распределёнными системами: «Если вы думаете об обычном монолитном приложении с одним процессом, или если вы считываете информацию из базы данных на отдельном компьютере, то это распределённая система. Если вы заливаете данные из этого процесса в браузер — это распределенная система. Это очень просто. Поэтому по умолчанию я рассматриваю очень простую топологию развертывания — монолит с одним процессом — и если я думаю, что сервисная архитектура может быть целесообразна, я просто попробую реализовать один из сервисов как микросервис».

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

Ньюмен добавляет: «Давайте сделаем мою систему немного более распределенной, лишь чуть-чуть, и посмотрим, что это даст. Смогу ли я с этим справиться? Могу ли я немного сгладить тот „ужас“, который возникает в распределённых системах, и получу ли я от этого какие-то преимущества?».

Топ-3 причины, по которым следует использовать микросервисы


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

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

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

(2) Необходимость изолировать конкретные данные и их обработку путём разделения данных.

Многие организации, например, в сфере здравоохранения и финансовой индустрии, нуждаются в защите информации на уровне PHI и PII. Они также должны придерживаться определенных стандартов безопасности данных и соответствия (таких как GDPR и SOC2). Реализация «права на забвение» — еще одна распространённая проблема. В микросервисной архитектуре вы изолируете данные и обработку, применимую к этим данным, что позволяет достичь разделения данных. Так удаётся легко определить, какие службы затрагивают информацию PII и требуют большего контроля, управления и аудита.

(3) Необходимость обеспечения высокой степени автономности команды.

Мартин Фаулер дополнил эту точку зрения следующим замечанием: «С организационной точки зрения, когда я обсуждаю микросервисы с людьми, то, конечно, именно на этой области я больше всего концентрируюсь. С увеличением размера команды координировать людей становится все труднее [...] Поэтому вам нужно устанавливать барьеры, а микросервисы как бы вынуждают вас к неудобному способу работы — что, собственно, и нужно в любом случае, когда команда больше». Чтобы узнать больше по этой теме, ознакомьтесь с этим постом DreamFactory, где мы описываем путь Amazon, Netflix, Uber и Etsy к микросервисам.

Снижение стоимости, временных затрат и сложности внедрения микросервисов


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

Комментарии (7)


  1. hardim
    00.00.0000 00:00
    +1

    Главное что бы архитектор понимал для чего он хочет разместить приложение в докер контейнере. Иногда бывает просто "модно" и "сделайте потому что так лучше":) еще потому что в отчетик можно написать красиво. Главное: Девопс сразу должен сказать что масштабирование проект ложится целиком на архитектуру. Ресурсы и методы автоматического масштабирования с платформы он предоставит :)...


  1. olku
    00.00.0000 00:00
    +1

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


    1. GospodinKolhoznik
      00.00.0000 00:00
      +1

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


    1. svartberg
      00.00.0000 00:00
      +1

      скорее это поговорка. И называют ее даже законом и не просто структуру, а коммуникационную структуру: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.(с) Melvin E. Conway


  1. sved
    00.00.0000 00:00
    +1

    Расскажите чем микросервисы отличаются от старых добрых EJB? Вместо аппликейшен сервера у нас теперь кубернетис, а вместо EJB бинов - микросервисы.


    Как мы помним, EJB в итоге уступили "монолитному" Spring-у. Из-за ненужных проблем вызываемых Application сервером, а так же бессмысленной сложности, вызванной необходимостью писать все эти интерфейсы и сервис фасады.

    Возможность динамически и независимо деплоить EJB, вызывать их удалённо и независимый класслоадер (в общем, то чем часто обосновывают микросервисную архитектуру) оказались не нужны большинству разработчиков.


    Почему апологеты микросервисов думают что их не постигнет участь EJB (которые во многом прогрессивнее типичной REST-овой микросервисной архитектуры) ?


    1. 2ANikulin
      00.00.0000 00:00

      Тем же, чем и от старого доброго DCOM. Микросервисы это парадигма. А EJB и DCOM это тяжеловесные вендорные технологии


      1. sved
        00.00.0000 00:00

        Ну назвать EJB тяжеловесной технологией - это громкое заявление.

        И уж точно это не является "вендорным" (не знаю, с чего это вы так решили)

        Я писал, что сама парадигма показала свою несостоятельность (в большинстве случаев) на примере EJB. Является ли EJB тяжеловесной технологий - это отдельный вопрос. Если рассматривать отдельную EJB, то скорее нет (как и отдельный микросервис). В комплексе, система EJB вместе с application серверами - скорее да (что справедливо к любой микросервисной архитектуре, если рассматривать её как систему).