А когда появился Докер, проблема зависимостей была решена. Я не буду расписывать, как устроен и работает Докер (для неподготовленного читателя это очень сложно, но если очень хочется - пишите мне в личку, постараюсь расписать). Докер создает определенный слой изоляции, где ваша программа запаковывается в определенный “контейнер”. Внутрь вашего контейнера вы устанавливаете все зависимости, добавляете вашу программу, и - вуаля! - ваша программа “запакована”. Запустить ее можно где угодно, достаточно на сервере установить сам Докер и выкатить туда “образ” вашего контейнера.

Докер вообще ВЗОРВАЛ интернет, это была технологическая революция сродни виртуализации. Но, как у каждой новой технологии, у Докера есть свои проблемы.
Например, если вы “убьете” контейнер, все данные на нем пропадают - соответственно он не подходит под базы данных. Впоследствии эту задачу решили с помощью persistent volumes - когда контейнер использует диск самого сервера.
Или другая проблема - контейнер умирает, и вам нужно, чтобы он поднимался сам автоматически.
Или если у вас несколько контейнеров, на которых ваш сайт - как сбалансированно распределять клиентские запросы между ними (помните, что контейнеры иногда умирают).
Или как обновлять ПО. Чтобы запустить контейнер с “новым” ПО, надо остановить контейнер со “старым” ПО, а значит клиенты некоторое время не смогут работать с сайтом.

Чтобы решить такие проблемы, придумали системы контейнерной оркестрации. Самым популярным сейчас является Kubernetes, который из коробки все это делает.

Но мы ребята особенные и используем DC/OS (который на самом деле не контейнерная оркестрация, а система, объединяющая ресурсы нескольких серверов - процессор, память и диск - в один большой pool). Поскольку DC/OS создает определенный уровень абстракции и управления ресурсами, на него сверху ставится Marathon - как раз та самая система оркестрации, которая получает данные о ресурсах от DC/OS и на основе этих данных решает, где и как запускать контейнеры. На DC/OS так же ставится специальный балансировщик, который будет распределять поток клиентских данных и запросов на нужные контейнеры.

Вот как-то так.

C DC/OS у меня следующие проблемы:
1. Я его вообще не знаю.
2. DC/OS довольно сложный. Документация не в полной мере раскрывает, что под капотом, а инструкция по установке предлагает скачать заранее заготовленный шаблон инфраструктуры, чтобы попробовать его у себя локально или в AWS

Как любой уважающий себя специалист, я должен сначала изучить то, что хочу внедрить, поэтому я провожу определенное “исследование”. О нем я расскажу завтра. На сегодня информации хватит. 😉