Давайте проследим краткую историю способов размещения программ (для простоты не будем о мейнфреймах):
- Железные сервера
- Виртуальные машины
- Контейнеры
Железные сервера
В этом подходе производитель или интегратор чаще всего сам покупает все необходимое железо. И полностью обеспечивает решение: от установки до мониторинга и резервного копирования. При этом железо берется с приличным запасом, чтобы заказчик не выставлял претензии о низкой производительности.
Даже если сервера размещает внутренняя служба ИТ, то в итоге получается то же самое: много серверов, большинство из них специализированы и слабо загружены, а на нескольких сильно не хватает ресурсов.
Если железный сервер сломался, то его, как правило, чинят, т.к. перенести ПО на другой сервер весьма проблематично.
Чинят чаще всего за счет других, менее приоритетных серверов, пока ждут доставку новых компонентов.
В итоге, получаем следующие проблемы:
- низкая утилизация железа на большинстве серверов
- тяжело увеличить мощности, если какому-то ПО это нужно, особенно временно
- дорого делать отказоустойчивость: ПО особо не перенесешь на другие машины, нужно сразу машин с запасом
- каждое решение мониторится и бекапится по своему
Виртуальные сервера
Как раз, чтобы решить перечисленные выше проблемы были придуманы виртуальные сервера:
- виртуальные сервера можно в целом централизованно мониторить
- можно централизованно бекапить и восстанавливать на другом железе
- можно увеличивать и уменьшать используемые мощности достаточно просто вручную
- для не критичных к небольшому простою приложений можно вообще не делать сразу вторую машину – если что виртуалка будет перенесена на работающий сервер
- железо уже закупает ИТ, а не интегратор/производитель ПО
Т.о. снижается зависимость от интеграторов (а вместе с этим и цены), а так же чисто технически так гораздо проще и эффективней размещать ПО.
Переход на виртуалки произошел довольно просто, т.к. с точки зрения ПО и даже процедур установки это как настоящий железный сервер и мало что поменялось.
Решает ли это все проблемы? Конечно, нет. Давайте перечислим еще проблем:
- каждое решение ставится по своему
- каждое решение масштабируется по своему
- если хочется не просто загрузку ЦПУ на виртуалке, а более детальный мониторинг, то каждое решение мониторится по своему
- бекапы на уровне виртуалок – это уже отлично, но они занимают много места и могут оказаться битыми, хочется бекапить все-таки данные, а тут опять индивидуально для каждого решения
- сложно работать с зависимостями. Например, для нового ПО нужна база данных и балансировщик нагрузки. Все это сначала описывается в документах, потом вручную устанавливается и настраивается
- каталог сервисов (уже ближе к SOA или микросервисной архитектуре)
- трейсинг запросов через много система (тоже ближе к SOA или микросервисной архитектуре)
Контейнеры и K8s
Как несложно догадаться, контейнеры получили широкое распространение для решения проблем выше.
По сути, это еще более мелкие и динамические виртуалки только с 1 приложением внутри каждого контейнера.
Такое разделение позволило выделить много общих частей:
- установка
- мониторинг
- масштабирование
- настройка балансировщиков запросов
- запрос зависимостей (таких как база данных) – через операторы Kubernetes получается вполне себе PaaS
- бекапы
- обнаружение сервисов
- трейсинг запросов между системами
Понятно, что централизованно это все проще и дешевле решать.
При этом возникла проблема с уже существующими решениями: сами приложения обычно не нужно сильно переписывать, но вот всю обвязку на новую стандартную для Kubernetes нужно менять.
Это привело к половинчатым решениям: приложение вроде бы и можно запустить в Kubernetes, но далеко не все общие части выше оно может использовать. Чтобы подчеркнуть приложения, которые полноценно используют Kubernetes, был придуман термин Cloud Native (Kubernetes по сути является стандартом де-факто для частных облаков).
Со временем начали появляться приложения, которые изначально спроектированы для K8s. Вроде бы для них уже есть термин Cloud Native, но он уже испорчен франкенштейнами из прошлого, адаптированными под K8s. Кто-то использует термин Serverless, это наиболее близкий сейчас термин к настоящим Cloud Native приложениям.
Если ли проблемы при деплое приложений в K8s? Да, конечно. Пока что вероятный вектор дальнейшего массового развития – Serverless-концепции.
Отдельно о деплое K8s в виртуалках: это странно и неэффективно. Часто это говорит о том, что команда ИТ не понимает замещающую роль K8s и не хочет дальше развиваться (у нас и так все хорошо и отлажено с виртуалками).