Истина, как обычно, где-то посередине. Также этот автор известен флеймогонными текстами на Хабре, так что я бы его слова делил натрое как минимум: похоже, что ему хайп важнее объективности.

Моя команда сейчас работает над монолитом из 500к LOC, без учёта комментариев и пустых строк. Если бы не применение методологий типа clean code, SOLID и DDD — он бы давно был неюзабелен, мы бы пилили его на микросервисы, внедряли бы k8s, раздули бы штат и сегодня благополучно бы разорились на счетах за AWS и зарплатах.

Но справедливости ради в стартапах, которые я консультирую, я сам рекомендую закрывать глаза на качество кода до момента подтверждения сходимости юнит-экономики.

Вот гугль наш замечательный до сих пор при переводе японских текстов, заголовков, переводит гарем (жанр) как Гарлем.

не уверен в том, что solid и ddd противостоит микросервисам. У нас был кейс распределения работы между участникам удаленной команды, но что бы доступ у каждого участника был только к части кода, а не ко всему проекту. С микросервисами и сервис мэшем можно поднять окружение, в котором вся огромная система будет на амазоне, а девелопер может гонять интеграции на своей машине.
Но, понятно, что дъявол в деталях и все зависит.

Ну и есть такие проекты, где говнокодить нельзя. iot, например. Или то, что у меня :)

по-моему в IoT только и делают что говнокодят

О, про говнокод в IoT у меня есть охотничья история про людей, лазающих по столбам в далёком алтайском селе в -40, провода программаторов, ломающимся как спички на этом морозе, и вторая серия, через два месяца, с тонированной Нивой, обвешанной антеннами и людьми с ноутами внутри, медленно катающейся по этому же селу)

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

у нас чувак иот для контроля давления в котлах писал. говнокодил, контроля версий не было и тд. после того как пару раз долбануло, его уволили )
Поэтому мне показалось что оно так )

Зачем там IoT?

Это были умные счётчики электричества, в прошивке которых, как можно понять, были обнаружены баги, которые не мог парировать бэкенд)

Вдобавок, мороз в -40 там конечно можно найти - один раз за всю зиму. Так можно было и подождать.

>это были шибко умные счётчики электричества

fixed

Или даже - шибко жадная Алтайэнерго, или как его там.

Это же охотничья история, я для красного словца прибавил, конечно)

ну все так. но распиливать монолит можно по разным причинам. одну  из них я озвучил - ограниченный доступ к кодовой базе.
Ну условно, фронты не имеют доступ к бэку. у фронтов есть свой backend for frontend, есть отдельная репа с типами и json-schemами.

Можно без этого и так чтоб все в одну репу фигачили? можно. Жили же как-то в php даже до smarty еще, не говоря про всякие ларавели.
Результат у гитлаба можно увидеть, где руби вперемешку с фронтом.

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

Фронтенд и бэкенд традиционно в разных репо лежат (кроме случаев недальновидных попыток внедрения монореп, biiiig mistake). Под распилом я имею в виду как раз разбиение бэкенда на отдельные компоненты, связанные через service mesh или ещё как-то.

я просто для наглядности привел пример.
с бэкендом пример сложнее ) но еще раз - необходимость изолировать код вполне может быть причиной распила на микросервисы. или требование к повышению производительности узкого места, переписыванием его с ноды на go. И это требование вполне может существовать еще до продуктового запуска. т.к. нагрузочных тестов в стартапах никто не делает, с удивлением можно обноружить, что 10 человек увеличивают время ответа всей системы до 20 секунд, например, хотя при ручном тестировании все было ок.
Не, можно, конечно, закинуть побольше денег на амазон. Если они есть. Но если они есть - о чем тогда спор )))

Согласен про вынесение нагрузки, но это не вполне про микросервисный паттерн, это скорее инфраструктурное решение. Бизнес логика в монолите, а всякие авторизации, обработка событий, рассылка пушей и т.п. - в отдельных модулях.

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

Вот, всем книжка )
https://t.me/techskill/1887