|
Top-level
 @shuro сложно представить, когда разбивка чего-то большого на меньшие "кусочки", которые отвечают только за одну функцию - усложняет. Ну только если коллеги не понимают, как эти кусочки между собой связаны. Тогда надо просто написать доку. Монолит - это хорошо, но только тогда когда все понимают из чего он состоит. Когда это не так, то лучше дробить. Эт относится как к технологиям так и таскам. 7 comments
 @exo Ну так KISS не обязательно вращается вокруг контейнеров, он появился ещё до них. Тут, скорее всего, возникло как раз такого рода недопонимание - товарищ решил, что набор сервисов представляет собой единую сущность с системной точки зрения, поэтому их проще консолидировать. Почти всегда это не так, это да. конечно KISS появился до контейнеров, но его принципы прекрасно перелагаются на них. Всякими docker compose'ами и прочими кубернетесами :) Про недопонимание полностью согласен, потому и написал первым комментом, что надо спокойно донести свою точку зрения. Ведь все люди разные и по-разному видят абстракции :blobcatshrug:  не вижу никаких проблем потестировать балансировщик с одним контейнером, даже проще @exo @shuro это, как раз, очень просто. Больше компонентов - сложнее взаимодействие между ними. С базами данных это наиболее выпукло - сравни няшный простой метод, который обновляет по одной строке в трёх табличках в одной транзакции с тремя компонентами, которым нужно взаимодействие, сеть, протокол, монстрозная распределённая транзакция или возня с компенсацией транзакций |
Gregory's Server
@exo Несложно :)
Берём любую крупную зависимость или их устоявшееся сочетание. Условно говоря, PHP с нужными модулями можно засунуть в контейнер (или не засовывать, но технологически считать одним куском), а можно смотреть как на набор отдельных, хоть и взаимозависимых сущностей, и поддерживать отдельно.