В настоящее время задача разбиения монолита на микросервисы приобрела поистине огромную популярность в бизнес-среде.
Как будто все корпорации в России вдруг осознали все перспективы «новой» архитектуры, получили пинок от начальства и бросились этим воспользоваться.
Рвение корпоративных чиновников, как всегда, безумно и беспощадно.
И здесь опять же огромные деньги, выделенные на пилотов, тратятся на то, что в лучшем случае никогда не взлетит, а в худшем случае будет реализовано, несмотря на все ошибки.
И, дамы и господа, самое удручающее то, что это явление отнюдь не изолированное.
Это характерно для всей ИТ-индустрии России.
В этой статье я предлагаю обсудить, какие ошибки возникают при разбиении монолита на микросервисную архитектуру (MSA), почему они возникают и к чему приводят. Ну и в конце я опишу, как должен быть организован эффективный и правильный процесс перехода на MSA и какой должна быть архитектура микросервисной системы.
Итак, ваша организация решила разбить старый добрый монолит на микросервисы.
Почему? Как правило, внятного ответа дать никто не может, а вообще все начинают описывать, как плохо им живется с монолитом.
Да, циклы релизов действительно очень сильно зависят от разных команд. Как вы думаете, почему в ISA все по-другому? Некоторые говорят, что микросервисы масштабируются гораздо лучше.
Ну, можно и так, но зачем вам это нужно? Нет, возможно, это необходимо, но вы понимаете, почему или просто используете увиденную фразу? Говорят, что каждый микросервис гораздо менее требователен к ресурсам: памяти, базе данных и т. д. И что? У вас закончились деньги на сервера? Какова ценность бизнеса? Коллеги, я не хочу сказать, что у ISA нет преимуществ.
Есть такие преимущества.
Но я хочу сказать, что какие бы цели вы ни ставили, приступая к разборному проекту, вы, скорее всего, поставите их неправильно и никогда их не достигнете.
Вы этого не добьетесь просто потому, что реализацией вашего проекта будут заниматься те люди, которые довели ваш монолитный проект до состояния некомпетентно написанного кода.
Более того, все подходы к реализации MCA настолько же отличаются от монолитного, как телефонная лапша 20-го века отличается от сетевых технологий нынешнего 21-го века.
И аналогия здесь действительно очень хорошая.
ТФОП подводит к квартире одну телефонную линию.
Обрыв любого участка линии приводит к ее выходу из строя.
Сетевые технологии динамичны и позволяют строить альтернативные маршруты.
Даже выход из строя 60% всей сетевой инфраструктуры страны в результате ядерной войны не приведет к выходу из строя остальных сетей.
То есть главное преимущество MSA перед монолитом — это его динамичность, которая может привести к предельной надежности системы.
Здесь необходимо уточнить: из самой ISA не следует, что она будет надежной.
MCA дает вам только возможность создавать надежные системы.
Но вы несете ответственность за встраивание надежности и дублирования функциональности в архитектуру вашей системы.
Теперь давайте рассмотрим типичные ошибки при разработке корпоративной микросервисной системы.
- Отказ менять бизнес-процессы
Говорят, любой бизнес реализует свои бизнес-процессы в коде.
И если 20 лет назад вы строили свои бизнес-процессы на основе своей монолитной архитектуры, то любая ваша попытка внедрить MCA заведомо будет обречена на провал.
Просто потому, что для этого необходимо изменить бизнес-процессы.
Пример? Сколько этапов согласования вопросов существует в вашей организации? Итак, в микросервисной команде количество таких этапов приближается к нулю.
Подавляющее большинство вопросов решается внутри команды, реализующей микросервис.
От команды не требуется поднимать вопросы о языке, на котором будет написан микросервис, на корпоративном уровне.
Некоторые могут выбрать Java, а другие — Python. Вы можете не поверить даже сейчас, но этот вопрос полностью находится в компетенции команды.
И это потому, что в случае каких-либо проблем проще ПЕРЕПИСАТЬ микросервис, чем его ПОДДЕРЖИВАТЬ.
По моему опыту, разработка простейшего микросервиса с нормальным продакшеном занимает неделю работы двух джуниоров, включая бюрократию по выводу его в продакшн, т.е.
обходится компании, включая различные накладные расходы, примерно в 50-100 тысяч рублей.
Если только аналитика занимает месяц работы 3-х команд, то никакого MSA у вас в организации нет, вы снова скатываетесь в лютый монолитизм.
- Доверьте управление проектом опытным монолитистам
После того, как вы забросили модернизацию своих бизнес-процессов, вполне логично, что вы доверите новый проект очень опытному человеку, который показал себя с лучшей стороны и вообще знает все ваши бизнес-процессы.
Возможно, кто-то вам сказал, что на старые проблемы должен смотреть новый, опытный человек, но вы отмахнулись от него как от глупой назойливой мухи.
И вот он.
Ваш новый/старый менеджер по развитию проекта.
Не удивляйтесь, что результат будет такой же, как и раньше, или даже хуже.
Когда в ISA начнут использовать монолитные решения, это ни к чему хорошему не приведет. Именно в этот самый момент вы подписали смертный приговор своему пилоту.
Возможно, вы даже наймете на микросервисные проекты опытных людей, которые уже съели свору собак, но это вас не спасет, просто потому, что их начальник не будет слушать.
Просто потому, что его мозг не заточен под МСА, и советы других он воспримет как чудовищную глупость.
- Архитектуру разрабатывают архитекторы без опыта девелопмента.
Вот сидит архитектор, который в жизни не написал ни строчки кода, и отдает приказы разработчикам.
Очень часто разработчики оказываются более квалифицированными, чем он сам, а приказы он отдает как Наполеон.
Приказы, конечно, глупые.
Примеры таких заказов смотрите ниже.
- Повторите функциональность монолитной системы.
Что ж, это логично: нужно сначала полностью воспроизвести то, что уже существует, а потом двигаться дальше.
Воспроизвести все баги и костыли, всю ту хрень, на которую разработчики годами плюют. Одного я не понимаю: почему эти архитекторы думали, что кто-то потом будет давать деньги на рефакторинг? Те.
вы копируете свою устаревшую систему, не приносите ничего положительного с точки зрения функциональности и будете жить с этим 20-летним хламом еще как минимум 10 лет до следующего рефакторинга.
- Повторное использование кода
Любой монолитист знает, что код нужно использовать повторно.
Если вы сделали функцию User::toString, то в рамках MCA ее теперь нужно выделить в отдельный микросервис и все 1000 других микросервисов будут ломиться в нее для сериализации каждого пользователя.
То, что первый же сбой в микросервисе обрушит всю систему — в монолитах такого не было.
К тому моменту система работала уже 7 лет и за это время произошла полная смена команды.
Сотни микросервисов.
Документации нет. Нет даже простого описания назначения каждого микросервиса.
И вообще непонятно, какой статус у микросервиса: функционирующий, деактивированный, экспериментальный и т. д. В случае возникновения проблемы трассировка микросервисов превращалась в полный кошмар.
В результате никто просто не задержался в команде надолго.
Текучесть стала бичом команды.
За 3 месяца команда могла просто полностью обновиться.
Это реальная история плохо спроектированной микросервисной системы.
Это финал, который ждет подавляющее большинство стартовавших сейчас пилотов.
И все из-за ошибок, которые я перечислил выше.
И теперь я хочу рассказать вам, как разработать микросервисную систему.
- Проанализируйте свой предыдущий опыт, составьте список того, что вы считаете успешным, а что стоит пересмотреть.
Проведите опрос клиентов, пусть они запросят необходимые изменения функционала.
Ваша цель — достичь нескольких бизнес-целей посредством одного небольшого и точного рефакторинга.
Ваша цель – не переписывать по 10 раз одно и то же, а создать бизнес-продукт, который будет приносить деньги.
Вам нужно не просто сделать копию устаревшей системы, вам нужно создать современную систему, которая выведет вас на передний план ИТ-индустрии.
Зачем тебе эти старые костыли?
- Пересмотрите свои бизнес-процессы.
Если ваш agile всегда скатывается в жесткий водопад, если согласования и аналитика занимают месяцы, то ваше производство программного обеспечения требует радикальной модернизации.
И для этого нужно.
- .
найти специалиста с большим опытом разработки микросервисных систем.
Даже если он не посвящен в ваши бизнес-процессы, этот новый человек взглянет на ваши старые проблемы свежим взглядом и даст действительно ценные рекомендации.
Кроме того, только человек с реальным опытом разработки микросервисов может предвидеть подводные камни, с которыми вы столкнетесь.
Ваш опытный монолитчик только всё испортит.
- Унаследованные разработчики — ваш резерв, который сможет выступить ценным экспертным звеном в новой разработке.
Но люди, которые пилили монолит в виде костылей, ни при каких обстоятельствах не должны становиться костяком разработки микросервисной системы и определять ее архитектуру.
Монолитикам стоит рассчитывать на стажировку под руководством людей с опытом построения микросервисных систем.
И главное, что ждёт монолитовцев, — это жёсткая поломка мозга и полная перестройка мышления.
- Каждый микросервис — это не просто небольшая серверная функция.
Это полный цикл разработки бизнес-функции.
Одна команда должна нести единоличную ответственность за всю разработку этой бизнес-функции, как на стороне клиента, так и в базе данных.
Как только вы начинаете делегировать часть разработки другим командам, вы сразу же начинаете увязнуть в интеграциях.
Интеграция в MSA еще более дорога, ненадежна и неэффективна, чем в монолит. Необходимо сократить их количество.
В качестве микросервиса вполне нормально выбирать CRUD для какой-либо сущности, например сущности соглашения с клиентом.
Ничего страшного, если команда предоставит и бэкенд, и фронтенд микросервис (или библиотеку) для работы с контрактами: список, создание, обновление, удаление.
Главное, что команда несет полную ответственность за то, как эта функция будет работать на сайте и в мобильных телефонах.
- Не нужно быть фанатичным при реализации микросервисной архитектуры.
При правильной микроархитектуре сервисов вы сами решаете, в каком виде выпускать приложение: в монолитной, микросервисной или бессерверной архитектуре.
Ожидайте, что ваше деловое заявление может измениться в любое время, и вы сможете легко вносить изменения.
Agile-разработка — это то, что без лишней болтовни действительно должно применяться на всех уровнях.
- Будьте осторожны с повторным использованием функциональности.
Наоборот, любой функционал должен дублироваться.
Ваш выигрыш в 10 гигабайт дискового пространства никого не впечатляет, если каталог, который используют 30 микросервисов, будет остановлен из-за сбоя, вызывающего каскадное завершение работы всей микросервисной системы.
Микросервисы должны ПРИНИМАТЬ сбои сторонних сервисов, а не усугублять их.
И этот принцип является основной проблемой монолитников.
После 20 лет работы с реляционными базами данных, после десятков лет опыта нормализации таблиц и структур данных в приложениях очень сложно приучить себя к мысли, что дублирование, репликация, шардинг, денормализация — это нормально и полезно для проекта, а повторное использование и нормализация потенциально проблемных мест, готова поставить всю систему.
- И вообще, что происходит после выхода из строя одного из модулей? Вам просто нужно смоделировать все такие сбои и правильно с ними справиться.
Каскадное отключение всей системы — это лишь один из сценариев.
Неприятностей может быть много.
В монолите все компоненты расположены в одном Jar. В MCA каждый микросервис разделен ненадежными и скомпрометированными сетевыми соединениями.
Это не плохо и не страшно.
Просто нужно это учитывать при разработке и предусмотреть сценарии разрыва этих коммуникаций.
- Если вы действительно любите Spring, Hibernate и OracleDB, то, скорее всего, вы никогда не сможете построить надежную и быструю микросервисную систему.
Весна была изобретена в годы становления монолитной архитектуры.
Это огромный монстр, который даже в функции простого Hello World превратится в jar-файл размером в сотни мегабайт. Просто запуск такого приложения занимает считанные минуты.
И эти гигабайты бессмысленного цифрового мусора будут пожирать ресурсы вашего сервера 24х7х365. Oracle, Postgres, MySQL — это все ужасные старые вещи, построенные из расчета, что база данных должна работать на одном сервере.
Да, проходит время и все эти базы данных приобрели возможности масштабирования, но они по-прежнему совершенно неповоротливы и ненадежны в этом вопросе.
Существуют целые классы баз данных (NoSQL, NewSQL), которые были созданы в парадигме больших данных, высокой доступности, распределенного хранилища и т. д. И эти оракулы с постгресом просто не способны с ними конкурировать по надёжности и скорости.
Все эти «прохладные» источники, оракулы и спячки — наследие уходящей эпохи монолита.
Суть микросервисов и облачных функций — быстрый запуск приложений при возникновении нагрузки, отсутствие состояний для высокой масштабируемости и безжалостная выгрузка всех приложений и ресурсов, которые в данный момент не нужны и только тратят оперативную память.
Заключение
В заключение хотелось бы еще раз отметить, что я ни в коей мере не против разбиения монолитных систем на микросервисы.Напротив, я считаю, что такой подход может привести к значительно большей устойчивости вашей ИТ-инфраструктуры.
Бездумное внедрение элементов микросервисной архитектуры без понимания общей теории построения таких систем, полное игнорирование отраслевой практики и здравого смысла в целом — вот что отправляет ваших пилотов на свалку истории.
Только ошибки людей вашей организации приносят слезы и убытки вашим инвесторам.
Напротив, разумный подход может ускорить работу ваших сервисов и сделать их чрезвычайно устойчивыми.
Поэтому мне очень хочется пожелать мудрости всем, кто занимается развитием ИТ в компаниях.
Теги: #Управление проектами #ИТ-инфраструктура #Микросервисы #микросервисная архитектура
-
Еще Немного Критики В Адрес 1С
19 Oct, 24 -
Краткий Обзор Серверов Upnp Для Mac
19 Oct, 24 -
Хайлоад 2008 - Сколько Платить?
19 Oct, 24 -
Нексус Один. Презентация Началась
19 Oct, 24 -
У Кого Оно Короче?
19 Oct, 24
