Я PHP-разработчик с восьмилетним коммерческим опытом. Долгое время я не видел смысла в микросервисах — пока не перешёл на Python и не столкнулся с его архитектурными особенностями.

С чего всё началось?

В коммерческой разработке я уже восемь лет. Для меня язык программирования — это инструмент и не более. И переход с PHP на Python не вызвал трудностей. Мои знания ООП и алгоритмов обеспечили необходимую базу для коммерческой разработки.

Однако в первые месяцы я не понимал внутренних механизмов Python. Я писал код, руководствуясь общими принципами программирования.

Внезапная проблема

Однажды я заметил, что мой сервис зависает при загрузке файла в S3. Оказалось, что причина в синхронной библиотеке Python. Это удивило меня как PHP-разработчика. Ведь в PHP каждый запрос пользователя запускает отдельный экземпляр приложения. Код выполняется последовательно, и приложение возвращает ответ. Это делает PHP-приложения медленными, но надёжными: один запрос равен одному потоку.

В Python всё иначе. Программа разделяет один поток на всех пользователей. Если кто-то тормозит систему, то и у остальных всё останавливается. Таким образом, из-за одного сложного запроса сотни других пользователей могут наблюдать бесконечную загрузку.

И многие библиотеки Python, особенно HTTP, изначально синхронные. Это создаёт проблему при работе с внешними API и загрузками файлов в облако, что может повлиять на всё приложение. Именно это произошло и у меня.

Время для серьёзного разговора

Меня заинтересовала проблема, и я обсудил её с чатом GPT. Он объяснил всё, что я описал выше. Затем я поговорил с нашим Python-разработчиком. Он тоже подтвердил, что у Python есть своя куча недостатков.

И вот тогда я понял, почему микросервисы стали так популярны одновременно с Python.

В приложении, работающем в одном потоке, всегда есть риск "зависания" из-за любой проблемы. Такое приложение лучше использовать как мостик между реальным бэкендом и API.

Здесь на сцену выходят gRPC и микросервисы. Они позволяют разделить код и создать отдельные потоки для конкретных задач. Таким образом, если зависает сервис отправки данных в облако, клиенты этого не замечают. Приложение продолжает работать, ведь зависает только один из множества микросервисов.

Так в чём же проблема?

Казалось бы, всё хорошо: проблема решена, мы сократили зависимость от одного потока, уменьшили риски зависания.

Но есть один нюанс. Микросервисы — это своего рода костыль в мире однопоточных архитектур. Их часто считают крутыми из-за масштабируемости и командной гибкости. Однако это далеко не всегда правда.

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

Сегодня молодые компании вынуждены тратить больше средств и времени на разработку и поддержку микросервисов. Всё ради модных технологий. И довольные программисты, без опыта в создании архитектуры приложений, начинают писать свои сервисы. Они множат их, пишут в функциональном стиле. А потом рассказывают на свои конференция с ванильным рафом в руке какие они молодцы. Мрак, не?

Микросервисы — это бич нашего времени

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

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

Микросервисы — это важно. Но внедряйте их разумно. Используйте их там, где они уместны. Истинная мудрость в том, чтобы выбирать инструменты с умом. Разработчику важно знать про ООП, паттерны и в целом понимать, что он делает и зачем. В итоге именно это выделяет вас как продуманного и способного разработчика.

UPD 1

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

UPD 2

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

UPD 3

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

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