На слуху самые новые технологии — Web3, Metaverse, NFT, но как и в
В чем проблема?
Вы можете возразить, что не все разработчики испытывают трудности с развертыванием своих приложений, и будете правы. Google и Netflix бесперебойно поставляют код с огромной скоростью. Ваш друг, создавший совершенно новый стартап, без проблем развертывает свое Jamstack-приложение на Vercel. Так в чем проблема? Речь о тех десятках тысяч компаний среднего размера, приложения которых слишком велики, чтобы поместиться на «платформу как сервис» (PaaS), но не настолько, чтобы нанимать армию DevOps и инженеров по надежности систем (SRE).
Время Heroku
Стартап хочет вывести свой минимально жизнеспособный продукт на рынок как можно быстрее. Большинство компаний обращаются к PaaS, таким как Heroku, Vercel или любому другому из бесчисленных решений на рынке. Такой подход полностью оправдан по следующим причинам:
- это дешево. Обычно существует бесплатный тарифный план с возможностью запуска приложения за несколько долларов в месяц;
- простота в использовании. Последнее, чего хотят стартапы на ранних стадиях, — это тратить время на настройку инфраструктуры. Несколько кликов на веб-интерфейсе, отправка кода в git-репозиторий — и приложение готово к работе.
Дорога на AWS
Потенциально сказка может продолжаться бесконечно, но менее удачливые однажды столкнуться с суровой реальностью: они перерастают свой PaaS. Или, по крайней мере, он больше не соответствует их потребностям. Это может происходить по разным причинам:
- кодовая база растет, и управлять десятками сервисов на платформе PaaS становится сложно;
- вначале PaaS была дешевой, но теперь стала слишком дорогой;
- по каким-то причинам стартапу необходимо развернуть инфраструктуру у определенного облачного провайдера;
- PaaS не поддерживает определенный регион, в котором нужно развернуться;
- стартап не хочет привязываться к одному поставщику;
- приложение имеет специфические потребности, которые несовместимы с PaaS.
Список можно продолжать.
На данный момент новые компании чаще всего обращаются к одному из основных облачных провайдеров — AWS. Поначалу это выглядит очень многообещающе. Все API или сервисы, о которых они только могут подумать, уже присутствуют. Они могут адаптировать инфраструктуру к своим потребностям с помощью почти бесконечного числа типов экземпляров EC2. Управляемые базы данных? Да! CDN? Конечно! Вы даже можете добавить несколько «лямбд» (AWS Lambda), чтобы присоединить к вашему стеку «бессерверность». Похоже на мечту, не так ли?
Kubernetes — волк в овечьей шкуре
Но когда вы просыпаетесь от этого сна, реальность оказывается менее привлекательной. Amazon Web Services — сложный продукт, и начать работу с ним не так просто, как казалось вначале. Такие сервисы, как Elastic Beanstalk, имеют те же недостатки, что и другие PaaS, а построить конвейер доставки с нуля на основе предоставленных строительных блоков — нелегкая задача.
А что, если вы также хотите развернуть систему на GCP или Azure? У каждого облачного провайдера свои особенности и API. Очевидного пути к мультиоблаку не существует. В качестве ответа на эти вопросы многие компании обратились к Kubernetes. Эта платформа быстро стала мейнстримом и де-факто выбором каждой команды, которая хочет стать нативно-облачной.
Проблема решена? Нет! Многие ошибаются, думая, что Kubernetes — это платформа для разработчиков. Поначалу она может показаться простой, но по мере роста сложности люди начинают спускаться в кроличью нору, доходя до безумия, пока наконец не осознают, что Kubernetes не предназначена для разработчиков. По мнению одного из основных контрибьюторов Kubernetes Келси Хайтауэра, Kubernets — это платформа для создания платформ и лучшее место для старта, но она никак не является конечной целью. Чтобы создать собственную платформу для разработчиков на базе Kubernetes, компании создают целые команды DevOps и SRE. Некоторые из них добиваются успеха, но большинство терпят неудачу.
Следующее поколение PaaS
Итак, с одной стороны, у нас есть PaaS в стиле Heroku, простая в использовании, но ограниченная функционально. С другой стороны, Kubernetes с бесконечными возможностями, но большой сложностью. Что бы мы могли получить, если объединить лучшее из двух миров? Это будет следующее:
- простота PaaS для разработчиков;
- отсутствие привязки к одному поставщику;
- полная мощь Kubernetes.
Лучшее из двух миров
Тем командам, которые открыли собственный аккаунт в AWS (или в GCP либо в Azure), нужна не хостинговая платформа «все в одном» — им нужен способ свести к минимуму усилия по DevOps. Им нужен «DevOps-инженер как услуга» (DevOps engineer as a service). Такой сервис обеспечивает полный контроль над инфраструктурой, выполняя за вас обслуживание и тяжелую работу. Он хранит все конфигурации Terraform и Helm в вашем облачном аккаунте. Если вы по какой-то причине решите прекратить его использование, ваше приложение как и раньше продолжит работать на вашем собственном кластере Kubernetes. Вы просто потеряете такие функции, как:
- автоматический конвейер CD;
- автоматическое обновление кластера;
- удобные инструменты для разработчиков (UI, CLI и API);
- среды предварительного просмотра.
Заключение
Heroku уже много лет является стандартным решением для развертывания в облаке. Однако у него есть много недостатков, включая быстро растущие цены и отсутствие детального контроля. Для решения этих проблем появились современные решения, такие как AWS Fargate, Google Cloud Run и Qovery. Вместо того чтобы тратить месяцы на настройку инфраструктуры или непосредственно разбираться со сложностями AWS, вы можете одно из них, что позволит в кратчайшие сроки подключить свой git-репозиторий и начать развертывание приложения.
