uid uniqueДругая ситуация когда у клиента жирный сервер, на нем много чего еще есть (и что именно есть, вам не говорится пока жалоб не будет на вас) и вам нужно не только свое запустить но и чужое не поломать (такое же требование к разработчикам других приложений на том же сервере). В этом случае ext/lib трогать не рекомендуется (долгие согласования)

Давно уже есть виртуальные сервера.
Одно приложение - один сервер. Это не проблема.
А сейчас есть модные контейнеры, которые почти как виртуальные сервера, только "легковеснее".
Так что взаимодействие м/у приложениями, это сейчас проблема не программистов, а внедренцев и админов.
Создали на одном сервере приложений "зоопарк" - сами себе злобные буратины. :-)

uid uniqueКонечно все так но не всегда проекты строятся с нуля и не всегда мир вертится вокруг хотелок разработчика.
Представьте себе в качестве клиента крупный банк (крупнее Сбера в несколько раз), или крупную страховую контору, вы для них делаете один из кубиков большого паззла, один или два специализированных сервиса или приложение. Или адаптируете свой продукт.

1. У клиента есть инфраструктура и штат поддержки и список имеющихся версий баз данных, серверов приложений и тд. Если у клиента есть Оракл а у вас по умолчанию MS SQL, скорее всего придется перейти на Оракл (и наоборот).
2. Внесение новых решений и технологий сразу порождает вопрос - кто будет заниматься поддержкой. Особенно если технология open source. Либо придется оказывать поддержку вам либо искать другую контору.
3. Согласование, закупка оборудования и тд может занять пару лет а у вас на проект до его запуска к примеру год.

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

Ох-ох-ох...
Вообще при внедрении или даже развитии какой-то ИС (или приложения) всегда можно пропихнуть аппаратную часть.
Как минимум во всех проектах, в которых я участвовал этот пункт как минимум рассматривался.
Причем предварительно проводился анализ окружения. Что есть и что надо (аппаратная часть).
А дальше уже внедренцы должны были с этим анализом и аргументами обосновать заказчику, что таки оборудование надо докупить.
Или как минимум подумать о виртуализации.
Как минимум лет 10 назад у нас (в Казахстане) пошел массовый переход на виртуальные сервера.
И сейчас это фактически "стандарт".
Причем переносили и "унаследованные" приложения.

Например мне, когда требовалось развернуть небольшой сервис, для какой-нибудь мелочовки (типа обратиться по распианию к определенным сервисам, забрать информацию и положить ее в БД) было проще договориться с админами заказчика на выделение минимальной виртуалки, чтобы моя мелочевка там крутилась.
Причем все естественно оформлялось в виде официальных писем и т.д. РП.
Но обычно перед бумажным прикрытием была договоренность с админами заказчика.

Если же заказчик беден и/или жаден.
То опять же официальное письмо, что работоспособность ИС не гарантирована, т.к. аппаратное обеспечение и окружение не соответствует требованиям.
Такие случаи тоже были...
Но там если что-то "падало", то виноват был "заказчик", но мы всегда "входили в положение" ;-)