at0m1x

Я думаю здесь подмена понятий. Автор пишет "кэширует ли БД запросы", а имеет в виду "может ли в принципе эта страшная и непонятная громадина которая называется базой данных в принципе хоть когда-нибудь рабтотать быстро?"
Все, разумеется, кидаются отвечать на первый вопрос.
А на самом деле надо отвечать на второй. Да, почти всегда БД работает гораздо быстрее чем ты можешь вообразить и ничего кэшировать не нужно. Если вдруг стало работать медленно... впрочем, об этом ниже.

Нужно ли делать кеширование запросов
Вот в такой формулировке, взятой с потолка, "а не закэшировать ли мне запросы к базе данных*" - Нет, не нужно.

и как?
Очень просто.
Три простых шага:
1. Понять, устраивает ли тебя производительность приложения. Если устраивает, то все оставить как есть.
2. Если не устраивает, освоить профайлинг. Если это слово не упоминается в вопросе про производительность или кэширование, то вопрос можно сразу удалять. потому что он заведомо взят с потолка и не имеет смысла. По сути, профайлинг - это замер скорости выполнения отдельных участков кода для поиска узких мест - т.е. таких участков кода, которые тормозят всю программу. Это можно делать и вручную, и с помощью различных готовых инструментов. Только по результатам профайлинга, который показал конкретную причину тормозов, то самое узкое место (его еще называют bottleneck, "бутылочное горлышко"), можно приступать к оптимизации. Не кэшированию!
3. Если профайлинг показал, что проблема в конкретном запросе к БД, приступаем к его оптимизации. Чаще всего достаточно добавить индекс или донастроить сервер.
4. Только если все другие способы не помогли - занимаемся кэшированием. Но перед этим сначала решаем Вторую Важнейшую Проблему Информационных Технологий - инвалидации кэша. Поскольку закэшировать - это ерунда, каждый дурак сможет. Самая главная проблема не в том, как данные положить в кэш, а как и когда их оттуда удалять.

404
или 410 - если совсем навсегда
301 - если там есть хорошие бэклинки, в остальных случаях отдавайте 404

Многое конечно зависит от специфики проекта, но примерный алгоритм действий в общем случае такой:

1. Выбираете новый фреймворк (или без него, на ваше усмотрение). Решаете делать новый функционал на нем и только на нем. ZF2/3 ли, Symfony, Laravel - разницы никакой, что вам нравится. Готовьтесь к тому, что придется бизнес логику переписать полностью (если интеграция с фреймворком была жесткой, как обычно делают PHP разработчики). Если была завязанность на абстракциях и модульная структура - вас можно поздравить, переход будет безболезненным и быстрым.
2. Приготовьтесь, что работы станет больше, чем просто на ZF1 задачи решать и дальше. Постарайтесь не просесть слишком по производительности.
3. Есть список URL, перенесенных в новое приложение. Решение о том, какому приложению отдать обработку запроса, находится в точке входа в приложение. (в index.php, например. Т.е если обычно там происходит просто инициализация приложения, то перед ним теперь должна быть бизнес-логика определения, какому приложению дать ход, этакий свой мини-роутер. Если переписано - отдаете новому приложению. по дефолту старому)
4. Если у вас не было тестов - именно тут вы начнете понимать, почему они были нужны :)

Ну и по факту получается, что у вас некоторое время будет 2 приложения, которые надо параллельно разрабатывать. Старое помечаете как немодифицируемое. Приходит задача - сначала переносите ее на новый фрейм, тестируете, если работает как надо - в своем мини-роутере направляете соответствующие запросы в новое приложение. Постепенно с 0% до 100% доводите - и можно выкидывать старый фреймворк и микро-роутер в индексе, вы переехали.

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

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

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

Если вас интересует возможность именно в "сетевом" плане то все ваши опасения развеет настройка firewall :)

Пользуйтесь и не парьтесь и главное не пробрасывайте ненужные порты на роутере на статический адресс виртуальной машины.

Пароли и другие чувствительные данные можно передавать через переменные окружения. Доступ к переменным окружения имеет только само приложение посредством веб-сервера (с правами пользователя, из-под которого он запущен). Например вот так (Linux).

> "велосипед" который будет обновляться самой командой в соответствиями с требованиями проекта?

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

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

> Но что если новая версия очень сильно отличается от старой, придется проделать много работы по переделке большого проекта на новую версию.

Это значит, что фреймворк использовался только для украшения, а бизнес-логика писалась по-старинке, овнокодом.
Мы месяц назад поменяли мажорную версию Симфони, с 2.3 на 3.2. Переделки потребовались, но чисто механические, по замене нескольких устаревших функций.
Достаточно следовать рекомендованным практикам, использовать рекомендованные инструменты и апгрейд не будет настолько болезненным.

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

> Как обычно поступают команды, когда используется сторонний фреймворк, постоянно обновляют его версию в проекте или остаются на старой версии?

Хотя бы за мажорной версией следовать необходимо.

Возможно вы имеете ввиду Тайловые WM
Они как раз заточенны под хоткеи.
Awesome и i3 вроде как самые распространенные

Конкретно в этом видео вроде бы стоит i3