Привет, коллеги! Сегодня я отойду от прежнего стиля написания статей. До этого момента я писал больше про хард скиллы, но в последнее время я начал расширять свой кругозор и изучать процессы в компании под разными углами, в том числе с точки зрения бизнеса.
Изначально я хотел выпустить статью по теме непосредственного переезда инфраструктуры (в частности Kubernetes) на собственные сервера. Но всё же более интересно обсудить данные решения на уровне лиц, принимающих решения. В статье я расскажу о своем опыте работы с облаками, как мы в них заезжали и почему все же пришлось мигрировать.
Начало
В начале всего команде нужно иметь возможность быстро масштабироваться по ресурсам, особенно для стартапов. Железо — лишь вершина айсберга. Играет очень много других скрытых факторов, основной из которых — люди.
И все вроде замечательно: дев стенды работают, команда разрастается, расходы на инфраструктуру возрастают.
Когда облако нужно
Зачастую бизнесу нужно аргументировать, в каких случаях облако предпочтительнее on‑prem, а в каких — нет. Ведь кажется, что платить за возможность хостить свои приложения ежемесячно менее выгодно, чем закупить пару стоек один раз и никогда больше не платить.
И тут множество НО: компании бывают разные. Есть стартапы с парой девопсов, есть крупные банки с датацентрами по всему миру и огромным штатом специалистов разных уровней. Выбор нужно делать, учитывая бюджет и множество факторов и рисков.
Вам точно нужно облако, если у вас стартап: вам нужно быстро масштабироваться. Закупать сервера чаще всего плохая затея: можно вложить большие деньги, чтобы затем продукт не выстрелил.
Окей, у нас средняя компания, у которой есть пару лишних серверов. Как было подмечено ранее, железа недостаточно. Нужны специалисты на разных уровнях модели OSI, поддерживающие инфраструктуру. А если мы хотим еще и высокий SLA, то нанимать дополнительных людей для дежурств и смен.
Если хотим SLA еще больше — нужно больше датацентров, желательно в разных локациях и независимых друг от друга. И туда снова нужны люди...
Но нужен ли нам такой SLA? It depends
Когда облако не нужно
У нас налажено свое облако/Нам не нужен высокий SLA/Мы потерпим 500-е ошибки в выходные/Мы не будем тревожить девопса в его отпуск, т.к у нас есть дополнительные человеческие ресурсы.
По моему опыту, переезд из облака на свои сервера происходил на фоне оптимизации затрат, которые включали сокращение команды. Соответственно, нагрузка, которая раньше ложилась на девопса+специалистов облака теперь распределилась между девопсом (в большой перевес) и L1-L4 поддержкой компании, которые возможно с Linux и не работали никогда.
В такой ситуации DevOps всё больше занят текущими операционными задачами, а времени на развитие продукта и улучшение CI/CD‑процессов становится всё меньше.
Тем не менее, если заказчик готов выделить железо и согласен на снижение SLA — это вполне рабочее решение. Особенно в условиях неопределенности, запретов на использование иностранных облаков и растущей монополизации российского рынка (в частности со стороны Яндекса). В этом контексте собственная инфраструктура — способ сохранить автономность и снизить долгосрочные риски.
Как объяснить бизнесу
Метрики. Генерального менеджера не волнует, вы используете кубер или запускаете сервисы через systemd. Объективно оцените по каждому параметру тот или иной способ развернуться, опираясь на финансовые затраты. И как подмечено ранее, учитывайте не только прямые, но еще и косвенные расходы (человекочасы, простой в случае инцидентов, поддержка и обслуживание).
Возможно стоит рассмотреть гибридный вариант — сервисы, которым нужна отказоустойчивость (яркий пример — S3, K8s), можно оставить в облаке, тогда как менее важные — на своих серверах. Обратить внимание стоит еще и на сертификацию облачных провайдеров, которые предполагают хранение персональных данных клиентов и берут ответственность за их защиту.
По моему опыту, компании хотят полностью отказаться от облаков, когда испытывают финансовые проблемы и даже не хотят обсуждать тему оставления части ресурсов в облаке. В таком случае вы или соглашаетесь и берете на себя доп. нагрузку (чаще всего), либо просто покидаете компанию.
Вывод
Универсального рецепта по выбору между облаком и on‑prem нет. Где‑то облако — это спасение, где‑то — неоправданные траты. Всё зависит от задач, ресурсов и зрелости команды. Один и тот же Kubernetes в разных условиях может быть как идеальным решением, так и головной болью.
Важно не цепляться за технологии ради самих технологий. Считать, сравнивать, говорить с бизнесом на понятном языке. И не забывать, что любое инфраструктурное решение — это, в первую очередь, про людей и процессы, а не про YAML и Linux.
