Сегодня контейнеры кажутся настолько естественной частью инфраструктуры, что трудно представить IT-мир без Docker или Kubernetes. Но если отбросить привычку думать “контейнеры = лёгкие виртуалки”, становится ясно: контейнеры родились не ради экономии серверов, а ради управления хаосом приложений.
Именно это и объясняет Джастин Кормак (ex-Docker) в своей статье “Why did containers happen?”.
🧩 От виртуализации к упаковке
В 2000-х компании столкнулись с проблемой избытка “железа” — сотни серверов, низкая утилизация, ручные инсталляции.
💽 Виртуальные машины решили эту задачу: они консолидировали серверы и сэкономили лицензии.
Но к 2010-м появилась другая проблема — слишком много приложений.
С каждым Dev-отделом, microservice и CI/CD-цепочкой инфраструктура начала тонуть не в “железе”, а в дебрях версий, зависимостей и окружений.
Вот тут и появился Docker (2013) — не как “лёгкая VM”, а как система упаковки и развертывания приложений.
DotCloud, предшественник Docker, создавался как PaaS, и контейнеры стали ответом на банальный вопрос:
“Как развернуть сотни приложений быстро, одинаково и предсказуемо?”
⚙️ Ключевые инновации Docker
🧱 Docker Hub — “GitHub для контейнеров”.
Регистр, где можно было делиться образами, стал революцией. VM-образы весили гигабайты, делиться ими было бессмысленно.
Контейнерные образы же оказались мелкими, переносимыми и переиспользуемыми.
🧬 Иммутабельность — “не обновляй, пересобери”.
Docker заставил мир отказаться от «ftp в продакшн» и научил строить декларативные окружения.
Переустановить приложение стало проще, чем чинить — и это привело к новым принципам безопасности и предсказуемости.
💡 Язык Go получил второе дыхание: Docker сделал его “языком инфраструктуры”.
Сегодня Go — четвёртый по популярности язык в контейнерах после Node.js, Java и Python.
☸️ Kubernetes: оркестр вместо хаоса
Поначалу контейнеры решали задачу упаковки, но не координации.
С ростом масштабов появилась необходимость управлять их жизненным циклом — отсюда Kubernetes.
🧭 Первые пользователи не искали “супер-планировщик”, они хотели сценарии деплоя.
Именно поэтому Kubernetes победил: он позволил описывать состояние кластера декларативно.
Так родились Helm, GitOps, ArgoCD, а DevOps превратился из культуры в техническую профессию.
Docker Swarm пытался идти тем же путём, но ограничивал деплой изнутри кластера — и проиграл.
⚠️ Цена прогресса
Kubernetes принёс мощь и гибкость, но вместе с ними — сложность.
DevOps перестал быть философией “сотрудничества”, став ролью “человека, который пишет YAML”.
То, что начиналось как объединение Dev и Ops, закончилось новой специализацией и ростом инженерной бюрократии.
Парадокс: технология, призванная упростить жизнь, съела саму культуру DevOps.
🧮 Современные параллели
Когда-то виртуалки спасали от неэффективности “железа”, теперь контейнеры борются с неэффективностью приложений.
Но, как отмечает Кормак, по данным Datadog (2024), 83% расходов на контейнеры приходится на простаивающие ресурсы.
💸 Технологии стали точнее измерять пустоту, но не избавили нас от неё.
Мы научились автоматизировать неэффективность.
💤 Контейнеры стали “скучными” — и это хорошо
В 2015-м вышел манифест “Choose Boring Technology” — “Выбирай скучные технологии”.
Тогда Docker и Kubernetes были “не-скучными”.
Теперь, спустя 10 лет, ChatGPT сам признал:
“Docker — в основном скучный. Kubernetes — становится скучным.”
И это прекрасно.
Когда технология становится скучной — значит, она стала базовой инфраструктурой мира.
Как HTTP, как Linux, как Cron.
💭 Мнение автора
Контейнеры не просто изменили DevOps — они впервые сделали инфраструктуру воспроизводимой.
Это момент, когда сборка среды стала кодом, а деплой — предсказуемым действием.
Но вместе с тем они превратили инженерию в “ЯМЛ-инженерию” — напомнив, что каждый слой абстракции имеет свою цену.
И всё же, я согласен с Кормаком: контейнеры появились не потому, что были “лучше виртуалок”, а потому, что разработчики утонули в собственных приложениях.
И пока мы снова не утонем — на этот раз в микросервисах и LLM-агентах — контейнеры останутся самой здравой идеей XXI века.