Каковы преимущества микросервисов и окупятся ли они для вашего бизнеса?

Опубликовано: 2022-01-12

Концепция микросервисов, подход к разработке программного приложения как набора небольших сервисов, существует по крайней мере с 2015 года. Микросервисы, обеспечивающие такие преимущества, как независимое развертывание и масштабируемость компонентов, сегодня в моде. Это связано с тем, что эти преимущества микросервисов приводят к невероятно высокой скорости разработки программного обеспечения. Поскольку потребители быстро меняют свои предпочтения и поведение, пользователи микросервисов могут идти в ногу со временем. Жизнь теперь прекрасна, говорят они. Целых 56% компаний, участвовавших в недавнем опросе IMB, планируют внедрить микросервисный подход в ближайшие 24 месяца.

Почти 80% нынешних пользователей говорят, что их бизнес, скорее всего, увеличит инвестиции в микросервисы. Преимущества микросервисов побудили Netflix, Amazon, eBay, Twitter и многих других технологических гигантов перейти от монолитной архитектуры к микросервисам. Но следует ли вашей компании использовать микросервисы? Это зависит от контекста и от того, перевешивают ли плюсы микросервисов минусы для вашего приложения. В этом блоге представлен обзор микросервисов и монолитного подхода, а также пять основных преимуществ использования архитектуры микросервисов. В нем также рассказывается об опыте ITRex в области микросервисов и предлагаются советы о том, когда компаниям следует (не) использовать микросервисы. Нырнуть в.

Определение микросервисов и сравнение с монолитной архитектурой

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

Микросервисы:

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

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

Однако без использования архитектуры микросервисов Amazon вряд ли превратилась бы в одну из самых ценных компаний в мире (рыночная капитализация которой на декабрь 2021 года оценивается в 1,694 триллиона долларов). Решение использовать преимущества микросервисов было принято еще в начале 2000-х, когда Amazon понял, что не может масштабироваться со скоростью роста клиентской базы из-за медленной разработки и проблем с кодированием.

Netflix осознал преимущества облачной архитектуры микросервисов в конце 2000-х годов, после того как в течение нескольких дней не мог отправлять DVD клиентам по почте из-за массивного повреждения базы данных. Разбив свое приложение на более чем 700 микросервисов, инженеры Netflix сегодня могут развертывать код тысячи раз в день, что позволяет компании ежедневно транслировать около 250 миллионов часов контента более чем 200 миллионам пользователей по всему миру. Какую архитектуру использовали эти звезды технологий и многие другие компании раньше, в дооблачные времена? Использовали монолиты.

Что такое монолитная архитектура?

Монолитное приложение строится как единое целое, объединяющее все компоненты, включая пользовательский интерфейс на стороне клиента, операции на стороне сервера и базу данных. Как правило, монолитная архитектура:

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

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

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

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

5 ключевых преимуществ микросервисов

1. Независимое развертывание

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

2. Меньший радиус разрушения взрыва

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

3. Изоляция данных

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

4. Использование правильной технологии

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

5. Эффективность

Подход с использованием микросервисов позволяет компаниям создавать небольшие межфункциональные группы вокруг одного сервиса или набора сервисов, которые могут работать гибко. Эта модель сводит к минимуму количество передач, когда одна команда должна ждать, пока другая выполнит свою задачу, будь то развертывание или тестирование, прежде чем они смогут начать свою работу. Отсутствие зависимости от другой команды ускоряет разработку. По данным опроса IMB, в котором приняли участие 1200 ИТ-руководителей и разработчиков, пользователи сообщают о многочисленных преимуществах использования микросервисов. Наиболее важные преимущества микросервисов, которые они ощутили, включают: 30 % — более высокий уровень удовлетворенности клиентов 29 % — более высокий уровень безопасности данных компании/клиента 29 % — более быстрый вывод на рынок 28 % — улучшенная производительность приложений 27 % — большая гибкость для масштабирования ресурсов или снижение на 26% — Повышение производительности труда сотрудников Есть ли проблемы с микросервисами? Что ж, как гласит популярная цитата, микросервисы — это не бесплатный обед. Читать дальше.

Плохая сторона микросервисов

1. Сложность

Присущая микросервисам сложность увеличивается с увеличением количества сервисов. Эта сложность многогранна и связана со следующим:

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

2. Затраты

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

3. Риски безопасности

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

Когда (не) использовать микросервисы

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

Вот наши ключевые советы, когда НЕ использовать микросервисы:

1. Если вы стартап, микросервисы — плохая идея. Будет разумнее начать с монолитного приложения и разбить его на более мелкие компоненты, когда это станет слишком сложно для команды из двух пицц. Чего вы хотите, так это проводить дешевые эксперименты, а не вкладывать массу времени, усилий и денег в создание сложной архитектуры для продукта, потребительская ценность которого еще не подтверждена. Монолиты — это идеальный способ протестировать (и отбросить) MVP, чтобы быстро узнать, что принесет пользу вашим клиентам. Как говорит Мартин Фаулер, еще один уважаемый гуру микросервисов: i) Почти все успешные истории микросервисов начинались с монолита, который стал слишком большим и распался. ii) Почти во всех случаях, когда я слышал о системе, созданной как микросервисная система с нуля, она заканчивалась серьезными проблемами. Примечание. Если домен продукта неясен, вам также не следует использовать микросервисы, когда вы начинаете работу. Возможно, еще слишком рано переходить к сложным архитектурным решениям, и есть вероятность, что ваш подход к установлению коммуникаций и границ будет далеко от цели, когда ваш проект созреет.

2. Микросервисы — не лучший выбор для решения, которое не является сложным и может поддерживаться относительно небольшой командой. Развертывание сложной микросервисной архитектуры для инструмента планирования событий вашей компании может действительно развлечь ваших разработчиков, но стоит ли оно всех усилий? Микросервисы в первую очередь предназначены для решения одной проблемы: сложности. Как утверждает Мартин Фаулер, «даже не рассматривайте микросервисы, если у вас нет системы, слишком сложной для управления как монолита».

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

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

Микросервисы имеют смысл, когда любое из приведенных выше утверждений неверно. Другими словами:

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

Честным реальным примером из портфолио ITRex может быть собственный инструмент кибербезопасности, который клиент хотел преобразовать в платформу «Безопасность как услуга». Микросервисы идеально подошли для этого проекта, потому что монолитная архитектура просто не может обеспечить масштабируемость, необходимую SaaS-решению для обслуживания растущего числа клиентов, или гибкость, необходимую для развития и опережения хакеров.

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

И было фитнес-зеркало с искусственным интеллектом, оснащенное 3D-камерами, и модель ML, которая поставлялась с датчиками IoT, прикрепленными к оборудованию пользователя. Его основные компоненты, включая панель администратора, приложение для Android и систему управления правилами, были созданы разными командами на разных этапах проекта, каждая из которых использовала свой код и архитектуру. Когда сложность обработки их всех стала невыносимой, мы поняли, что нам нужно построить один сервер для централизованного управления. И мы преобразовали их в микросервисы, переделав их код и создав новые базы данных. Были и другие преимущества использования микросервисного подхода, такие как предотвращение дублирования кода или функций.

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

Сноска

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

Все еще не уверены, стоит ли вашей компании пользоваться преимуществами микросервисов? Свяжитесь с консультантами ITRex. Мы поможем вам разобраться.

Первоначально опубликовано на https://itrexgroup.com 10 января 2022 г.