Коллеги, надеюсь, кто-нибудь сможет прояснить ситуацию. Делаю бэк для сайта

(вспомогательные сервисы, парсеры, немного ML), какое-то время назад начал пилить монолит, накидывал фичей, все хорошо работало, как сверху решили, что микросервисы это то, что нужно.
И началось. Один репозиторий на 10 разных, микросервисы, CI/CD под каждый, digital ocean, k8s, пришлось растаскивать этот монолит. Из-за микросервисов теперь нужен брокер сообщений, общение между контейнерами и прочее. К почти каждому микросервису теперь нужен graphgq интерфейс, помимо стандартных rest эндпоинтов.

Возник вопрос, а оно реально так должно быть / нужно? При условии, что нет штатного девопса и никто не шарит за best practices в организации этого зоопарка.

Высокой нагрузки на мой бэк нет, большинство задач планируется по крону, crud обеспечивает контейнер с hasura + postgres

Зачем там graphql и брокер сообщений одновременно вопрос, обычно люди обходятся просто http api или мессадж брокером. Может быть у вас не микросервисы, а обычный SOA? По поводу девопса, это отдельная тематика многие живут без девопса если команда одна, это не должно быть связанно с архитектурой. То есть девопсы это девопсы, а архитектура это архитектура.

Я вот тоже подумал напихали всего, что «модно»

А зачем вам микросервисы, чем монолит не устраивал?

Ну как вариант поискать вакансии и просто сменить контору, кстати... Как-то это странно: бэк разрабатываешь ты один - тебе задачу усложнили неоправданно Но я не знаю, так - вкидываю как вариант для размышлений, налицо нездоровое взаимное недопонимание с начальством Это решение принял кто? (По техническому бэкграунду всмысле) Если такое решают менеджеры, наверное проще объяснить с чем ты несогласен и уйти (либо передумают, тк такого разраба искать имхо долго, либо пойдут на диалог) Но опять же смотри по ситуации, пересказ мне лично видится дичью но это мое неопытное в айти мнение

graphql для удобства фронтендеров, для подключения всех контейнеров в один контейнер-эндпоинт (единая точка доступа), ну и чтобы рест для круда не делать. Брокер сообщений для общения между бэк-сервисами, например тот же парсинг, обработка логов ¯\_(ツ)_/¯

"Легко поддерживать", "отказоустойчиво", "можно деплоить в кубер"

Не менеджеры. Бэк-разработчик. Мне тоже сложно сказать, я вообще меньше года код пишу в продакшн ¯\_(ツ)_/¯

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

Так я сначала задал вопрос именно ему. Получил ответ вида "Легко поддерживать", "отказоустойчиво", "можно деплоить в кубер" В каком смысле уровня упорности?

Идк, например, может он затеял это чисто чтобы разобраться в технологии, и это в конечном итоге нанесет ущерб конечному продукту

Это все к монолиту применимо

Раньше ты деплоил и поддерживал один большой сервис, теперь кучу маленьких

Вот у меня от этого горит жопа. От какого-то охренительного усложнения. Это ж не яндекс, где 1000 RPS и достаточно сложные процессы внутри + экосистема

Может вы пилите яндекс для роботов, кто вас знает)

Так 2 бэк разработчика ты и тот кто это решение принял? Ну поработай если совсем трешина будет свалишь с новыми навыками (имхо) upd: дальше посмотрел речь про 10 разработчиков, так что возможно у топикстартера в компании все не так уныло, как показалось)

Ну типа 2 бэка, да, но наши с ним сферы работы не пересекаются (кроме архитектурных вопросов, в которых решает он). Он свой проект делает, я - свой. Остальные из разрабов - фронтендеры, которые бэк никак не трогают, кроме как "дай мне эндпоинт чтобы вот этот пайплайн запустить, мне кнопку надо прифигачить" А вообще вот эти вот скиллы сейчас в отрасли востребованы? Я смотрю по вакансиям, везде Rabbit/Kafka + Docker (compose/swarm) + Celery, редко встречаю кубер и elastic стек (скорее на сеньера). И я правильно понимаю, что под этими скиллами понимается не только уметь пользоваться, но и разворачивать & администрировать это все?

дак а че там уметь