▶️ В мире разработки программного обеспечения существуют два основных подхода: микросервисная и монолитная архитектуры. Оба подхода имеют свои преимущества и недостатки, а каждый проект имеет свои уникальные требования, ограничения и цели.

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

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

Под монолитом, с вашего позволения, я буду подразумевать скорее сервис-ориентированный подход, но с единой кодовой базой, так как описанный в книгах монолит действительно мертв. Процитирую примечение из статьи Мартина Фаулера — https://martinfowler.com/articles/microservice-trade-offs.html

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

🛠️ Удобство разработки:

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

💬💭 Микросервисная архитектура придумана не разработчиками/архитекторами/админами, а эффективными менеджерами и бизнесом, так как больше преимуществ это дает заказчику, позволяя ему нанимать любых колхозников, прошедших курсы разработки на любых языках. Также этот подход расхалаживает инженеров, позволяя им писать быстро и хуево, не обрабатывая ошибки и исключения. Все это вырастает в плюсы с точки зрения бизнеса и управления, но, как мне кажется, имеет обратную сторону, понижая инженерную культуру, выработку высококачественных стандартов и профессиональное развитие, когда хочется дотянуться до настоящих гуру. Также это приводит к неибзежному росту техническго долга, потому что релизы новых фичей становятся быстрыми и частыми, а как показывает практика бизнес не готов давать время на рефакторинг и устранение технического долга, несмотря на то как это радужно рисуется в книгах.

🏢 Монолитная архитектура может быть сложнее в разработке из-за большого количества кода в едином репозитории. Однако, это удобнее для небольших проектов, когда вся функциональность тесно связана. Особенно классно на монолитную архитектуру ложится подход Trunk-based development (TBD), ссылку на который я уже давал у себя в канале — https://trunkbaseddevelopment.com/. Выглядит вообще сказочно 😊

💬💭 Тут вырастают требования к разработчикам и инженерам, появляются высокие стандарты, так как без них вырастает вероятность накосячить при разработке. Развивается инженерная культура внутри команд, вырастает качество и скорость обучаемости людей вовлеченных в процесс. Возникают конечно опасения и риски, что скорость разработки может упасть, несмотря на то как бы это круто и олдскульно не было. Но у меня есть убеждение, что с этим вместе вырастет качество разработки, если добавить к этому еще правильные Contnuous integration/Continuous Delivery/Continuous Deployment процессы, тесты (smoke/unit, функциональные, интеграционные), а также высокие стандарты процесса разработки (версионирование методов и обратная совместимость + code of conduct) и ревью — минимизуруют вероятность поломки основной ветки.

🔧 Гибкость и масштабируемость:

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

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

💬💭 Хочется поднять вопрос про динамическую вертикальную масштабируемость для монолитной архитектуры, которую, насколько я знаю уже давно поддерживают VMware/Hyper-V, но не уверен, что подобный подход реализуем у облачных провайдеров. То есть мы можем запускать наши приложения нативно без использования контейнеров и масштарибировать вертикально при росте/снижении нагрузки. То есть контейнеры можно вообще выкинуть из эксплуатации, но я оставляю открытым вопрос, что контейнеры позволяют сохранить идентичность окружения для эксплуатации и разработки. В принципе у меня нет никаких консернов по отношению к контейнерам, за исключением случаев, когда высоконагруженное приложение активно работает с файловой системой.

🔒 Надежность:

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

🏢 Монолитная архитектура может быть более надежной, так как вся функциональность находится в одной кодовой базе и отказ одного модуля не приведет к недоступности всей системы. Следует уточнить, что в моем понимании монолит состоит из множества модулей.

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

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