среда, 20 февраля 2019 г.

Успешный переход к микросервисам: зачем, когда и как


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

Когда бизнес приложение, и как следствие команда разработки становится больше и достигает определенного размера, у компаний появляется серьезная проблема управления проектом. Кроме того, если программный продукт реализован в виде монолитного приложения, то оно также сталкивается с технологическими проблемами. В подобных случаях бизнес требует решения для исправления рабочего процесса и улучшения совместной работы на проекте.
Архитектура микросервисов (MSA) – это ответ на проблемы связанные с традиционным монолитом, когд его сложность начинает порождать проблемы но требует дальнейшего масштабирования.
Большие IT компании, такие как Netflix, Amazon и Uber показывают как миграцию к микросервисам влияет на из бизнесс. Нетехнические компании также получают бонусы. Случай Walmart, который восстановил свое online присутствие с помощью микросервисов может послужить примером трансформативного потенциала подобной архитектуры для традиционных предприятий.

Согласно недавним опросам, 80% компаний расчитывают на микросервисы и двигаются в направлении к полностью микросервисовой архитектуре. 9% уже при создании своего  программного обеспечения используют распределенную структуру, 38% совместно используют микросервисы и традиционный монолит, а 33% планируют переключится в ближайшем будущем.

Почему: Роль микросервисов в разработке корпоративных систем

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

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

Преимущества и сложности микросервисов

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

Преимущества:

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

 Недостатки:

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


 - Тестирование. Архитектура монолита использует сторонний WAR. QA специалисту нужно лишь запустить файл и подтвержить соединение монолита и базы данных. В микросервисах необходимо выполнять подобную проверку для каждого микросервиса.

Когда: Правильное время для перехода к архитектуре микросервисов

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

Переход к микросервисам нее всегда бывает простым. Но эти затраты окупятся со временем.

Как: Способы перехода к микросервисам

Как интегрировать микросервисы в монолитное приложение? Есть два фундаментальных подхода:

1. Разбить монолит на микросервисы

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

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

2. Сохранить монолит и строить микросервисы вокруг него

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

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

Завершение

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



Комментариев нет: