The post has been translated automatically. Original language: Russian
Hello, community!
A frequent dispute in infrastructure teams is: "Do we still need virtual machines or do we need to move everything to Kubernetes?" The answer is boring, but correct: you need both layers. It's just that everyone has to solve their own problem.
Virtualization and containerization are not at the same level of abstraction. VMs provide OS isolation, resource management, and a familiar operational model. Containers provide application packaging, rapid releases, and scaling of services. Kubernetes is not a replacement for a data center or a magic "make cloud-native" button. This is an orchestrator who needs a solid foundation himself.
Let's look at the layers.
1. Hypervisor layer: stability and isolation. Workloads that need predictability live here: databases, legacy monoliths, stateful services, Windows applications, systems with strict network and storage requirements. VMs are convenient for backups, snapshots, clear capacity planning, and division of responsibilities between teams.
2. Container layer: the speed of delivery. Containers are good where the application was designed as a set of services: APIs, frontends, stateless components, workers, Dev/Test, ML/AI inference in separate services. The value here is not in "fewer resources", but in speed: build, deploy, rollback, autoscaling, a single pipeline.
3. Kubernetes layer: orchestration, not infrastructure instead of infrastructure. K8s requires a network model, persistent storage, observability, RBAC, backup policies, security context, registry, CI/CD, and release discipline. If this layer is placed on top of a weak or unmanageable infrastructure, the team simply transfers the chaos to a more fashionable format.
What does it usually look like in a mature scheme?
CloudFort's Private Cloud: a base layer for critical VMs, legacy, databases, and stable systems.
Container platform: a layer for new services, microservices, APIs, and DevOps processes.
Public outline: a sandbox for pilots, time loadings, and integrations where the risks are justified.
The main architectural principle is not to containerize everything. Stateful and critical workloads require a separate design. It is better to first stabilize Legacy at the infrastructure level, and only then decide which parts can be transferred to services.
At CloudFort, we help build this order of layers: from private cloud and fault-tolerant virtualization to scenarios where container platforms can be deployed on top of the infrastructure without losing control.
Colleagues, a question for you: which workloads do you already have in Kubernetes, and which ones do you deliberately leave in your VM? And where do problems arise most often: storage, network, security, observability, or ownership between teams?
Let's discuss the architectural cases in the comments. 👇
#CloudFort #AstanaHub #Kubernetes #Virtualization #Containers #DevOpsKZ #SystemArchitecture #PrivateCloud #CloudNative #Infrastructure
Привет, комьюнити!
Частый спор в инфраструктурных командах: «Нам еще нужны виртуальные машины или уже всё надо уносить в Kubernetes?» Ответ скучный, но правильный: нужны оба слоя. Просто каждый должен решать свою задачу.
Виртуализация и контейнеризация не находятся на одном уровне абстракции. ВМ дают изоляцию ОС, управление ресурсами и привычную эксплуатационную модель. Контейнеры дают упаковку приложения, быстрые релизы и масштабирование сервисов. Kubernetes — это не замена дата-центру и не магическая кнопка «сделать cloud-native». Это оркестратор, которому самому нужен надежный фундамент.
Разберем по слоям.
1. Hypervisor layer: стабильность и изоляция. Здесь живут workloads, которым нужна предсказуемость: базы данных, legacy-монолиты, stateful-сервисы, Windows-приложения, системы с жесткими требованиями к сетям и storage. ВМ удобны для резервирования, снапшотов, понятного capacity planning и разграничения ответственности между командами.
2. Container layer: скорость доставки. Контейнеры хороши там, где приложение проектировалось как набор сервисов: API, фронтенды, stateless-компоненты, воркеры, Dev/Test, ML/AI-инференс в отдельных сервисах. Здесь ценность не в «меньше ресурсов», а в скорости: build, deploy, rollback, autoscaling, единый pipeline.
3. Kubernetes layer: оркестрация, а не инфраструктура вместо инфраструктуры. K8s требует сетевой модели, persistent storage, observability, RBAC, backup-политик, security context, registry, CI/CD и дисциплины релизов. Если этот слой поставить поверх слабой или неуправляемой инфраструктуры, команда просто переносит хаос в более модный формат.
Как это обычно выглядит в зрелой схеме?
Private Cloud от CloudFort: базовый слой для критичных ВМ, legacy, БД и стабильных систем.
Контейнерная платформа: слой для новых сервисов, микросервисов, API и DevOps-процессов.
Публичный контур: песочница для пилотов, временных нагрузок и интеграций, где это оправдано по рискам.
Главный архитектурный принцип: не контейнеризировать всё подряд. Stateful и критичные workloads требуют отдельного дизайна. Legacy лучше сначала стабилизировать на инфраструктурном уровне, а уже потом решать, какие части можно выносить в сервисы.
В CloudFort мы помогаем строить этот порядок слоев: от частного облака и отказоустойчивой виртуализации до сценариев, где поверх инфраструктуры можно разворачивать контейнерные платформы без потери контроля.
Коллеги, вопрос к вам: какие workloads у вас уже живут в Kubernetes, а какие вы сознательно оставляете в ВМ? И где чаще всего возникают проблемы: storage, сеть, безопасность, наблюдаемость или ownership между командами?
Давайте обсудим архитектурные кейсы в комментариях. 👇
#CloudFort #AstanaHub #Kubernetes #Virtualization #Containers #DevOpsKZ #SystemArchitecture #PrivateCloud #CloudNative #Infrastructure
Share
