Как показал опрос О’Reilly, для предприятий, которые хотят создавать облачные приложения, микросервисы являются новой технологией, и для для них первостепенное значение имеет понимание ее нюансов, сообщает портал ComputerWeekly.

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

В течение последних нескольких лет наблюдается рост внедрения микросервисов. Исследование O’Reilly «Microservices Adoption in 2020», проведенное среди более чем 1500 организаций, показало, что лишь около четверти из них вообще не используют микросервисы. Только 10% из остальных используют их более пяти лет, что означает, что большинство решилось на использование микросервисов в течение последних нескольких лет.

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

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

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

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

Потенциальные недостатки

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

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

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

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

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

Еще одним сложным вопросом при создании приложения или сервиса на основе архитектуры микросервисов может стать вопрос о данных, а точнее, о том, где их хранить. Это связано с тем, что каждый экземпляр микросервиса, скорее всего, будет иметь собственное хранилище данных, но некоторые приложения могут требовать возможности доступа к общему хранилищу. Различные сервисы также будут предъявлять разные требования к хранению данных. Некоторые специалисты утверждают, что наиболее целесообразно использовать базу данных NoSQL, в то время как другие выступают за использование SQL, если организация уже развернула такую СУБД.

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

Планируйте тщательно

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

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

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

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

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

Интересно, что в рамках опроса O’Reilly выяснилось, что бóльшая, чем в среднем, доля респондентов, сообщивших об успехе микросервисов, решила реализовать их с помощью контейнеров, в то время как бóльшая доля респондентов, назвавших свои усилия по созданию микросервисов неудачными, не использовала контейнеры.

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

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

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