Про первый кусок технологий поговорили, теперь о втором - Docker и DC/OS.

Предположим, что вы хотите открыть свой интернет-магазин плюшевых хомячков. Бизнес модель есть, бюджет есть, наемный тыжпрограммист есть.
По “классике”, ваш тыжпрограммист арендует сервер, поставит туда “веб” сервер (система для обслуживания сайтов) и базу данных, чтобы хранить информацию о клиентах и товарах. Здесь надо понимать, что каждая система (веб-сервер, СУБД и тд) это программы. Каждая программа состоит из “своего” программного кода и зависимостей.

Например, для того, чтобы поставить Nginx, на вашем сервере должен стоять GCC (GNU C Сompiler), а для GCC требуется сам C.
Вы поставили СУБД и веб-сервер, написали ваш сайт “ООО Плюшевые хомячки”. Сайт запущен, клиент радостно заходит на него и заказывает себе игрушки. Здорово, правда?

В какой-то момент к вам начинает приходить больше посетителей, и сервер начинает не выдерживать нагрузки (помните, что у вас на 1 сервере и веб сайт, и база данных). Что делать? Заказывать новый сервер и ставить туда ваш вебсайт. А потом еще. И еще. И еще…
Учитывая, что программист все ставит руками, “дублирование” статического сайта начинает занимать больше времени, чем разработка. Это первая проблема.

А потом вы хотите сделать модную систему анализа пользовательского поведения, чтобы определить свою ЦА и начать активно раскручиваться. Для этого нужно опять заказывать сервер, писать под него ПО с кучей зависимостей, а ваша маленькая база и так еле справляется, вы заказываете еще сервер под дублирование БД, настраиваете кластеризацию, ставите перед ними балансировщик, затем дублируете систему анализа данных…

А затем вы разрабатываете “свою” систему email маркетинга, чтобы привлечь еще больше клиентов, ваше приложение становится сложным, и для отказоустойчивости вы применяете очередь сообщений (ЕЩЕ 1 сервер, еще больше ручной работы)…

Уловили идею?

До того как появился Докер, эти проблемы решались такими прикольными способами как управление конфигурациями, автоматизация управления и Infrastructure-as-Code. Идея заключается в том, что в определенных файлах вы описываете, что и как должно быть установлено и где - а затем говорите системе установить это ПО на сервер-1, вот это ПО на сервер-2, а на сервер-3 поменять адрес веб сайта с fluffyhamster.ru на hamsterforlove.ru.
Применение такого подхода сокращает время на настройку и развертывание, но не решает проблему зависимостей - так что поговорим и о ней.

Есть такой прекрасный язык программирования как Python. Я этот язык ну очень сильно люблю и когда программирую, то на нем и только на нем.
У Питона есть две “мастер” версии - 2 и 3. Они друг от друга сильно отличаются, и программа, написанная на Питон 2, вряд ли заработает на Питон 3. Разработчики обычно пишут программы, совместимые с обеими версиями, а умные разработчики переписывают старые программы под Питон 3.

Итак, вот ваш кейс. В вашем онлайн-магазине есть две маленькие программы - одна генерирует электронную рассылку для клиентов, а вторая анализирует пользователей в БД, чтобы выявить интересные для них предложения. Исторически так сложилось, что первая программа была написана на Питон 2, а вторая на Питон 3. Поскольку программы маленькие, заказывать под них отдельный сервер непозволительная роскошь (в простонародье ДОРОГО). Держать их на одном сервере - геморрой с точки зрения “объяснить программе 1 использовать вот этот вот Питон, а программе 2 вот это вот Питон, и НЕ НАОБОРОТ, ТЫ ЧТО НАДЕЛАЛ, У НАС СЕЙЧАС КЛИЕНТЫ ВЗБЕСЯТСЯ, ВЕРНИ КАК БЫЛО, ЧТО ЗНАЧИТ ТЫ УДАЛИЛ 3 ПИТОН, ТЫ НАРКОМАН ЧТОЛИ?”