В профессиональной среде довольно популярно мнение, что молодым компаниям стоит избегать контейнерной инфраструктуры. Его придерживаются даже бывшие разработчики Kubernetes. Но, разумеется, с ним согласны не все. Мы в T1 Cloud пишем про облачные технологии и решили обсудить разные точки зрения.
Аргументы против
Чтобы запустить MVP или протестировать идею, стартапам достаточно арендовать виртуальные машины у сервис-провайдера или настроить пару серверов в локальном дата-центре. Им нет смысла строить архитектуру на Kubernetes по типу корпораций из big tech. В этом убеждены многие предприниматели, разработчики, системные администраторы и другие специалисты. Например, Кристофер Тоцци, облачный аналитик и по совместительству автор книги «For Fun and Profit: A History of the Free and Open Source Software Revolution», считает, что эффект от внедрения K8s не стоит усилий, требуемых для настройки окружения.
Контейнеры усложняют архитектуру продукта и увеличивают нагрузку на разработчиков. В таких условиях рано или поздно придется формировать отдельную команду для поддержки бэкенда. Эта задача будет отнимать ресурсы, необходимые для развития функциональности ключевого продукта, оттягивать его запуск. Но время не тот ресурс, которым стартап может жертвовать, с учетом того, что до пятого года жизни дотягивает не больше 50% бизнесов.
Другой аргумент связан с производительностью Kubernetes. Он подходит для высоконагруженных приложений, поэтому его выбирают команды, пытающиеся заложить потенциал масштабирования на будущее. Один из участников форума Hacker News назвал такой подход What-If Engineering, когда разработчики заранее решают проблемы, которых может и не быть.
В тематическом треде один инженер рассказал, что работал на проекте, где использовали скрипты Ansible для управления инфраструктурой — на это уходило порядка $100 тыс. ежегодно. Когда подход пересмотрели, ценник сразу сократился на 85%. Даже один из бывших мейнтейнеров Kubernetes в своем блоге отметил, что проект должен расти параллельно с нагрузкой. И к контейнерам стоит переходить, когда команда обзавелась достаточной пользовательской базой.
Еще один нюанс, связанный с построением архитектуры на K8s, — это большое количество дистрибутивов. Все они построены на одной базовой платформе, но инструменты различаются. В то же время они содержат множество компонентов — аддонов, кублетов, контроллеров, планировщиков и API-сервисов. Если по какой-то причине компания переходит с одного решения на другое, инженерам придется изучать новый инструментарий. В то же время оркестровка требует ручного контроля — у стартапа на это нет ни ресурсов, ни времени.
Альтернативный взгляд на вещи
Разумеется, далеко не все согласны с утверждением, что молодым компаниям не нужно «погружаться» в K8s. По мнению одного из резидентов Hacker News, все зависит от экспертизы команды. Инженерам стоит работать со стеком, который хорошо им знаком. Если это Kubernetes, Firecracker или Nomad, то почему бы не внедрить контейнеры с первых дней.
Среди участников сообщества также можно встретить специалистов, которые считают, что Kubernetes, наоборот, упрощает обслуживание IT-инфраструктуры. Так как писать скрипты на Terraform сложнее, чем работать с файлами манифестов в K8s. В качестве примера пользователь HN привел компанию, где он трудоустроен. В экосистеме есть приложение, представляющее собой набор PHP-файлов и таблиц crontab, развернутых на нескольких серверах. Приходится мириться со многими неудобствами и общими библиотеками. Другое приложение развернуто на контейнерах в облаке — тут обновление занимает гораздо меньше времени.
Главная проблема, с которой сталкиваются стартапы на ранних этапах, — это усложнение архитектуры баз данных, брокеров сообщений, микросервисов и других компонентов. Однако подобная «солянка» будет вызывать трудности на любом этапе разработки. С Kubernetes не должно быть сложностей, если грамотно подойти к развертке инфраструктуры. В теории запустить и обслуживать компактную среду может даже команда без опыта работы с контейнерами.
Первое время они действительно были чем-то сложно управляемым, но сегодня облачные провайдеры и сторонние поставщики предлагают инструменты, которые снижают порог входа для работы с K8s.
На что обратить внимание
Если просуммировать мнения, то к Kubernetes — это просто инструмент. Есть сценарии, когда стартапу лучше отказаться от контейнерной среды. В другом случае она может ускорить развитие проекта.
Если стартапу достаточно одного сервера, то K8s будет лишним, так как он повышает когнитивную нагрузку на разработчиков. Впрочем, контейнеры также плохо приспособлены для вычислений на базе GPU — в частности, аналитики данных и машинного обучения.
Разумеется, от этого правила можно отойти, если команда хорошо знакома с технологическим стеком и понимает, как извлечь из контейнерного окружения максимум.
На первый взгляд, большое количество дистрибутивов Kubernetes усложняет инфраструктуру. С другой стороны, облачные провайдеры предлагают инструментарий, упрощающий оркестровку за счет абстракций и методологий Infrastructure as Code.
О чем еще мы пишем в нашем блоге на Хабре: