Comments 12
У вашего рассказа как будто предусловие, что монолит у нас и так классный и от добра добра не ищут. Но я хотел бы, например, посмотреть на монолит, надо которым одновременно работают 40 разрабов и не знают печали. Если у вас там все настолько по солиду написано, то снимаю шляпу и признаю, что микросервисы вам не нужны.
Согласен, со многими бизнес задачами (в частности уровня предприятия) качественный монолит справится без каких либо проблем. А еще есть плюс у монолита на этапе прототипирования, а именно на этапе разработки функционального прототипа. Нескольким разработчикам вполне по силам в довольно короткие сроки построить работающий монолит (например на Java и Spring) чтобы самим посмотреть и другим показать как работают их идеи. Такой монолитный прототип можно попробовать, посмотреть на него с разных сторон, в том числе чтобы понять нужно ли выделять из него сервисы, и если нужно то какие именно, как они должны выглядеть, как ими управлять и т.д.
В целом, можно представить себе схему когда у нас есть "монолит", который состоит из кучи библиотек (вместо отдельных сервисов).
Все-таки наличие таких библиотек необходимо (с какого-то размера), чтобы команды могли независимо делать эксперименты (если нет множества разных команд с разными целями и сроками, то и микросервисы, и библиотеки не нужны особо).
Таким образом, мы уходим от сетевых задержек. Какие при этом могут быть минусы?
- необходимость возможности старта всей системы на одном сервере: если используются локальные кеши, то такое не всегда возможно
- увеличенное время сборки, но при этом вся система стартует локально (что удобно для разработчиков)
- необходимо для одного запроса для снижения задержек использовать больше cpu/памяти/сети, чем есть на одном сервере
- вроде бы в таком случаем масштабирование проще, но когда есть совсем разные разпросы, то оно не эффективно (например, один запрос требует кучу данных в памяти, а другой запрос cpu, а третий по сути аркестрирует вызовы к базам)
- при большом количестве серверов и экспериментов придется довольно часто передеплоивать все, что, как ни крути, приводит к какому-то простою серверов и потенциальным ошибкам при обновлении
Т.е. да, в каких-то областях возможно не переходить на обычные микросервисы, а еще какое-то время оставаться на библиотечных микросервисах, но это каждый раз надо смотреть по месту. И, конечно, если у вас все и так хорошо без микросервисов, то не нужно их внедрять просто чтобы были.
Если библиотека микросервисов имеет достаточный уровень абстракции, то код очередного нового модуля будет одинаков, независимо от того монолит с библиотеками это или микросервисы. В обоих случаях разработчик помечает инжектом интерфейсы и дёргает их методы
Поэтому если отдел разработки не может построить кодовую базу монолита, он испытает точно такие же трудности и с кодовой базой микросервисов
Поддерживаю утверждение, что микросервисы имеют свою (и довольно высокую) цену. На моей старой работе новый владелец настоял на том, что старую систему надо выкинуть, и написать с нуля новую, с Растом и микросервисами. Набрали команду энтузиастов Раста с хорошим опытом на других языках, владелец привел знакомых архитекторов и понеслось. Спустя год работающий прототип так и не готов, написано больше десятка микросервисов, хитрым образом взаимодействующих между собой, запускать всё это умеет ровно один человек :)
А что вы думаете о другом модном тренде, serverless (AWS Lambda, GCP Cloud Functions и т.п.)?
Почти один в один произошло и на моей прошлый работе. Разница была в том, что там были реальные проблемы с одним модулем монолита, но можно было было прекрасно вынести в отдельный сервис только этот модуль, так как он был довольно четко ограничен по функциональности и API можно было сделать очень просто.
Вместо этого CTO продавил идею "А давайте все распилим на микросервисы", хотя вся команда была против. Штат под это дело не расширили, в результате после года работы новая система так и не смогла по функциональности догнать старую, в проде работал чудовищный гибрид обоих, расходы на инфраструктуру почти удвоились.
Я работаю в Амазоне и моя команда отвечает в том числе за рендеринг информации о доставке. У нас был сервис и библиотека, которые делали одно и тоже, и мы заглушили сервис в начале этого года.
При всех плюсах этого подхода, описать боль деплоймента некоторых изменений достаточно сложно. Но самое интересное начинается когда что-то идёт не так, хотя ты ничего не менял. Мы уже полгода не можем найти причину падения доступности в одном регионе после того как одна из страниц сделала обновление зависимостей (нескольких тысяч разом).
Наиболее "круто" когда сотни микросервисов "упираются" в одну транзакционную "макробазу"... :-)
Как бы помягче выразиться…
Данная статья демонстрирует искаженное восприятие микросервисной архитектуры. И что самое страшное, что она будет воздействовать на умы молодых людей, которые только встают на путь проектирования систем. Опытным специалистам с первых же абзацев видны эти искажения.
Одно лишь это предложение много чего стоит: «Вы серьезно перегрузите стек используемых технологий, что может затруднить для клиента взаимодействие с приложением.»
Вы серьезно думаете, что клиент должен знать о стеке используемых технологий? Расскажите, пожалуйста, КАК??? можно спроектировать приложение, чтобы стек используемых технологий затруднил взаимодействие с приложением.
Приведенные примеры отсутствия преимуществ микросервисов перед монолитом - это примеры НЕПРАВИЛЬНОГО проектирования.
Мой маналииит!
Нужны ли нам микросервисы?