Почему микросервисы помогут вам ускорить поставку бизнес-ценности.
История появления микросервисов
В статье От микросервисного монолита к оркестратору бизнес-сервисов (укороченный вариант в видео) я рассматривал механизм эволюции IT-архитектуры и причины, которые подталкивают к изменениям от одной стадии к другой. Я бы хотел дополнительно погрузить вас в историю того, как и почему мы пришли к микросервисам.
В прошлом веке, когда бизнес понял, что с помощью IT можно получить преимущество на рынке, в создание программ начали вкладывать много денег, и стало появляться множество небольших программ и утилит для работы. Их можно сравнить с разными инструментами, которые свалены в кучу, и вам нужен мастер, который соберёт из них конвейер для бизнеса. Инструменты были разношёрстные, а среда, в которой они работали, не была готова управлять сложностью, которая возникала, когда этих утилит становилось слишком много.
Неудобство управления этим «зоопарком» привело к тому, что появились огромные монолитные системы типа Enterprise resource planning (ERP). Их преимущество было в том, что они предложили работу по принципу «одного окна». Стали не нужны множество мелких инструментов, появился универсальный огромный колосс, который сделает всё, что нужно на вашем предприятии. Его можно бесконечно расширять функциями, которые должны быть устроены по его подобию, и которые делают его ещё больше, и благодаря которым он всё глубже пускает корни в вашу компанию.
Такой подход имеет ряд недостатков:
Доставка бизнес-ценности происходит довольно медленно, потому что монолитная система должна быть целиком согласована, целиком протестирована, целиком выпущена в релиз. В таких системах релизный цикл может быть 6–12 месяцев, что для современных скоростей считается очень медленным.
Монолитная система часто требует использовать её собственный стек технологий для создания расширений. Даже если существует технология разработки, которая лучше решает конкретную задачу бизнеса, разработчикам придётся использовать технологию монолита, чтобы встроить новый продукт в этот монолит. Такой выбор бывает вреден бизнесу, потому что у конкурентов может не оказаться такого ограничения и они убегут вперёд.
Эти две проблемы тормозили развитие компаний, потому что их невозможно обойти в рамках архитектуры монолита. Отвечая на эти проблемы, разработчики и IT-архитекторы снова начали возвращаться к идеям создания небольших сервисов, каждый из которых отлично решает свою маленькую бизнес-задачу. Они называются микросервисы.
Этот подход очень похож на то, с чего всё начиналось, когда было много независимых утилит. Разница в том, что сейчас более развиты технологии инфраструктуры, где разворачиваются микросервисы. Инфраструктура и подходы к её созданию готовы выдержать сложность управления сотнями таких сервисов. Кроме этого, сильно продвинулись вперёд принципы проектирования классов и сборок, принципы построения IT-архитектуры, модульного и интеграционного тестирования, логирования и мониторинга. Всё это дало ключ к управлению сложностью микросервисной архитектуры.
Почему микросервисы?
Довольно много внимание уделено микросервисам, потому что на данный момент это единственный подход, который создаёт возможность быстро изменять части системы и подстраивать её под постоянные изменения извне.
Микросервисы позволяют создать такой «рой», в котором каждая боевая единица отлично делает свою работу, умеет понимать общие задачи и работать на общую цель, при этом по своим задачами почти автономна. Если в такой «рой» кинуть палку или попытаться сбить его рукой, то структура немного изменится, потому что он (рой) увернётся от удара, но будет продолжать делать своё дело как единое целое; его целостность и работоспособность не нарушится из-за внешних случайностей.
В этом смысле тема микросервисов очень важна для создания антихрупного приложения (это один из инструментов, который обеспечивает антихрупкость в IT). Если же мы создали хрупкое приложение, то оно является уязвимым, оно боится влияющей на него переменчивости. А в современных условиях, когда бизнес часто работает в условиях высокой неопределённости и изменчивости среды, разумно закладывать антихрупкость в систему. В этом смысле создание «роя», который не боится перемен, выгоден для стабильного развития бизнеса.
Ускоренная поставка бизнес-ценности
Когда система состоит из множества независимых друг от друга микросервисов, их можно изменять и обновлять тоже независимо друг от друга. Когда при работе с монолитом все изменения сливались в одну систему, потом всё это тестировалось, потом выходило в релиз, то было ощущение, что многие изменения в системе просто запаздывают не по своей вине. То есть новые функции готовы, но ждут общего релиза.
С микросервисами этой проблемы нет. Если одни микросервис изменился, то только его одного можно зарелизить, не нужно ждать всех остальных.
Такой подход облегчает тестирование и ускоряет поставку релизов пользователям, потому что тестировать нужно только небольшие участки системы. В хороших командах релизы микросервисов поставлены на поток, они делаются автоматически по несколько раз в день. При этом пользователи непрерывно получают обновления, а бизнес успевает обгонять конкурентов.
Дешёвое масштабирование и эффективный расход ресурсов
Каждый микросервис выполняет свою небольшую бизнес-задачу. Если пользователи увеличили нагрузку на систему, то, скорее всего, они нагрузили не все сотни микросервисов, а только 5–6 штук, которые участвовали в обработке этой задачи. Микросервисная архитектура позволяет выделить эти 5–6 микросервисов, дать только им больше ресурсов, чтобы смаштабировать их горизонтально.
Здесь необходимо объяснить разницу между вертикальным и горизонтальным масштабированием. Вертикально масштабируется один мощный сервер, на котором развёрнута система. При таком подходе по мере наращивания железа падает КПД от этого наращивания. Например, если на сервере увеличить мощность в 2 раза, то это может дать прирост на 60–80%, а не в 2 раза. Кроме этого, у серверов и ПО есть предел по вертикальному масштабированию, в который может упереться, не достигнув нужной производительности.
Если у вас есть микросервисы, то вместо увеличения мощности одного сервера, вы можете создать десятки копий вашего приложения и разместить их на небольших серверах, или даже в виртуальных контейнерах, что даст прирост производительности на количество запущенных копий. Я сейчас не буду вдаваться в подробности того, как должны быть спроектированы приложения, которые способны горизонтально масштабироваться, потому что это довольно узкая тема и IT-архитекторы с ней хорошо знакомы. Нам сейчас важно, что микросервисная архитектура позволяет делать горизонтальное масштабирование, которое позволяет почти линейно и бесконечно увеличивать производительность системы.
В пример этого подхода хочу привести проект Мисс Россия. В блоге Microsoft вышла моя статья Как мы «Мисс Россию» на руках переносили. Там описан довольно примечательный для нас кейс. Дело в том, что конкурс «Мисс Россия» проходит две недели в году, в это время система испытывает перегрузки от посетителей и тех, кто голосует за участниц. В остальное время нагрузок нет, а большинство сервисов, которые отвечают за голосование и отсев накрутки голосов, просто выключены.
В этом проекте использование микросервисов дало большую экономию на ресурсах по сравнению с монолитным приложением, которое использовалось до этого:
Наращивание мощности происходит в облаке в те моменты, когда приходит много пользователей. Для заказчика это значит, что он платит за «железо» только тогда, когда оно необходимо для бизнеса.
Микросервисы работают независимо друг от друга, поэтому их можно включать и выключать при необходимости. Соответственно, те микросервисы, которые нужны для голосования, выключены и не забирают ресурсы весь год, кроме двух недель.
На этом примере хорошо видно, что бизнес может очень гибко организовывать свои расходы и отвечать на потребности пользователей благодаря микросервисам. С монолитом так изящно сделать бы не получилось.
Переход на микросервисы
Тема перехода на микросервисную архитектуру стала одной из самых горячих на конференциях по архитектуре ПО. Бизнес почувствовал, что такая архитектура даёт преимущество.
Заказчики и разработчики захотели раздробить монолитные приложения на множество маленьких сервисов, чтобы увеличить скорость доставки релизов до пользователей, разделить ответственность команд, уменьшить взаимозависимость бизнес-функций приложения и использовать горизонтальное масштабирование вместо вертикального.
Если вы решите, что для вашего бизнеса будет выгодно использовать микросервисы вместо монолита, то используйте вот эту шпаргалку, чтобы не потратить деньги и время впустую.
Комментарии (39)
vasyakolobok77
06.11.2023 08:54+4Почему микросервисы помогут вам ускорить поставку бизнес-ценности.
Слишком громкое заявление. Микросервисы – это не серебряная пуля, и в общем случае под каждую задачу нужен свой подход, своя архитектура.
создать десятки копий вашего приложения ... что даст прирост производительности на количество запущенных копий
Слишком громкое и неверное заявление. Ваш МС не изолирован ведь от других частей системы (а иначе это не часть системы) и при масштабировании одной части системы вы будете упираться в производительность другой части (закон Амдала). Например, упретесь в производительность БД и придется думать как оптимизировать работу с ней: разделение чтения и записи, попытка ввода слоя кеша, проблема с инвалидацией кеша и т.д. т.п. Решение одной проблемы будет плодить другие и так далее по кругу.
Дешёвое масштабирование и эффективный расход ресурсов
Тоже слишком громкое заявление. Да, если вы арендуете ресурсы в облаке, то вам проще управлять ресурсами и мыслить абстракциями request cpu / ram у pod'ов. Но дешево и эффективно ли это? – вопрос открытый, потому что все скрыто от вас, а цена за оверхед k8s просто включена в стоимость ресурсов. Если компания большая и имеет свой ДЦ, то ей дешевле управлять ресурсами через менеджеры ВМ.
Ко всему прочему не все так радужно с облаками, stateful set в k8s это просто костыль и постоянная боль с отваливающимися volume'ами. Т.е. опять же, решение одних проблем (простота доставки) порождает другие проблемы (ненадежность сетевых хранилищ).
К чему это я все? Кроме очевидных преимуществ МСА стоит подсвечивать и их недостатки, которые нужно учитывать. Плюс не хватает примеров, как стоит и как не стоит дробить системы, чтобы вместо МСА не получить распределенный монолит.
AlexanderByndyu Автор
06.11.2023 08:54Спасибо за уточнения. Даже не думал, что описал все слишком радужно. Если у вас есть ссылки на статьи, которые рассказывают об ограничениях, то скиньте сюда. Уверен, что они будут полезны тем, кто изучает тему микросервисов.
От себя могу добавить вот эту статью «От микросервисного монолита к оркестратору бизнес-сервисов» https://habr.com/ru/articles/496934/
JordanCpp
06.11.2023 08:54+2Не статьи, а комментарии в соседней статье о микро сервисах.
https://habr.com/ru/companies/ruvds/articles/770262/comments/#comment_26123686
Очень много годных комментов.
JordanCpp
06.11.2023 08:54+3На мой взгляд, большинство восторженных статей о микросервисах, больше напоминают инфоцыганство. Технология рулит, но при большой нагрузке, где реально следует выделить отдельный независимый сервис. Всё остальное сложность, ради сложности. Ну и авторитетные пацаны от ИТ советуют.
AlexanderByndyu Автор
06.11.2023 08:54Если этот подход правда может помочь бизнесу, то почему бы об этом не написать?
JordanCpp
06.11.2023 08:54+6Такой подход выгоден всем.
Рост кол-ва железа, девопсы счастливы и заполонили экологическую нишу.
Разработчики счастливы, только они понимают, как что работает. И каждый юнит на счету.
Бизнес счастлив, ведь они растут инфраструктура развивается, девопсы заказывают больше железа, разработчики рапортуют о росте кол-ва микро сервисов.
Все счастливы.
Только огорчён здравый смысл. Миллиарды инструкций в секунду просто греют проц. Лишние синхронизации. Лишние инстансы БД. Излишнее железо и его поддержка. Лишние синхронизации и добавленные тормоза по сетевым взаимодействиям по сети между микросервисами.
В итоге, в пиццерии работают 250 разработчиков и выкатывают фичи каждые 5 минут.
AlexanderByndyu Автор
06.11.2023 08:54Вы же не рассмотрели часть, связанную с конкурентной борьбой. Если у вас все наносекунды оптимизированы, но вы не умеете как конкуренты выкатывать новые фичи каждые пять минут, то может так случиться, что бизнес, на который вы работаете, не выдержит конкуренции. И зачем тогда эти невероятные оптимизации железа и разработчиков? Надо двигаться быстрее других с точки зрения бизнеса, даже если это будет не максимально оптимально по железу. Микросервисы – это про бизнес. Собственно, поэтому я и выбрал для статьи хабы про управление
JordanCpp
06.11.2023 08:54+1Очень может быть. От бизнеса зависит.
AlexanderByndyu Автор
06.11.2023 08:54+1Да, согласен. И я, как инженер и IT-архитектор, прекрасно понимаю то, о чем вы говорите. Но предпочитаю ориентироваться на бизнес. Если нужны нано-секунды, то значит упираемся и достигаем их, а если скорость поставки, то для этого есть понятный инструмент – микросервисы.
JordanCpp
06.11.2023 08:54+3Возможно у меня проф деформация от хайлоад веба на С++. Меня напрягает лишний переход по указателю, плохая локальность данных,непродуманная схема БД, не желание юзать SQL, лишние задержки и т. д
AlexanderByndyu Автор
06.11.2023 08:54О, да, тогда микросервисы для вас – это просто огромная коллекция того, как можно сделать неоптимально :)
SpiderEkb
06.11.2023 08:54+1Встряну со своей болотной кочки.
У нас вопрос производительности тоже очень остро стоит. Все поставки обязательно проходят через нагрузочное тестирование на копии промсреды. С выявлением узких мест, излишнего потребления ресурсов и т.д. и т.п.
И уж если (в частности) говорить об SQL, то это не всегда оптимальное решение (наш технологический стек позволяет как прямую работу с БД, так и интегрированный в язык разработки SQL).
И если вы используете SQL для получения сотни записей по одной таблице по заданному значению ключа - НТ вы не пройдете. Потому что быстрее и эффективнее это сделать прямым чтением. И наоборот - когда у вас сложный запрос по нескольким таблицам и большие объему выборки - тут наоборот прямое чтение проигрывает в эффективности.Также не использует JSON - только ABI контракты. Слишком большие накладные расходы на запаковку-распаковку.
Ну и еще много чего - длинный список "нефункциональных требований".
dph
06.11.2023 08:54Но микросервисы, в среднем, усложняют и удлиняют процесс доставки фич, а не наоборот.
Микросервисные решения сложнее разрабатывать, сложнее модифицировать, сложнее выкладывать, сложнее тестировать - все это очень печально сказывается на скорости поставки.
В 90% случаев выбор МСА - это ошибка архитектора.AlexanderByndyu Автор
06.11.2023 08:54Это мне напомнило времена, когда я ещё консалтил и помогал справляться с техдолгом. Помню открываю код, а там в обработчках нажатия кнопок все сразу: авторизация, логирование, SQL-код, работа с кэшем. И так во всех обработчках по всей системе. Как следствие: жуткое дублирование, работа через статические методы, невозможность модульного тестирования. На вопрос к разработчикам, почему они не сделали нужные слои абстракции, они ответили, что так проще, весь код сразу видно. Разработчикам тактически так и правда было проще, но бизнес стратегиски от этого страдал, потому что тестирование было долгое, релиз делали долго и с ошибками, новых разработчиков подташнивало от кода и они увольнялись. Другими словами, если бизнесу нужны микросервисы, чтобы победить в конкурентной борьбе, значит их надо сделать. То, что "это же сложно" бизнес не должно волновать.
Отдельный вопрос, что микросервисы суют там, где они не нужны. Например, создают какую-то внутреннюю систему на 100 пользователей и накручиваю туда 50 микросервисов, потому что это модно. Я считаю, что это тоже клинический случай, только в другую сторону. Так делать, конечно, не нужно и с такими архитектурными астронавтами надо бороться как и с теми, кто боится сложности, когда она нужна.
dph
06.11.2023 08:54Эээ, и при чем тут микросервисы?
Если разработчики могут писать микросервисы (со всеми их сложностями), то написать модульный монолит с нормальным архконтролем для них не проблема.
Нет никаких проблем написать монолит с нормальным тестированием, нормальной выкладкой и нормальной внутренней логикой - и это гораздо проще, нежели сделать аналогичное решение на микросервисах.
Микросервисы нужны - но довольно редко и совсем не описанным причинам. И бизнес тут вообще не при чем.
kaichou
06.11.2023 08:54+1Нет репрезентативной выборки, в которой продемонстрировано, что этот подход может помочь бизнесу больше, чем противопоставляемый ему.
dph
06.11.2023 08:54Но микросервисы вообще никак не связаны с бизнесом, никаким образом.
То, что написано в статье - произвольный набор слов, не связанный ни с микросервисами, ни с монолитами.
vagon333
06.11.2023 08:54+1А кто мешает в ERP использовать функционал микросервисов?
Т.е. единая система, но функционал не встроен в монолит, а вызывает микросервисы.
Особенно:
- функционал в разработке, когда возможны частые изменения;
- сложный функционал, когда бесполезно впихивать невпихуемое.
Есть рабочий пример. Прекрасно живет.
Batalmv
06.11.2023 08:54+2Неудобство управления этим «зоопарком» привело к тому, что появились огромные монолитные системы типа Enterprise resource planning (ERP).
На самом деле не все так плохо. Люди придумали еще Х десятилетий назад декомпозицию функций и успешно ее реализовывали. Страшные и огромные "монолиты" вроде банковской ОДБ или телекомовских "биллингов" довольно таки "модульные" внутри :)
Доставка бизнес-ценности происходит довольно медленно, потому что монолитная система должна быть целиком согласована, целиком протестирована, целиком выпущена в релиз. В таких системах релизный цикл может быть 6–12 месяцев, что для современных скоростей считается очень медленным.
В релаьно мире в больших корпорациях все не совсем так. Давайте посмотрим трезво на ситуацию. Большая система - почти всегда это продукт компании, которая продает его многим крупным клиентам. Это не что-то самописное. Это ПРИНЦИПИАЛЬНЫЙ момент. Я распишу:
Такая система всегда имеет "ядро", которое общее для всех клиентов и заложенные возможности кастомизации (как в виде настроек аналитиками, так и добавлению уже своих моделй, адаптеров, "прокладок". и т.д.)
Глазами продуктовой компании вам надо развивать свой продукт ("ядро"), который должен работать у всех клиентов одинаково успешно. И тут никакой спешки нет. Стабильность стократ важнее сиюминутного time-to-market маленькой фичи.
Если вы делаете не конечный продукт, а платформу, на которой крутится много продуктов в куче разных инсталляций - у вас очень сложное тестирование, так как вы тестируете не функции одного банка/телеком оператора, а куда более масштабную задачу конструктора функциональности. Уже тут тоже понятно, что чуда нет и быстро никто никуда не идет.
....
Эти две проблемы тормозили развитие компаний, потому что их невозможно обойти в рамках архитектуры монолита.
Ничего они не тормозят по совершенно другой и прозаической причине. Рассмотрим условный банк, который спокойно себе работает на "ужасном" монолите в виде ОДБ. Как так то? Все просто. Вам нужно подняться на уровень Enterprise архитектора. И там вы увидете, что ОДБ - просто один квадратик. Да, его можно рисоватьбольшим и очень большим, но еще есть очень много других квадратиков. К примеру, интернет-банкинг. Это отдельный квадратик, где мы отлично можете применить "микросервисы", так как это отдельная система, которлой от ОДБ просто надо API. И всею Или не можете, так как этот квадратик тоже банк закрыл "платформенным" решением, которое кастомизировал по себя (те же яйца: ядро + кастомные модули).
----------------------
Вы сделали ошибку в самом начале. Даже не ошибку в вашем решении (которое весьма вериоятно хорошее и его архитектура соответствует требованиям), а в написании статьи. Все идет от требований.
Если я выбираю архитекутуру для системы, которая пишется с нуля под конкретного заказчика - велкам, микросервисы, agile, ... вперед и с песней
Если же я выбираю архитектуру для платформы, которая будет продана сотням клиентом, меня больше заботид, как отделить общий код (ядро) от кастомизации и обеспечить успешные внедрения платформы при сохрании максимального разумного процента, который делает едитное ядро. Потому что тогда я могу продать этот код 100 раз :) И тут уже time-to-market не так важен. Точнее он важен, но я могу его банально решить, вынеся этот функционал в область кастомизации и дав клиентам либо low-code approach (что выносит в одну калитку разработку), либо в кастомный модуль "напиши сам" (и тут клиент имеет полное право примеять снова все, что нравится).
-----------------
Про ресурсы я ничего писать не буду, выше уже отписались, что влияние микросервисной архитектуры именно на утилизацию ресурсов сильно преувеличено. Как минимум там, где сразу об этом думали.
SpiderEkb
06.11.2023 08:54Для начала - снимаю шляпу за столько внятное и толковое разъяснение ситуации.
Я уже писал выше. Работаю как раз в банке. И как раз в Управлении разработки центральных банковских систем - это то самое, что крутится на центральных серверах, работает с клиентскими данными и обеспечивает базовый функционал банка. То, что называется мастер-система. И еще более того - лично я в команде "ядровых функций АБС".
И Вы опять на 146% правы - вокруг этого существует еще несколько десятков разного рода "внешних систем", которые могут вообще на других платформах и технологических стеках работать (у нас АБС работает на платформе IBM i, на внешних системах есть и RHEL и SLES и бог знает что еще...).
Так вот, даже АБС это не монолитный монолит. Тут нет какого-то "единого монолитного ядра". Это огромная куча модулей ("программных объектов" в терминологии нашей платформы), связанных между собой стандартными (для данной АБС) контрактами. У нас выкуплены все оригинальные исходники и бывают ситуации, когда возникает нужда что-то изменить в стандартном модуле - просто берем нужный исходник, правим его и заменяем соотв. программный объект (что в единичном случае составляет мизерны доли процента от общего объема работающего кода и уж тем более не требует остановки системы что просто нереально по нормативам регулятора).
Изначально поставляется минимальны набор модулей, реализующий базовый функционал. Все, что нужно сверх него - это ужа сам, под свои потребности, следуя документированным стандартам на ядровые ABI, форматы данных и общую архитектуру.
Плюс система уже обросла (и продолжает прирастать) новыми модулями, теми, что разработаны нами под наши бизнес-процессы.
И все это работает именно так, как я написал в начале - как совокупность акторов, но не какой-то монолитный монолит (ну разве что все это работает на одном, условно, сервере). Какие-то акторы могут работать последовательно в рамках одного задания, какие-то параллельно в рамках нескольких заданий (задание, job, - это основная сущность платформы - все, что работает, работает в задании - зашел терминалом на сервер - запустилось интерактивное задание, открыл еще одно окно терминала - еще одно задание, можешь программу запустить прямо в этом задании, можешь в отдельном фоновом - по завершении программы оно также завершится).
Т.е. фактически одновременно на сервере крутится тысячи таких вот заданий и в каждом работает какой-то модуль, реализуя свой бизнес-процесс. Они могут взаимодействовать между собой разными способами (скажем, есть способы распараллеливания обработки больших объемов данных, когда головной процесс организует "конвейер", запускает нужное количество фоновых заданий-обработчиков и затем осуществляет выборку данных, подлежащих обработке и по мере поступления данных выкладывает их на конвейер откуда они разбираются обработчиками).
Что-то в виде запросов (через MQ или ESB) приходит из внешних систем. Что-то тем же путем уходит во внешние системы...
И Вы опять же правы
Стабильность стократ важнее сиюминутного time-to-market маленькой фичи.
Просто потому что ошибка на проме может стоить космических денег. Посему этап тестирования может занимать кратно больше времени чем этап разработки. Потому что 70-80% (минимум) кода смело можно относить к mission-critical.
AlexanderByndyu Автор
06.11.2023 08:54А зачем вы берете микросервисы и говорите, что банкам и плантформам они не нужны? Там же совсем другая бизнес-модель и другие отношения с клиентами. Банки зарабатывают на процентах по кредитам и комиссии за транзакции. Что будет, если личный кабинет юрлица не будет работать день? Юрлица позакрывают счета и уйдут в другой банк? Нет, конечно. Они приедут в банк с бумажными платежками и сделают, что им надо. Может бухгалтер поворчит немного, но с точки зрения прибыли банка ничего не поменятся. А если не будет работать мобильное приложение банка целый день? Разве физики тут же закроют счета, кредитные карты, договоры ипотеки? Тоже нет. В этом смысле работа банка – это монотонная работа по перевариванию транзакций.
Если сравнить это с работой в ритейле или екоме, то ситацию целиком противоположная. Что будет, если вы хотите купить зарядку, зашли на Озон, а там не работает кнопка Купить? Вы откроете вкладку Яндекс.Маркета и купите там. Вот так просто.
Что если во ВкуссВилл отвалится касса? Вы пройдете 50 метров до Пятерочки и купите там.
Если один маркетплейс сделал систему лояльности, а другой нет. Вы пойдете в первый. А если второй догнал и выпустил свою систему, которая еще выгодней? Вы пойдете во второй.
Тут важно, что в отличие от банков, в свободной торговле нет критических факторов, которые сдерживают переход клиента от одной компании к другой.
Я понимаю, что вы видите перед собой картинку стабильной клиентской базы и все в банке будет следующие 10 лет примерно также как было предыдущие 10 лет. Но представьте себе на мгновение, что бывают разные бизнес-модели, что в них клиенты по-разному себя ведут и где-то на самом деле есть жесткая конкурентная борьба, в которой действительно важна скорость поставки новых фич, чтобы привлечь аудиторию.
SpiderEkb
06.11.2023 08:54+2А зачем вы берете микросервисы и говорите, что банкам и плантформам они не нужны?
Я такого ни говорил. Я говорил что мы в полный рост используем модульность, просто не называем это микросервисами. И, возможно, это не является микросервисами в том смысле, который в этот термин вкладываете Вы.
Но все равно это модульность в которой соблюдается то, что Вы писали:
Если одни микросервис изменился, то только его одного можно зарелизить, не нужно ждать всех остальных.
Только "микросервис" заменяем на "модуль".
Ну вот пример из последнего. Есть у нас такая сущность - "дата актуализации клиента". Лежит она в одной таблице, причем, таблица эта содержит "историю изменений" - на одного клиента там несколько (может быть) дат актуализации, каждая со свое "датой установки".
В соответствии с тем, что писал выше, есть модуль внешнего ввода, через который (и только через него) вводятся изменения в эту таблицу. И есть ретривер, который возвращает последнюю установленную ДА для заданного клиента (путем поиска записи для данного клиента с максимальным значением даты установки ДА).
Используется эта сущность достаточно широко. И решили ускорить работу ретривера (или дать возможность в SQL запросах не использовать тяжелую конструкцию having max(...) group by ... а просто читать одну запись из таблицы). Т.е. сделать "витрину" - таблицу, где на каждого клиента всего одна запись - последняя установленная ДА.
Для этого делаем поставку, в которой содержится таблица-витрина, индекс к ней, исправленная версия модуля внешнего ввода (где после изменения в основной таблице дополнительно изменяется запись в витрине) и исправленная версия ретривера (который теперь работает не по исторической таблице, но по витрине). Плюс SQL скрипт первоначального заполнения витрины.
Итого - 5 объектов в поставке. Ничего более. Все остальные 100500 модулей, которые используют ДА (изменяют ее, получают ее через ретривер...) не поменялись т.к. контракты модуля внешнего ввода и ретривера не поменялись, все изменения внутри логики их работы.
Именно то, о чем вы писали:
Если одни микросервис изменился, то только его одного можно зарелизить, не нужно ждать всех остальных.
тестировать нужно только небольшие участки системы
микросервис выполняет свою небольшую бизнес-задачу
с заменой "микросервис" на "модуль" (в данном случае - два модуля).
Банки зарабатывают на процентах по кредитам и комиссии за транзакции
Если бы все было так просто...
Что будет, если личный кабинет юрлица не будет работать день?
Мы к личному кабинету вообще никакого отношения не имеем. Для нас это "внешняя система" откуда нам приходят какие-то запросы и мы отдаем требуемые данные. Там другие люди, другие платформы, другой стек.
Повторюсь - мы АБС. Автоматизированная банковская система. Мастер-система. Mission-critical система. Которая крутится 24/7 обеспечивая всю банковскую логику. Я не возьмусь даже примерно перечислить все, что там работает. Основное - да платежи. Но даже там не так просто. Каждый платеж (а их сотни миллионов в сутки) должен пройти процедуру контроля (по многим параметрам, в т.ч. а не уходят ли деньги тому, кому не надо - злодею какому?). Там десяток, если не больше, проверок по результатам которых выносится решение пропустить платеж или отправить на ручной контроль в финмон с указанием что вызвало подозрения.
Еще есть регулярная отчетность всякая - в налоговую и прочие органы.
Если клиентские данные. Есть списки росфина со всякими террористами-экстремистами которые мы регулярно получаем, раскладываем по своей БД и сравниваем своих клиентов на совпадения с этими списками.
Есть еще много бог знает чего - тарифы, лимиты, зарплатные проекты, пластиковые карты, процессинг...
Есть, например, "рассылка уведомлений клиентам". Запускается каждый день, проверяет клиентов по разным параметрам (например, на предмет истекшего или скоро истекающего срока действия ДУЛ - документа, удостоверяющего личность).
Есть отчеты в налоговую - открыл клиент счет - данные в налоговую. Накопилась на счетах сумма, превышающая необлагаемый порог - данные в налоговую. И попробуй не отправь... Быстро настучат по голове.
А еще есть "закрытие опердня" - это ежедневное сведение баланса за день и переход на следующий день.
Там очень много чего крутится. Сколько потеряет ОЗОН, если я не смогу купить зарядку? А стоимость часа простоя АБС исчисляется суммами с 6-7 нулями только прямых финансовых убытков, не считая репутационных и штрафов от регулятора (время недоступности mission critical систем нормируется минутами) вплоть до лишения лицензии "за неисполнение обязательств перед клиентами".
Очень примерные оценки объемов системы (реально, думаю, больше)
К АБС подключено более 60 банковских систем,
обеспечивающих работу различных бизнес направлений.
Большинство фронт приложений используют АБС,
как основной источник информации и функциональности.АБС это:
27 тыс. программных объектов
15 тыс. таблиц и индексов базы данных
Более 150 программных комплексов
Занимает более 30 Терабайт дискового пространства
В день изменяется более 1,5 Терабайт информации в БД
За день выполняется более 100 млн. бизнес операций
Одновременно обслуживается более 10 тыс. процессов
За год происходит более 1100 изменений в алгоритмах программЕжедневно в АБС выполняется процедура
закрытия банковского дня (EOD), в которой выполняется
обслуживание всех без исключения сделок и бизнес сущностей.В процедуре закрытия дня производится
более 500 миллионов изменений в БД,
при этом eё длительность составляет около 4 часов.Тут важно, что в отличие от банков, в свободной торговле нет критических факторов, которые сдерживают переход клиента от одной компании к другой
Среди банков также ест конкуренция. И каждый банк борется за расширение клиентской базы. И клиенты могут точно также уходить (или не приходить) если работа банка им не нравится.
Но любой банк еще находится под неусыпным контролем регулятора (ЦБ). Что будет если ОЗОН продаст зарядку Бин Ладену? Да ничего. А банку за это устроят такую "веселую жизнь" что мало не покажется (если платеж уйдет куда-то, куда не надо - "содействие финансированию терроризма" - это достаточно серьезно так-то...)
в которой действительно важна скорость поставки новых фич, чтобы привлечь аудиторию
А для банка важна стабильность и устойчивость работы. Падение новой фичи на проме может вызвать некорректную работу того, что с ней связано. Что приведет к нарушению законодательства, требований регулятора со всеми вытекающими последствиями.
Любая фича внедряется только после длительного тестирования - компонентное, бизнес, нагрузочное, интеграционное, техтест на прелайве... Внедрение каждой поставки проводится только при наличии плана отката на случай если что-то пойдет не так.
Как пример. Несколько лет назад был инцидент когда в результате необнаруженного на тестах дефекта один из модулей в период пиковой нагрузки начал дико тормозить. Что привело к задержкам всего, что с этим модулем было связано (того, что ожидало результатов его работы). В результате миллионы клиентов по всей стране не могли расплатиться картами банка - "нет ответа от банка" в течении полутора-двух часов. Нигде. Ни на ОЗОНЕ, ни в Пятерочке, нигде. Пока дежурная смена не выявила проблему и не откатила (или там WA решение нашли - не помню уже). Банку это очень дорого тогда обошлось... Это вам не зависшая касса в одном магазине. Это в масштабах станы инцидент.
По серьезным дефектам промсреды всегда собирается "комиссия по инцидентам", разбирает причины, делает выводы.
Так что банк - это очень непросто. И здесь сократить срок внедрения новой фичи методом "херак-херак и в продакшн", пусть криво-косо, лишь бы вперед конкурентов, не проходит. Тут все должно быть на 146% стабильно и надежно. В первую, вторую, треть. и далее очередь. И только потом уже TTM и скорость вкатывания фич. А модульность нужна для повышения устойчивости и безопасности - любые изменения должны быть локализованы и любое изменение можно быстро откатить.
Так что везде свои тараканы. И везде свои подходы для достижения своих задач.
AlexanderByndyu Автор
06.11.2023 08:54-1Это длинное подтверждение того, что у вас бизнес-модель отличается. Поэтому неясно зачем вам микросервисы. У вас наверняка никто и не следить за уменьшением времени time2market.
А на счет того, откуда у банка деньги, рекомендую посмотреть отчетность банков, она открытая. Основная статья дохода – кредиты. Вторая – оплата за транзакции. Остальное по сравнению с этим просто мелочи.
В целом, у меня есть хороший знакомый, директор двух филиалов большого банка в Москве. Он смотрит на продажи в банке сильно иначе, чем вы описали. Главное – удержание крупных клиентов, а на них влияет, к сожалению, для нас айтишников, не то, как работает приложение, а условия, на которых большой бизнес будет держать деньги в банке. Только если условия одинаковые, то уже спрашивают у бухглатера, какая система ближе его сердечку, но до этого доходит почти никогда.
SpiderEkb
06.11.2023 08:54+2Это длинное подтверждение того, что у вас бизнес-модель отличается. Поэтому неясно зачем вам микросервисы. У вас наверняка никто и не следить за уменьшением времени time2market.
Ну и где я говорил что нам нужны микросервисы?
Я говорил о том, что нам нужны те свойства, которые Вы декларируете как преимущества микросервисов перед монолитом:
Если одни
микросервисмодуль изменился, то только его одного можно зарелизить, не нужно ждать всех остальных.тестировать нужно только небольшие участки системы
микросервисмодуль выполняет свою небольшую бизнес-задачуЗдесь я заменил используемый вами термин "микросервис" на используемый у нас "модуль". Но принцип от этого не меняется. И оно ни в коей мере не является монолитом.
Да, у нас другие приоритеты - во главе угла стоит надежность, а не TTM. Но достигается эта цель теми же способами, что и у вас - модульность.
Вы запускаете микросервисы в отдельном контейнере, у нас все работает в отдельных независимых заданиях (job). Каждое задание изолировано от остальных. Его (при необходимости) можно принудительно завершить (системная команда ENDJOB) извне. Каждое задание имеет свой отдельный joblog (который автоматически ведется системой). При завершении задания система автоматически освобождает все выделенные в рамках него ресурсы (память, открытее файлы и т.п.). Вплоть до временных объектов (у каждого задания автоматически создается и потом удаляется специальная библиотека QTEMP в которой можно создавать любые временные объекты и знать что все это автоматически удалится по завершению задания).
Любая программа может быть запущена как в текущем задании командой CALL (если мы в терминале) или в отдельном фоновом командой SBMJOB (submit job).
Как видите, общих принципов очень много. Хотя и цели разные.
И микросервисы, как вы их понимаете и используете не являются единственно возможным способом реализации.
А на счет того, откуда у банка деньги, рекомендую посмотреть отчетность банков, она открытая. Основная статья дохода – кредиты. Вторая – оплата за транзакции. Остальное по сравнению с этим просто мелочи.
Я не о том, откуда у банка деньги. Я о том, что банк работает в намного более жестких условиях по сравнению с ритейлом тем же. Более высокие требования к надежности и доступности. Более жесткий контроль со стороны регулятора. Жесткие санкции за нарушения правил - ну не закроют магазин если он там что-то нарушил. А банк запросто могут лишить лицензии (сколько банков "вычистили" за последние годы).
Вот скажите - в ритейле получают списки росфина (подозреваемые в экстремизме, подозреваемые в пособничеству терроризму, подозреваемые в распространении оружия массового уничтожения, список решений суда, список ООН...)? Должен ритейл эти списка хранить, проверять своих клиентов на совпадение с субъектами списков (а у нас это 50млн клиентов и несколько сотен тысяч субъектов и надо всех со всеми сравнивать каждый раз как пришла новая версия списка - примерно раз в неделю), формировать стоплисты, проверять каждый платеж (отправитель/получатель) на совпадение со списком? А банк обязан это все делать. А еще обязан отслеживать всякие подозрительные операции типа обнала. А еще обязан кучу всяких отчетов в разные органы предоставлять...
И все это помимо основной деятельности - проведение платежей. И все это ложится на нас - Автоматизированную Банковскую Систему.
Главное – удержание крупных клиентов, а на них влияет, к сожалению, для нас айтишников, не то, как работает приложение, а условия, на которых большой бизнес будет держать деньги в банке.
Что толку в прекрасном приложении, если центральная система работает так, что нарушаются требования регулятора? Когда приходит внеочередная проверка ЦБ, находит нарушения и выносит решение о приостановлении действия лицензии? Тогда все клиенты автоматом пойдут в другие банки.
Мы с вами на разных уровнях работаем. Вы макияж делаете красивый, а мы заботимся о том, чтобы это макияж не стал последним, посмертным.
То, что мы делаем, не видно снаружи. Но когда где-то там придумывают очередную "креативную фичу", то они реализуют ее или на тех интерфейсах что уже есть, или приходят к нам и говорят "нам нужно от вас..." а мы уже придумываем как это реализовать максимально эффективно - чтобы и там получили желаемое и у нас система не легла под нагрузкой а продолжала выполнять основные свои задачи. И мы не можем "купить еще один сервер в облаке" - все наши данные по требованиям ИБ обязаны хранится во внутреннем периметре (все сервера жестко изолированы от внешнего мира, доступ к ним есть у очень ограниченно круга лиц). Поэтому вынуждены думать и о предельной эффективности всех наших решений тоже. Потому что любые фичи - они хороши и работают ровно до тех пор, пока работает банк.
AlexanderByndyu Автор
06.11.2023 08:54Спасибо за ваши развернутые комментарии. Многое для себя из них почерпнул. Надеюсь, что наша дискуссия и вам что-то дала.
Уверен, что если вы соберете все свои комментарии, то получится отличная статья на тему того, как устроен в банке модульный монолит, почему именно так и какие к нему предъявляются требования. Тем, кто работает в банке, и любителям этой темы точно понравится.
SpiderEkb
06.11.2023 08:54+1В целом - да.
Мы в разных условиях работает и на разных направлениях. Вы создаете фичи, мы автоматизируем внутренние бизнес-процессы.
Разные задачи, разные требования, разные приоритеты, разные подходы.
И уже если вспомнить ТТМ, то у нас тоже бывает т.н. "нормативка" - процесс должен быть запущен к определенному сроку. И тут опять все жестко - "с такого-то дня банк должен предоставлять такой-то отчет туда-то". Ключевое слово - "должен". Не начнет предоставлять - нарушение требований законодательства или регулятора. Может повлечь какие-то санкции (штраф - ну почти наверняка).
Так что тоже бывает, что уж...
Чего, на мой взгляд, не хватает в вашей статье - четкой формулировки преимуществ микросервисов. Ибо те свой свойства, которые вы указали (извините, опять повторюсь)
Если одни микросервис изменился, то только его одного можно зарелизить, не нужно ждать всех остальных.
тестировать нужно только небольшие участки системы
микросервис выполняет свою небольшую бизнес-задачу
точно также реализуются и в "модульном монолите" (как вы изволили выразится).
И даже изолированность (контейнеризация) реализуется у нас на уровне заданий, которые полностью изолированы друг от друга. Да, можно реализовать передачу данных через очереди (системные объекты типа очередь на нашей платформе), сокеты (в т.ч. unix-сокеты) или пайпы. Можно даже специальным образом указатели передавать. Но случайно одно задание к другому в память не залезет никак. И никак на него не повлияет.
И что остается в итоге? Масштабируемость? Но не все процессы допускают облачные решения. Это раз. Кластеризация серверов (у нас вообще-то не один физический сервер) уже существует. Современные технические решения (я рассказывал про Power10) позволяют делать это еще проще и прозрачнее для потребителя...
Тогда что? Конкретная реализация? Но это не концепция и не принцип, это просто один из способов получения тех преимуществ, которые заложены в концепции.
Так что хотелось бы более развернуто посмотреть сравнение "модульного монолита" и микросервисов. Все плюсы и все минусы.
dph
06.11.2023 08:54Хм, гораздо больше шансов, что я уйду с Озона на ЯМ просто потому, что Озон где-то потерял мои деньги (стандартная ситуация для микросервисов) или вообще плохо оптимизировал поиск (так как увлекся микросервисами и все ресурсы потратил на написание своего драйвера к кафке, а не на реализацию нормального продукта).
А так как микросервисы, в среднем, менее надежны, нежели монолит - то и шансов у "микросервисного" Озона упасть гораздо больше, чем у "монолитного".
Микросервисы вообще не про надежность, не про гибкость и не про масштабируемость.SpiderEkb
06.11.2023 08:54-1Хм, гораздо больше шансов, что я уйду с Озона на ЯМ просто потому, что Озон где-то потерял мои деньги
Пожалуй, да. Подумал - как выбираю где купить? Понял что зависит от
репутации магазина
наличие нужного товара и цены на него
скорость и удобство доставки - когда привезут, куда привезут...
Аналогично с банками - надежность, ассортимент и стоимость предлагаемых услуг.
Базовый функционал давно уже у всех плюс-минус одинаковый. А наличие каких-то фич точно не стоит на первом месте при выборе. И точно что если кто-то какую-то фичу ввел раньше - это не повод бежать туда с "насиженного места" если все остальное тут устраивает. Ну появится оно чуть позже...
SpiderEkb
Вот сколько статей про микросервисы vs монолит и ни одного реального примера настоящего монолитного монолита enterprise уровня.
Честно говоря, не могу себе такого представить даже...
Работая шесть лет в команде ядровых функций АБС (то, что крутится на центральнызх серверах) в банке из топ-10, ни разу не слышал про "микросервисы". Но то, как это организовано тут, монолитом никак не назвать. Скорее это ближе к старой (концепция, если не ошибаюсь, разработана еще в 70-х годах прошлого столетия) модели акторов - программных модулей, каждый из которых вызывается для выполнения конкретного действия или при возникновении каких-то условий и где один актор может порождать цепочку других.
Как пример - общение АБС с внешними системами через очереди. Есть некий "монитор очереди", который отслеживается появление в ней новых сообщений. Каждое сообщение имеет заголовок в котором содержится его идентификатор (тип сообщения). По этому типу монитор в своих настроечных таблицах находит модуль, отвечающий за обработку данного типа сообщения и запускает его, передавая в качестве параметра полученное сообщение.
Т.о. при появлении нового типа сообщения нужно просто написать модуль (программу) для его обработки и зарегистрировать его в настроечных таблицах монитора.
Второй пример - таблицы. На чтение таблиц нет ограничений - как хотим, так и читаем. Но на изменение есть жесткие требования - только через т.н. "модуль внешнего ввода" (за исключением всяких рабочих таблиц для временного хранения какой-то промежуточной информации, логов и т.п.). Фактически там три модуля - "внешний ввод", "валидатор" и "модификатор" (подробности почему и зачем именно так расписывать долго, так что остановимся на этом). В модуль внешнего ввода передается структура записи. Далее вызывается "валидатор", который проверяет корректность и непротиворечивость данных и затем собственно "модификатор", который уже вносит собственно изменения в таблицу и реализует всю связанную с этим процессом логику (а она может быть достаточно сложной - могут быть какие-то связанные таблицы, специальные действия и т.п.).
Появился новый бизнес-процесс? Пишется и внедряется соответствующий модуль. Изменилась логика процесса? Модифицируем нужный модуль.
Этот подход реализован уже очень давно (ну лет 20-ти как минимум).
Т.е. все это ну никак не монолит. Но и микросервисами никто никогда не называл.
Все связи между модулями исключительно на уровне ABI - запаковывать-распаковывать джейсоны тут слишком большая роскошь как по времени, так и по ресурсам. Да и в условиях фиксированных и согласованных для каждого модуля контрактов это избыточно.
Увы, но, например для банка это не работает. Никто не даст хранить mission critical данные вне внутреннего периметра (центральные сервера вообще изолированы от внешнего мира - никакого прямого доступе к БД нет, только конкретные авторизированные запросы через очереди или ESB шину). Кроме того, облако не обеспечит нужного быстродействия и надежности на тех объемах данных, которые постоянно обрабатываются.
Сейчас уже есть технические решения по масштабированию серверов в очень широких пределах. Последнее поколение процессоров IBM Power10 содержит непосредственно на кристалле контроллер высокоскоростной шины, позволяющий "стыковать" несколько серверов непосредственно на уроне процессоров так, что они могут совместно использовать все ресурсы. К сожалению, всех технических подробностей не знаю, информация из обзорного доклада на последней внутренней конференции разработчиков.
А вот это вообще напоминает анекдот про одну шапку или десять из одного и того же куска ткани... Если вы запускаете 1, 10, 100 виртуальных контейнеров на одном сервере, то с запуском каждого нового контейнере будет пропорционально падать производительность всех остальных.
На фоне всего этого "микросервисы" воспринимаются как некий хайп. Старая конфетка в новой обертке. Это хорошая и и правильная идея с большим потенциалом, но все это давно известно и используется намного дольше, чем об это стали говорить на каждом углу и убеждать (самих себя?) как это хорошо и лучше чем монолит.
AlexanderByndyu Автор
Спасибо, что поделились опытом из своей области. У меня опыт в основном из ритейла, екома и логистики. Там микросервисы очень активно используются.
Вариант, который вы описали, очень похож на микросервисы. Не могу точно сказать дельту "по фотографии", то выглядит похоже.
Речь не именно про облака, а про то, что железо можно наращивать по мере роста нагрузки. Уверен, что у вас внутри банка такая штука должна быть тоже реализована. Плюс от микросервиса в том, что у него четкие границы, вроде ваших акторов. Если одни актор (а он небольшой, судя по описанию) будет перегружен, то только для него вы нарастите железо.
Это вопрос в деньгах. Чем больше и круче вертикально растим, тем дороже это стоит, причем дороже нелинейно. Дешевле купить кучу мелких машин, чем строить и обслуживать супер-крутой компьютер.
Тут связано с моим предыдущим комментарием. Вы смотрите на железо, как на что-то целостное, я смотрю на него, как на сервис. Другими словами, можно докупать дешевые мощности и наших плодить копии микросервисов.
SpiderEkb
А микросервисы очень похожи на акторы, которые придумали очень давно, но вот сейчас кто-то вытащил эту идею и пропагандирует ее как нечто "революционно новое".
Увы, но так это не работает. Наращивание железа всегда связано с проблемами скорости обмена информацией. Для высоконагруженных систем это проблема стоит очень остро. Если у вас микросервис работает (выполняет свою задачу) 1нс, но чтобы его вызвать, передать входные данные и получить ответ уходит 5нс - это уже непозволительная роскошь.
Я упомянул Power10 именно в этом ключе. Там ребятам удалось эту проблему решить. Повторюсь, я не сильно ориентируюсь в современном железе, да и доклад был в значительной степени обзорным, но в целом это выглядит так:
Есть некая шина с контроллером непосредственно на кристалле (т.е. скорости обмена там космические) позволяющая объединять не только сами процессора, но и все ресурсы - память, диски и т.п.
Допустим, есть машинка - 2 процессора, терабайт оперативки, сто терабайт диска. Не хватает? Покупаем еще одну такую же, сцепляем ее "космической шиной" с первой и получаем машину с четырьмя процессорами, двумя терабайтами оперативки и двумстами терабайтами диска. Все это поддерживается как на уровне железа, так и на уровне ОС - "снаружи" все это продолжает быть одним сервером (ну как реализованы многопроцессорные сервера, но тут они просто в разных корпусах).
Емкость шины там называлась не менее космической - даже не сотни, тысячи "слотов". Но массовых решений такого уровня на рынке пока нет.
Я исхожу из наших головных болей - прежде всего производительность. Никому тут не нужны микросервисы, для которых передача входных данных и получение ответа займет больше времени, чем обработка им информации. поэтому да. Пока мы работаем на предыдущем поколении серверов (Power9), мы работаем на кластере из нескольких машин. на общей шине, но все равно это кластер.
Но я, собственно, главным образом про то, что концепция микросервисов не революционна. Это старая модель, он давно разработана и описана. Это раз.
Второе - я не могу себе представить реализацию enterprise монолита, где одновременно работают тысячи (если не десятки тысяч) достаточно независимых бизнес-процессов. А enterprise это именно вот такое вот. Не один процесс. Много. И все параллельно работают. И в каждом своя логика. И про этом по данным они пересекаются друг с другом. А могут и по логике частично пересекаться. Как это засунуть в монолит, коим постоянно пугают маленьких детей ("не ходите дети монолит писать..."). На мой взгляд это какая-то страшилка чтобы показать "революционность" микросервисов (при том, что enterprise давно уже так живет и никому ничего при этом не доказывает - там все это воспринимается как само собой разумеющееся).
AlexanderByndyu Автор
Судя по тому, что вы написали, вы никогда не работали с микросервисами в проде. Тогда странно, что вы убираете десяток лет развития этой темы в IT и утверждаете, что это всё это было. Микросевирсов раньше в принципе не могло быть, потому что не было IaC. Только благодаря развитию этого направления создание архитектуры на микросервисах стало возможно.
Прежде, чем утверждать, что микросервисы – это пропаганда и хайп, рекомендую вам, как инженеру, изучить этот вопрос.
Я уверен, что это отличная технология, но тут есть вопрос стоимости. Если я могу насоздавать сотни инстансов микросервиса за Х рублей и потерять при этом 10% на увеличении трафика, а на Power10 мне придется заплатить 10Х руб. и потерять только 1%, то это только вопрос бизнес-целей и возможностей. Я согласен, что можно растить вертикально, если для этого есть потребность бизнеса и средства.
Я с этим работаю ежедневно. Скажите, если я как-то могу вам помочь это представить.
А "так" это как? Вы про модель акторов, которые соединены шиной?
SpiderEkb
Тут вопрос не в конкретной реализации, а в концепции, идее. Как ее реализовать в каждом конкретном случае - это уже вопрос цены и технических возможностей.
Я говорю о том, что сейчас есть тенденция брать старые идеи, оборачивать из красивыми бантиками и выдавать за нечто такое "чего никогда не было".
Вот были когда-то велосипеды с педалями на переднем колесе. Потом придумали цепной привод. Потом переключение скоростей, планетарные переключатели, привод не цепью, но ремнем. Но сам базовый принцип велосипеда от этого мало меняется.
Так и здесь. Сама идей перехода от одной программы-монолита к набору модулей, каждый из которых выполняет свою часть работы и каждый из которых может работать как последовательно, так и параллельно с другими существует уже давно. Это велосипед. А уж как вы реализуете привод - цепью, ремнем, традиционное переключение скоростей, планетарное - это уже вопрос вторичный.
По-моему, монолиты - это первое что приходит в голову человеку, пришедшему из "мира персоналок". Он мыслит программой, выполняющей всю работу. Те же, кто работал на мейнфреймах (будь то System/390 или БЭСМ-6) мыслят сразу иначе - там речь идет о множестве параллельно работающих заданий (job), каждое из которых выполняет какую-то функцию и они могут обмениваться между собой информацией и результатами работы - там все именно так устроено и именно там и возникла модель акторов и ее математическое обоснование. Там никому в голову не приходит запихнуть всю работу в одно задание. А дальше уже лишь вопрос реализации в рамках доступных технологических возможностей.
Модульно. Каждый модуль выполняет свою конкретную задачу. Обработка сообщения конкретного типа, запись в конкретную таблицу со всеми необходимыми сопутствующими действиями и т.п. Т.е. тот самый подход, что Вы описываете - ни одно изменение ни в одном процессе не затрагивает все системы целиком за рамками данного процесса. Добавление нового процесса не требует пересборки всей системы, достаточно интеграции нового модуля. Как именно вы это реализуете уже зависит от того, что у вас есть в наличии. Важен принцип построения и работы системы.
И если углубляться в дебри терминологии, то, что вы называете "микросервисами" суть конкретный способ реализации общей концепции - можете назвать ее "модульной", "микромодульной", как угодно. Но реализована она может быть многими способами и "микросервисы" в том виде, как они пропагандируются, всего лишь один из них (дальше уже можно сравнивать конкретные реализации).
Удивитесь ли Вы, если скажу, что даже операционные системы могут быть построены по похожему принципу? Т.н. "микроядерные" ОС где все разделено на изолированные модули (включая все драйвера устройств, а собственно ядро (микроядро) есть очень простой, компактный модуль, который является связующим звеном для всех остальных.
Сравнивать "микросервисы", как частный способ реализации модульности с "монолитом" как концепцией "все-в-одном"... Корректно ли это? Это как сравнить "яблоко" (конкретный вид фрукта) с "овощем" (овощем вообще, любым овощем).
AlexanderByndyu Автор
Почему только сейчас? Человечество таким образом развивается, это наш путь. Возьмите научную работу, она же обязательно должна быть основана на предыдущих идеях, в которые вы добавляете какой-то "бантик". По-моему это хороший способ всем нам маленькими шагами пытаться справиться с нарастающей сложностью.
Кто-то так делает? Не замечал. Покидайте ссылок, интересно будет посмотреть.
Так и есть, но есть нюанс. Он заключается в том, что пока у концепции нет конкретного названия ее сложно развивать всем сообществом. Подход, который вам нравится и к которому вы привыкли, обвесили парой "бантиков", он приобрел границы и ценность, а благодаря этому его стало возможно развивать. В этом я вижу большую ценность, поэтому буду и дальше использовать именно термин "микросервисы". Таким образом я буду делать вклад в общую копилку, где и разработчики и бизнес смогу найти для себя возможности для роста. А, возможно, кто-то на этой основе добавит еще "бантик"-улучшение, назовет это убер-сервис и оно зайдет и будет помогать бизнесу расти быстрее, почему нет?
SpiderEkb
Единственный риск тут - кому-то может показаться, что есть всего два варианта - монолит и вот такая вот конкретная реализация. Что в общем случае не совсем верно.
И да, судя по всему, у нас не микросервисы ни разу по ряду признаков. Но при этом и не монолит совсем (по другому ряду признаков).
Но в общем и целом все это так или иначе основано (принципиально и концептуально) на модели акторов (считайте что микросервис - это такая реализация актора). А дальше уже технологические особенности.
В целом - да. Но есть моменты когда появляется новая концепция (как когда-то появилась концепция механизации процесса вычислений), а потом уже начинаются вариации на это тему и усовершенствования с появлением новых технологических возможностей.
murkin-kot
Общая идея за микросервисами - асинхронность и распределённость. Это, разумеется, не бином Ньютона. Такой подход появился сразу, как только появились технические возможности для распределения вычислений (то есть тысячи лет назад, когда люди научились независимо делать каждый свою задачу). Но сегодня явление, под названием "мода", заставляет раскручивать именно узко понимаемую реализацию древнего подхода. Приход массовости (вслед за рекламой в следствии моды) привёл за собой кучу посредственностей, которые воспринимают рекламу как истину и не думают о корнях явления. Поэтому в любом (подавляющем большинстве) околорекламных описаний явления вы найдёте исключительно "микросервисы", перекладывающие JSON-ы из докера в очередной кубернетес. Таков рекламный шаблон.
Поэтому не стоит удивляться "хайпу" - чем больше людей вовлечено в модную тему, тем примитивнее будет описание их работы. Все участники большого коллектива не могут быть мыслителями, что статьи, подобные данной выше, почти каждый раз весьма уверенно доказывают.
AlexanderByndyu Автор
А что если мы в компании уже много лет используем микросервисы и бизнес, благодаря этому получает гибкость и зарабатывает больше? Я понимаю, что есть разные люди и часть может просто взять "обертку" микросервисов и делать абы что, но это разве означает, что микросервисы всегда используются для хайпа? Для меня странно, что вы без разбора смыли всех любителей микросервисов выгребную яму.
murkin-kot
Не всех. Вы выше сами признали - таков путь, так устроено человечество. И этот путь можно охарактеризовать одним словом - реклама. Так вот в массовой рекламе как раз и нарисована та самая картинка, которую я всячески критикую. То есть неэффективный во многих областях шаблон подаётся как идеальное решение.
И причина указана выше - массовое внедрение всегда предполагает снижение уровня интеллектуальных усилий. Это означает, в том числе, снижение порога для входа в данную тему. И на сколько этот порог понижен, мы и видим в рекламе.
Ещё раз - я критикую безумно гипертрофированную подачу одной из имеющихся технологий, на фоне огромного многообразия зачастую намного более полезных технологий.