Самое абсурдное видео за сегодня, которое вы посмотрите.

Заставка сериала «Друзья» — но он называется «Друзи», а в главных ролях игрок «Что? Где? Когда?» Александр Друзь.

Комментарии: youvi.ru/post/3i509bNUGf3

А дизайнить кто все это будет? Транспорт, протоколы и межсервисное взаимодействие?

так ты же и так и так дизайнишь это

ну, будет вместо restful api шина

Вот где эти светлые люди в описываемой тобой схеме?

это зависит от уровня проекта

Шина?

ты же понимаешь, что совсем мелкие проекты - это просто, условно, Django, вообще без каких-либо тестов

Так ты про малый бизнес или же что-то серьезное?

оно к любому подходит, кроме какого-то супер-хайлоада

тебе нужно добавить некий новый модуль и ты можешь его в монолит вляпать

а можешь отдельный сервис поднять

МИКРОсервисы - думаю честно говоря что вообще никуда не подходят

просто сервисы - там где они в тему - подходят

ну, убери слово микро

микро у каждого свой

то есть вот есть у тебя условный монолит, допустим, на Django, ты можешь прямо там новое app сделать (в рамках того же проекта Django в том же контейнере), а можешь, например, отдельный контейнер (или даже Cloud Function) и с основным взаимодействовать по шине, шина будет managed, сам контейнер тоже на managed Kubernetes, так что в плане админства одинаково, а в плане удобства разработки - ну, отдельно это может быть удобнее делать, будет проще кому-то потом передать другому поддерживать, отдельно от основного приложения (вопрос про удобство разработки)

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

А точно тут нужен кубер?

ну, если оно managed, то какая разница, что там