О микросервисах, их плюсах и минусах: интервью с Антоном Гриценко

Совсем скоро, 29 сентября, наш коллега, эксперт и тренер Sigma Software University, Антон Гриценко, представит в Харькове курс «Microservices with Spring Boot and AWS», который ранее с успехом прошел в Одессе, Киеве и Львове.

Какие вопросы будут затронуты, почему тема микросервисов востребована уже многие годы и какое будущее их ждет? Об этом и многом другом сегодня говорим с Антоном, ведущим разработчиком в компании Sigma Software, который занимается разработкой программного и аппаратного обеспечения уже более 10 лет, из них последние 5 лет посвятил проектированию и реализации приложений на основе микросервисной архитектуры (MSA) и сервис-ориентированной архитектуры (SOA).

Антон, почему ты заинтересовался темой микросервисов?

Потому что эта технология сегодня – это must have для любого специалиста, начиная с уровня Strong Middle и выше. Появление и развитие микросервисов связано с эволюцией области в целом. В течение продолжительного времени использовался подход, ориентированный на использование монолитных приложений. Эти приложения разрабатывались одной командой и развертывались как единое целое. В определенный момент стало очевидно, что в ряде случаев, разбиение монолита на несколько независимых приложений может принести выгоду с точки зрения нефункциональных и организационных требований. Этот подход стали активно использовать и продвигать крупные компании, такие как Netflix, EBay, Google и другие. Они популяризовали microservice architecture и event-driven design, демонстрируя свои успехи в применении этих подходов.

На волне этой популярности, вслед за гигантами, микросервисную архитектуру стали активно использовать многие компании. Однако, впоследствии произошел спад.

Почему же?

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

Проведу аналогию с управлением командой. Одно приложение – это как команда из одного человека. Работать с ним легко, но есть определенные ограничения. Три приложения – это команда из трех человек, управлять которыми можно уже более эффективно: давать им разные задачи, в том числе распределять и масштабировать их. К примеру, одну небольшую задачу можно поручить одному человеку, а более существенную – двум другим. На этом этапе члены команды еще способны договориться самостоятельно. Когда же команда становится больше, нагрузка на коммуникацию и управление существенно возрастает, и уже необходимо выделять отдельного специалиста, чтобы управлять взаимодействием членов команды.

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

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

Зачем, по-твоему, нужно изучать эту архитектуру?

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

Каким ты видишь будущее микросервисов?

Это один из вариантов архитектуры, имеющий широкое применение в корпоративной сфере.

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

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

Чему ты будешь уделять внимание на курсе?

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

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

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

Что тренинг может дать разработчикам?

Знания, полученные на реальных проектах. Но об этом я уже сказал выше.

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

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

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

Когда человек слышит о микросервисах, у него в голове должен возникать определенный набор понятий, которые касаются инфраструктуры, шаблонов, подходов к разработке. С одной стороны, если мы говорим об инфраструктуре, то разработчик должен понимать, что такое мониторинг и как его стоит организовывать. Ему важно знать, что такое circuit breaker или client load balancing, если мы говорим про паттерны. Он должен владеть основными аспектами Spring Cloud, знать что такое correlation id и sleuth. У хорошего разработчика должно быть определенное виденье области, потому что сталкиваться с этим непременно придется.

 

Антон, спасибо за интересное интервью! А всех, кому интересна тема микросервисов, приглашаем присоединиться к курсу, набор еще открыт!

Регистрируйтесь здесь.

Последние новости

Создаем крутой UX: полезные советы для предпринимателей

По данным Google Trends, интерес к UX (взаимодействию с пользователем) растет с каждым годом. И это неудивительно. В своем недавнем….

Работаем с критикой эффективно

В течение всей профессиональной жизни мы сталкиваемся с критикой, которая может исходить от наших коллег, от руководства, от нас самих…..

QA FEST 2018: краткий обзор

Дмитрий Придатко, Test Engineer в компании Sigma Software побывал на слете специалистов по тестированию — ежегодной конференции QA Fest, которая….