H3LLO CLOUD

Мы даём новым пользователям облачного сервиса огромный приветственный лимит. Он настолько щедрый, что щедрее на российском рынке просто нет. Мы проверяли.

Всё совершенно бесплатно на целый год:

• Две виртуальные машины, у которых 2vCPU и 4 Гигабайта DDR5 у каждой.
• Managed Postgres (тоже 2vCPU и 4ГБ RAM)
• Ещё на 40 GB — сетевой диск, который можно по желанию подключать к любой машине.
• Объектное хранилище на 100 GB.
• + белый статический IP. V4, конечно.

Никто на российском рынке и среди крупных западных облачных хостингов такого объёма не даёт больше чем на месяц. Собственно, из тех, кого мы нашли, — вообще никто.


Скоро мы планируем прикрутить ещё одну фичу — бесплатный доступ к Kubernetes.

• Любой желающий сможет три месяца поиграться с простеньким кластером на один мастер-воркер и понять, что за контейнерами — будущее. Ну или бесплатно сойти с ума.
• А потом получить месяц доступа к продакшен-кластеру. Это полноценный отказоустойчивый кластер, состоящий из трёх–пяти мастер-нод. Тут можно уже развернуться по полной, начать серьёзные продажи, протестировать свои идеи в реальных условиях.

После этого, конечно, бесплатный период закончится. Мы не филантропы, двигающие идею облачного инстанса в массы, мы практичная компания со своей экономической моделью. И, кстати, дешевизной мы не заманиваем: средний чек у нас на уровне тех же Селектела, Яндекса и Сбера.

Мы пришли за вашими деньгами. Но хотим, чтобы вы смогли посмотреть инфраструктуру сами.

Где, собственно, подвох?
Такой большой лимит подходит для того, чтобы вы смогли полноценно поработать с облачным сервисом, ощутить его преимущества. Облачные сервисы мы любим и хотим, чтобы все поняли, насколько они крутые и как с ними нужно работать.

Поэтому построили публичное облако, масштаб которого позволяет решать реальные задачи. Поставили топовые сервера, процессоры Xeon пятого поколения, сети на 400 гигабит, всё это нарезали на виртуальные кусочки и готовы по запросу предоставить клиенту нужную мощность.

Релиз у нас сегодня, если что. До этого тестировали.

И вот эти лимиты: 2 ВЦПУ + 4 ГБ памяти для управляемых баз данных. Они минимум вдвое быстрее тех, что есть сейчас на рынке. Мы протестили.

Это как первая доза бесплатно. Втянетесь в нормальное хорошее облако — будет тяжело съезжать после того, как увидите, насколько оно экономит время в разных местах. И насколько удобно работать с нашим UX, благо мы всё сделали и делаем для того, чтобы экономить ваше время.

Почему две машины? Потому что только так можно поиграть полноценно. Многие берут или дают для теста одну машину. С одной, даже хорошей, вы не наступите на все грабли. Мы даём сразу две, чтобы можно было поднять отказоустойчивую систему.

Важный элемент этой схемы — балансировщик нагрузки. И нет, ящер с картинки наверху не врёт. Балансировщик у нас тоже входит в бесплатный пакет, что обычно встречается только в платных тарифах у других провайдеров.

Всё это для того, чтобы любой пользователь мог сразу и на целый год запустить полноценный продукт. Блог на 10 тысяч посещений, небольшой онлайн-магазин, корпоративный сайт. Это возможность запустить онлайн-проект без покупки железа, без аренды и долгой настройки виртуальных машин.

Мы предоставляем базу данных, так что можно не париться с настройкой Postgres, Mongo или целого кластера, MySQL или ещё чего угодно.

Всё запускается буквально в два клика. И никаких финансовых рисков на старте.

Никакой экономии на хранении: это полноценный прод без деградации. Все диски дублируются трёхкратно, а резервные копии создаются в другой зоне доступности. Даже если один из дата-центров вдруг выйдет из строя, информация останется доступной. Это означает, что ни один сбой не приведёт к потере проекта или базы данных.

Ещё один плюс двух машин — их гораздо легче масштабировать. Если продажи пошли, нагрузка растёт, то к двум можно добавить ещё две, пять, сто… Вся инфраструктура уже готова. И, что немаловажно, это безопасная инфраструктура.

В этом первый подвох: если ваш проект взлетит, то вы захотите масштабироваться. С одной ВМ дальше хотелок дело не пойдёт. С двумя вы сможете всё и сразу — и дадите нам денег.

Вторая история — конечно, со временем, возможно, мы снизим лимиты. Но пока мы можем позволить себе такого рекламного расхода. Машзал со старта облака будет загружен не полностью и не весь, а нагрузка на вычисления — наименьшая часть расходов cash burn. Поэтому, если мы загрузим машзалы хотя бы наполовину бесплатными клиентами с некоторой конверсией (хотя бы 5 %) в рост, это очень быстро приведёт к нашей прибыли. Быстрее, чем другие модели. Мы считали. Мы любим считать и любим теорию игр.

В процессе расчётов мы пришли к выводу, что переподписка, когда один физический ресурс распределяется между несколькими пользователями, может быть эффективной, если тщательно настроить баланс нагрузки. Мы будем использовать её только для бесплатных демохостов, чтобы оптимизировать ресурсы на старте. А для постоянных клиентов ресурсы выделяются индивидуально: так мы исключаем риск, что одновременный высокий спрос приведёт к перегрузке и испортит работу сервиса.

Про белый IP
Надо сказать пару слов про деньги и ограничения законодательства.

У нас простая регистрация: достаточно электронной почты и номера телефона, причём второе — даже не наше требование, а Минцифры. Поэтому легко предположить, что кто-то со второй симки, например, захочет получить вторую пару бесплатных серверов. Или через год зарегистрирует новый аккаунт, чтобы снова сидеть бесплатно.

Есть две системы. Первая — финансовая. Для того чтобы получить бесплатные лимиты, нужно пополнить счёт. Там немного, тысяча рублей минимум, но от спама одноразовыми аккаунтами это защищает. И, что важно, это не плата за бесплатный пакет (как звучит-то!). Эти деньги останутся на счёте, ими можно будет оплачивать дополнительные услуги. А при пополнении на пять тысяч рублей активируется полный набор лимитов, включая белый IP. Это защищает нас от массовых фейковых регистраций: случайный пользователь вряд ли будет заводить десятки аккаунтов и замораживать на них деньги, пусть и небольшие.

Вторая — нейросеть, которую мы уже обучаем (на базе Tensor Flow). Она анализирует контрольные суммы, имена образов и другие параметры, чтобы выявлять повторные регистрации и попытки обойти ограничения. И если кто-то, исчерпав бесплатный лимит, запустится с нового аккаунта, то мы это, вероятно, увидим.

Ещё аспекты
Мы строим облако очень поздно по сравнению с другими. Это минус по возможной доле рынка, но плюс по тому, что можно не повторять неэффективные шаги.

Мы сразу же ушли от оверхеда технологий. Помните историю про неповоротливость и уязвимость OpenStack — платформы, на которой сидят почти все российские облака? Так вот: это не про нас. Мы OpenStack попробовали, оценили и сразу отказались, написав в итоге свою платформу на Go с парой ключевых обработок на Scala.

У нас очень продуманная команда, и, вероятно, мы сможем сохранить это преимущество ещё пару лет. Небольшая оптимизированная команда, где каждый на своём месте и эффективно закрывает свой сектор, — одна из причин, по которым мы можем давать такие жирные приветственные лимиты. О других расскажем чуть позже.

Единственная сфера, в которой мы отходим от принципа «один человек — одна задача», — это безопасность. Site Reability Engineering, Network Operation Center и инженеры по безопасности у нас работают в несколько смен, поэтому мониторинг ситуации и техподдержка — круглосуточные. И если заметим подозрительную активность, то не будем сразу отключать клиента, как большинство провайдеров. Попробуем разобраться, свяжемся с самим клиентом. Хотя стопроцентно этого обещать не могу: ландшафт ИБ меняется каждый день. Но постараемся.

Чтобы не ловить детские косяки типа ненастроенного файрволла, у нас есть внешние утилиты «обстукивания». Если, например, у вас открыты небезопасные настройки или база данных без пароля, то мы предупредим об этом.

У нас очень хороший старт на собственных активах (без кредитов). Про старт я подробно рассказывал вот тут, если кратко: была майнинг-ферма — непрофильный актив, который нужно было переоборудовать во что-нибудь более интересное. А майнинг-ферма — это не только доступ к дешёвому электричеству, но и большое количество производительных видеокарт. Располагалось всё это добро далековато от Москвы, в Александрове, так что мы решили заняться облаком. Особенно после того, как побегали по территории с пистолетами, потому что асиков было на миллиард.

Плюс два ЦОДа в Москве в аренде.

Закупили самое новое оборудование. Есть дата-центры мощнее нашего, глобальнее — у Яндекса, например. У нас сейчас стоят процессоры Xeon пятого поколения, как только в продаже появятся шестые — сразу купим. Это серьёзное преимущество: у других облачных сервисов — в среднем третье поколение, а оно в несколько раз слабее. И, что важно, для той же мощности нам нужно меньше физических серверов, а следовательно, и места. Больше вычислений на стойку, а расходы у ЦОДов идут именно на стойку.

Ещё один наш бонус — продуманный цикл жизни железа. Многие другие ЦОДы создавались годами, там огромное количество техники, и разом её заменить… ну, наверное, можно. Но потребуется бюджет, сопоставимый с бюджетом небольшого региона. Это как в авиации: когда выходит новый двигатель, надо менять весь парк. Весь парк менять невозможно, поэтому новые компании эффективнее уже имеющихся. А уже имеющиеся продают самолёты в Африку.

Отработав свой срок в клиентском сегменте — там, где важна производительность, сервер переедет в ванну на другие задачи. Туда, где процессор и память менее важны. За пределы Москвы в ЦОД с более дешёвой стоимостью поддержания стойки на задачи по фактическому потреблению типа инференса. И продолжит приносить пользу, плавая в диэлектрической жидкости. Иммерсионное охлаждение позволяет тратить меньше электричества, а компактная команда из 30 человек делает обслуживание бизнеса дешевле.

Про иммерсию я ещё расскажу отдельно, она прямо очень сильно меняет правила игры. Если у вас ЦОД приспособлен под неё. У нас приспособлен.

Что делать, если придёт большой клиент и надо будет освобождать машзал?

Ничего. Докупим железа. Если придёт условный Озон или Вайлдбериз — мы потянем. Не моментально, не по клику: потребуется докупить оборудования, настроить поддержку. Это не повлияет на бесплатные лимиты.

Но наша ЦА — не такие гиганты, а российский топ-1000. Давайте представим, например, Тануки. У них, кстати, отличные ИТ, если что. Вот 100 таких компаний мы прямо сейчас можем включить по клику, и даже на постоплатной системе. То есть без авансов, без всего, просто приходите, пользуйтесь — по истечении месяца заплатите.

Мы можем предоставить клиентам принципиально новые инструменты и возможности, помочь вывести бизнес на другой уровень. Кстати, неважно, физическое вы лицо или юридическое, мы можем работать и с карточками, и по электронному документообороту с выставлением счетов.

Сейчас мы уже собрали три сотни заявок на платную подписку. И ожидаем, что очень быстро добьём до тысячи: числа говорят сами за себя.

К лету мы планируем масштабировать бизнес: приедет новое оборудование, которое разместим уже на базе iXcellerate. Когда закончим основные работы, у нас будет достаточно мощностей, чтобы без проблем завести почти любого клиента. Если у других провайдеров ресурсы ограничены — у нас с этим проблем нет. Хотите масштабировать интернет-магазин? Легко. Запускаете крупный корпоративный проект? Потянем. Мы не просто расширяем инфраструктуру, а создаём площадку, где бизнес сможет расти без ограничений.

Вот здесь можно забрать.
limits.h3llo.cloud

Вот в этом подвох. Мы хотим, чтобы вы почувствовали себя неожиданно хорошо и подсели.

Если вдруг вам по какой-то противоестественной причине интересно наблюдать за реалити-шоу «айтишники против всего мира», то вот наш телеграм-канал, в котором рассказы, как мы строим это облако и какие грабли уже нащупали.

Главный прикол с k8s: поднять базовый кластер займёт всего 15 минут. А вот чтобы он реально заработал, ответить на все вопросы перед установкой, всё спланировать — на это нужны дни, реально дни мозгового штурма и планирования. Ну или потом придётся разбирать и делать ещё раз. Несколько раз.

Кубер унижает человеческое достоинство разными способами и на разных этапах. Это часть опыта от пользования продуктом. Так задумано.

И вот про эти самые вопросы мы сейчас и поговорим, потому что там целое волшебное поле грабель.

Начнём с простых вещей, например, выбора дистрибутива, выбора способа хранения данных (и динамического выделения места), а также того, куда складывать пароли к критичным ресурсам. На этих трёх выборах ломается примерно 50 % админов.

Поехали в ад!



Архитектура

Kubernetes — это кластер. То есть много серверов, которые работают вместе. Эти серверы называются нодами, или узлами. Есть ноды управляющие (Control Plane). Раньше их звали Master, но сейчас это слово немодное, так что Control Plane. А есть ноды рабочие (Worker Nodes) — вот на них-то и крутятся ваши приложения в контейнерах (точнее, в подах).

Рядом с Control Plane живёт etcd. Это распределённая база данных (ключ-значение), где Кубер хранит всю инфу о себе и о том, что в нём запущено: какие поды, какие сервисы, какие конфиги — вот это всё. Она тоже обычно распределена по нескольким управляющим нодам для надёжности. Для полной надёжности её ставят отдельно.

Работает это так: вы пишете файл с конфигом, который описывает условия и состояния, например: «Хочу такой-то деплой из стольких-то подов, чтобы он при таких условиях вёл себя так, а при таких — вот так». Эти правила хранятся в etcd, а Control Plane следит за их исполнением. Если есть разница между тем, как надо, и тем, как есть, — всё приводится в нужное состояние. То есть что-то грохается или добавляется. Автоматически.

Казалось бы, всё просто, но тут огромная кроличья нора.

Дело — в условиях и работе приложений. Чтобы прописать нормальные условия для работы кластера, придётся вытащить наружу кучу метрик изнутри ваших приложений. Потому что более-менее доступные условия «из коробки» — это, например, «Если нагрузка на процессор больше 80 % 10 секунд подряд», а не «Если я записываю в базу данных быстрее чем за 0,1 секунды, и очередь — меньше 1 000 событий».

То есть вам надо будет продумать внешнюю сигнализацию своим приложениям, чтобы отдельные контейнеры могли сообщать внешнему миру о своём состоянии. Например, когда они перегружены, недогружены или что-то ещё.

Вторая особенность — вам надо обеспечить правильное поведение приложения при добавлении-убавлении контейнеров. Это касается транзакций (надо корректно закрываться после обработки транзакции, а не терять её), записи на диск и так далее.

С диском — тоже отдельный сюрприз: мышление придётся изменить. Но давайте по порядку.

Если у вас планируется реально большой, нагруженный кластер, то Control Plane и особенно etcd лучше выносить на отдельные, выделенные ноды. Не надо на них вешать рабочую нагрузку, пусть они занимаются только управлением. У себя на деве или стейдже мы можем и совмещать, чтобы экономить ресурсы, но на проде лучше делить. В наших собственных продуктах на dev-части мы совмещаем узлы, а на прод-части создаём два отдельных контура.

Почему это проблема?



Потому что это унижает человеческое достоинство. Просто знайте: то, что у вас поначалу не всё получается, — это нормально. Это часть процесса. Так задумано. Вот как сталкивались с этим наши участники команды разработки:

• Начинаешь с Kubernetes — вроде всё понятно по верхам, курс прошёл, потыкал. Гугл и AI помогают. Но потом лезешь глубже: драйверы для хранилищ, autoprovisioning, сети… и это просто стена! Понять базово — это одно, а настроить под себя — совсем другое. Нужны или огромный опыт, или куча времени, чтобы просто сидеть и ковыряться. Настроить выход наружу? Тоже целая история с кучей нюансов: часто просто копируешь решения, не до конца понимая.
• Написать код — быстро. А вот развернуть его в Кубере первый раз — это дни мучений! Сертификаты, связь между сервисами, настройка Argo CD с ключами — всё совершенно неинтуитивно. Если рядом нет опытного DevOps, который проведёт за ручку, то это просто взрыв мозга и боль: не понимаешь, за что страдаешь! Но когда наконец всё настроишь, думаешь: «Боже, как же хорошо! Теперь только так и буду работать! Только, пожалуйста, пусть кто-нибудь другой развернёт сам Кубер, я этого больше не хочу!»
• Пытаешься соединить внутренние сервисы Кубера с внешним миром — и тут начинаются танцы с бубном. Куча технологий, и все — на разной стадии готовности.
• Самое сложное в начале — просто понять, как вообще работать с Kubernetes. У тебя не запускается простой сайт в Docker-контейнере, а DevOps объясняет проблему терминами Кубера, и ты даже не понимаешь, как это отладить, куда смотреть. Потом тебе дают конфиг для kubectl и говорят: «Разбирайся сам». Ощущение, будто тебя выкинули с лодки посреди озера: плыви!

Что ставить
Это классика жанра для новичка. Открываешь доку Кубера, а там бац — десяток способов установки! И хрен поймёшь, какой тебе нужен.

Дальше можно гуглить «Kubernetes Hard Way» и «Kubernetes Simple Way»: там статьи разной степени упоротости. Поскольку на дворе — XXI век, можно попросить помочь и LLM, но это будет step-by-step-воспроизведение одной из этих двух инструкций.

Третий путь — пойти к облачному провайдеру и там найти managed-service для k8s, обычно выглядящий для пользователя как волшебная кнопка «Создать кластер Kubernetes». Жмакнули, подождали минут 10–15, и вам вываливается файлик с конфигом. А дальше наступает ступор. Смотрите на этот файлик и думаете: «Ну зашибись, а дальше-то что?»

Мой личный совет: прежде чем лезть в облака или мучиться со своими серверами, поставьте себе на ноут Minikube. Это такая песочница, маленький Кубер на одной машине. Погоняйте его, потыкайте палочкой, разберитесь с базовыми понятиями: что такое Pod, Service, Deployment — вот это всё. Освойте kubectl — это главная команда для общения с кластером. Вот когда вы через это пройдёте, тогда и Managed Service в облаке станет в разы понятнее, и вы будете знать, что делать с этим загадочным admin.conf.

Итак, вариантов три с половиной:

• Managed Service в облаке (типа нашего H3LLO CLOUD) — это когда вы приходите к провайдеру, говорите: «Хочу Кубер», нажимаете пару кнопок (ну или не пару: всё зависит от упоротости провайдера), получая готовый кластер и kubeconfig. Плюсы: не надо париться с установкой и обновлением управляющих нод (Control Plane, etcd): всё это — головная боль провайдера. Масштабирование нод — часто «из коробки»: настроил правило, и если нагрузка растёт, то провайдер сам добавит виртуалок в ваш кластер. Автоматическое выделение persistent volume любого размера в любом количестве — тоже на провайдере, как и LoadBalancer для внешнего доступа. Минусы: зависимость от провайдера, его ограничений (про них ещё скажу) и его ценовой политики.
• На своих серверах (Bare Metal) или своих виртуалках. Полный контроль над железом, над софтом, над настройками. Делайте что хотите. Но на вас падает вся сложность установки, настройки, обновлений, бэкапов. Масштабировать кластер новыми серверами? Только ручками: пошёл, купил сервер, поставил в стойку, настроил, добавил в кластер. Никакой магии.
• Руками в облаке на виртуалках: можно, но зачем? Если очень хочется поковыряться в кишках, но своего железа нет. Или если Managed-сервис чем-то критично не устраивает (например, версией Кубера или доступными опциями). По сути, это то же самое, что и Bare Metal, только серверы арендованные. Вся сложность — ваша, но хотя бы серверы покупать не надо.

Последний способ — запустить отдельный контейнер в контейнерном хостинге типа нашего L1VESTACK. Тут вообще от платформы и серверов полностью абстрагируемся. Но это скорее для быстрого решения текущей задачи, а не для того, чтобы правильно настроить Кубер.

Как ставить

• Kubeadm — официальная утилита от создателей Кубера. Но это, как я говорю, «путь самурая». Все команды — ручками, все конфиги — ручками, бутстрэп каждой ноды — ручками. Если вы не мазохист и ставите Кубер первый раз — не советую категорически: намучаетесь и проклянёте всё на свете.
• Kubespray — это наш выбор для своих инсталляций на железе или виртуалках. Это, по сути, набор готовых Ansible-сценариев. Он автоматизирует 90 % рутины по развёртыванию кластера на куче нод. Есть неплохие статьи, как его подготовить и запустить. Очень рекомендую начинать именно с него, если вы решили ставить сами и уже выросли из Minikube. Очевидный плюс — в дальнейшем удачный конфиг можно многократно воспроизвести.
• Экзотика — есть и другие штуки, часто привязанные к специфичным ОС. Например, для Talos OS есть свои утилиты — Talos CTL (ручками) и talm (типа Helm, но для Талоса). Интересные вещи, но это уже для тех, кто в теме.

На какую ОС ставить ноды

• Есть обычные Linux — старая добрая Ubuntu, CentOS, Debian, и всё это прекрасно работает. Привычно, понятно, куча доков в сети.
• Специализированные ОС — есть дистрибутивы, заточенные специально под контейнеры и Кубер. Это Fedora CoreOS / Flatcar Container Linux: часто у них read-only — корневая файловая система для безопасности, атомарные обновления. Но есть нюансы: например, FCOS вместо привычного cloud-init использует свой формат конфигов — Ignition. Надо разбираться, как его готовить (там есть ещё утилита Butane). Talos — ещё более хардкорный вариант. Там вообще нет привычной ОС с shell! Всё управляется через API. Максимальная безопасность, минимализм. Но требует полного переосмысления подхода к управлению хостами.

Если нет особых требований к безопасности или специфике, то начинайте с обычной Ubuntu LTS — не ошибётесь.

Container Runtime

• Docker (точнее, dockershim) — до недавнего времени был стандартом де-факто. Сейчас его официально выпилили из Кубера, но многие дистрибутивы и инсталляторы по-прежнему его поддерживают через прослойку. Если у вас нет веских причин для другого — можно начать с него: он самый привычный.
• Containerd — а вот это стандарт де-факто сейчас, поддерживаемый Кубером напрямую через интерфейс Container Runtime Interface. Кстати, Docker сам под капотом использует containerd, так что переход на него обычно безболезненный. Большинство новых инсталляций использует именно его.
• CRI-O — ещё реализация CRI, разрабатываемая Red Hat. Тоже хороший вариант.
• Есть и совсем специфичные вещи типа Kata Containers (запускает контейнеры в легковесных виртуалках для изоляции) или Kubevirt (позволяет запускать полноценные ВМ внутри Кубера). Но это уже для особых случаев.

Рекомендация: начинайте с containerd. Это сейчас мейнстрим.

Хранение
Вот это критически важный вопрос, если у вас не только stateless-вебморды, но и базы данных, очереди, кэши — всё, что должно переживать перезапуск и падение подов.

Сразу забудьте про использование локальных дисков на нодах для хранения важных данных в продакшене! Нода умерла — данные пропали.

То есть данные должны быть размазаны по кластеру или храниться в выделенном отдельном хранилище.

Кубер для работы с хранилищами использует стандартный интерфейс Container Storage Interface. Это позволяет подключать к нему самые разные системы хранения данных — как локальные, так и сетевые.

Базовое решение Ceph — очень популярное, мощное и надёжное распределённое хранилище. Наш опыт показывает, что это отличный выбор. Его можно развернуть отдельно, а можно прямо внутри Кубера с помощью специального оператора Rook. Rook сам поднимает все компоненты Ceph (мониторы, OSD на дисках нод) в виде подов и делает его доступным для Кубера через CSI. Мы у себя часто используем именно связку Ceph + Rook.

Всё это работает так. У вас есть приложение, работающее в контейнере внутри Kubernetes K8s. Этому приложению, например, базе данных, нужно место для хранения данных — скажем, пять гигабайт. Создаётся PVC (Persistent Volume Claim). Это как заявка на диск. Кубер понимает запрос и обращается к системе хранения данных (например, Ceph) через autoprovisioning с командой: «Создай диск на пять гигабайт». В Ceph создаётся блочный диск (RBD) и выделяется Куберу в виде его сущности PV (Persistent Volume). И уже этот PV подключается к поду.

Ceph — это распределённая система хранения, которая обычно устанавливается на те же серверы (узлы), где работают и сами контейнеры (сейчас мы — про Bare Metal). Она объединяет диски этих серверов в единое большое хранилище.

Хотя компоненты Ceph (например, процессы, управляющие отдельными дисками — OSD) могут запускаться в своих управляющих контейнерах (часто — с помощью инструмента Rook), сама система хранения тесно связана с физическими дисками и серверами. Когда контейнер падает, диск в Ceph остаётся. Когда падает целый сервер, данные сохраняются. Система не хранит всех данных на одном диске или узле: при записи копии данных «размазываются» по разным дискам на разных серверах. Мы сами выбираем, какой уровень репликации установить. Ceph автоматически обнаружит потерю OSD и начнёт перераспределять данные по оставшимся рабочим дискам, чтобы восстановить нужный уровень избыточности.

Если контейнер поднимется на другой машине после перезапуска, то новый экземпляр контейнера просто подключится к тому же самому постоянному тому (Persistent Volume), который был создан для него в Ceph. Данные на диске никуда не делись. Управление самим кластером Ceph — тоже отказоустойчиво. Есть специальные процессы-мониторы и манагер с репликами в режиме standby. Если сервер с главным манагером выходит из строя, то управление автоматически переходит к другому манагеру на другом сервере.

Конечно, система не неуязвима. Если выйдет из строя слишком много серверов или дисков одновременно, так, что оставшегося места не хватит для хранения всех данных или их реплик, или если не останется достаточно узлов для поддержания кворума управления кластером, то Ceph может перестать работать или перейти в состояние «Только для чтения». Там лучше разбираться руками.

В целом нет ничего хуже, чем развал кластера. В этой ситуации придётся долго и весело танцевать с бубном, если у вас не настроены итеративные бэкапы.

Ещё варианты:

• LinStor — ещё одно распределённое хранилище, и тоже с CSI-драйвером. Говорят, может быть производительнее Ceph в некоторых сценариях. Тоже достойный вариант.
• Если вы в облаке, то у провайдера есть свои CSI-драйверы для их блочных хранилищ (Amazon EBS, Google Persistent Disk, Azure Disk, etc.). Обычно это самый простой вариант в облаке. Причём их можно смешивать для разных условий и для разных типов данных.
• Более экзотичные GlusterFS, локальные диски через Local Persistent Volumes (только для специфичных задач!) и куча других вариантов.

Вы можете определить разные «классы» хранения (StorageClass), например, fast-ssd, slow-hdd, cloud-premium. А потом в манифесте для вашего приложения (в PersistentVolumeClaim) вы просто указываете имя нужного класса. Кубер через CSI-драйвер сам создаст диск нужного типа в соответствующем бэкенде (Ceph, облако, etc.). Это позволяет абстрагироваться от конкретной реализации хранилища.



Сеть
Если диски ещё более-менее понятны, то тут спотыкаются даже опытные админы. Сеть в Кубере — это, пожалуй, одна из самых сложных тем. Вам точно понадобятся хотя бы базовые знания сетей (IP-адресация, маршрутизация, файрволы).

Kubernetes создаёт свою собственную виртуальную сеть поверх вашей физической (или облачной) сети. Каждый под (контейнер) получает свой IP-адрес в этой виртуальной сети. И поды, запущенные на разных физических нодах, должны иметь возможность общаться друг с другом по этим виртуальным IP. Чтобы эта магия работала, нужно выбрать и установить CNI-плагин (Container Network Interface). Это такой софт, который и отвечает за настройку сети для подов. Наши фавориты:

• Cilium — очень мощный и быстрый плагин. Он использует новомодную eBPF прямо в ядре Linux, что даёт ему производительность и кучу фич (сетевые политики, шифрование, балансировка). У Cilium есть ещё крутой инструмент Hubble — это UI и CLI для визуализации сетевых потоков и зависимостей между сервисами. Супервещь для отладки, мы его любим.
• Calico — тоже очень популярный и зрелый плагин. Часто идёт по умолчанию во многих инсталляторах (например, в Kubespray). Умеет работать как с оверлейными сетями (VXLAN, IPIP), так и без оверлея, используя BGP-маршрутизацию, если ваша сеть это поддерживает. Тоже отличный выбор.
• Flannel (простой, для начала неплох).
• Weave Net, Antrea и куча других, в том числе специфичных для облаков (AWS VPC CNI, Azure CNI, GKE Netd).

В зависимости от выбранного CNI и вашей инфраструктуры вам может потребоваться разбираться с BGP, VXLAN, IPIP-туннелями, настройкой маршрутов и файрволов. Сеть — это то место, где можно застрять надолго. Как сказал один наш сетевик, когда разбирался с какой-то проблемой: «По идее должно быть так, но хрен его знает, иди копай». Эта фраза будет преследовать вас примерно везде по мере реализации.

«Я запустил Nginx в поде, как мне его открыть в браузере?»

В Кубере есть специальная штука — Service. Это абстракция, которая даёт постоянный IP-адрес и DNS-имя для группы подов (например, для всех реплик вашего веб-сервера) и умеет балансировать трафик между ними.

Типы сервисов:

• ClusterIP: сервис получает внутренний IP, доступный только изнутри кластера. Для внутренних бэкендов — самое то.
• NodePort: сервис открывает порт на каждой ноде кластера. Вы можете обратиться на IP_любой_ноды:NodePort и попасть на сервис. Неудобно, небезопасно, порты надо выбирать из определённого диапазона. Для продакшена — фу.
• LoadBalancer: вот это уже интереснее. Если вы в облаке, то при создании сервиса такого типа облачный провайдер автоматически создаёт вам внешний облачный балансировщик (ELB, Google LB, etc.), назначает ему публичный IP и направляет трафик на ваш сервис (точнее, на его NodePort на нодах). Очень удобно! А что делать, если у вас свой кластер на железе (Bare Metal)? Облачного балансировщика нет. Тут на помощь приходит MetalLB. Это такой специальный контроллер, который эмулирует облачный LoadBalancer. Вы выделяете ему пул IP-адресов из вашей локальной или публичной сети (если вы крутой и имеете свою публичную сеть), и когда создаёте сервис типа LoadBalancer, MetalLB берёт свободный IP из пула и «анонсирует» его в вашей сети (обычно через ARP или BGP), чтобы трафик на этот IP приходил на ноды вашего кластера. Обязательная штука для Bare Metal!
• Есть еще ExternalName, который использует DNS с кастомными параметрами, но даже в официальной доке предупреждают, что для некоторых протоколов типа http(s) могут быть проблемы. Мы его не используем.

Ingress — стандарт для публикации веб-приложений (HTTP/HTTPS) в продакшене. Ingress — это не тип сервиса, это отдельный ресурс в Кубере. Он работает как умный реверс-прокси или «входные ворота» для внешнего трафика. Он позволяет рулить трафиком на разные сервисы внутри кластера на основе хоста (например, api.mysite.com -> сервис API, blog.mysite.com -> сервис блога) или пути (mysite.com/app1 -> сервис App1, mysite.com/app2 -> сервис App2). Ingress также обычно отвечает за TLS-терминацию (SSL-сертификаты).

Чтобы Ingress заработал, вам нужно установить Ingress-контроллер. Это, по сути, и есть тот самый реверс-прокси, который читает Ingress-ресурсы и настраивает себя соответствующим образом. Самый популярный — Nginx Ingress Controller: знакомый многим Nginx, но специально заточенный под Кубер. Мощный, гибкий. Но! Будьте осторожны: недавно в нём находили неприятные уязвимости, позволяющие читать секреты из кластера. Это к важности своевременных апдейтов. Из других хороши HAProxy Ingress, Traefik (очень популярен, умеет сам получать Let's Encrypt-сертификаты), Contour и другие.

Настроить Ingress, сертификаты, DNS — это тоже задача не на пять минут. А если обратиться к официальной документации, то она рекомендует идти не в Ingress, а в Gateway API. Тут может показаться, что надо начать с него, и даже есть классные GUI для Gateway API, и хорошо бы ими воспользоваться! Но погодите )

Gateway API — это относительно новая спецификация в Кубере, которая со временем должна заменить или дополнить Ingress. Она более гибкая, позволяет разделять ответственность по маршрутам для разработчиков. Выглядит перспективно. Но я бы пока советовал не лезть в экзотику типа Kong Gateway. Да, у него есть красивый UI, что подкупает в мире консольного Кубера. Но он ломает саму идеологию Кубера с его декларативными манифестами в etcd и использует другую логику представлений. Лучше освоить стандартный Ingress с Nginx или Traefik, а к Gateway API присматриваться постепенно по мере накопления опыта. Есть реализации на базе того же Nginx, Envoy (Istio, Contour), HAProxy. Если разбираться с Gateway API, то лучше начать с них.

Кусок информационной безопасности
Пароли от баз данных, ключи к внешним API, всякие токены — ни в коем случае нельзя хардкодить в коде приложения (если кто-то ещё так делает и не был распят) или пихать прямо в YAML-манифесты! Этим вы создаёте огромную дыру в безопасности.

Для этого в Кубере есть специальные объекты:

• Secrets — для хранения чувствительных данных (пароли, токены, TLS-сертификаты). Они хранятся в etcd в base64 (что не шифрование!), но Кубер предоставляет механизмы для их шифрования «at rest» и контроля доступа к ним через RBAC.
• ConfigMaps — для хранения нечувствительной информации конфигурации (URL’ы, параметры, конфиг-файлы целиком).
• Продвинутый уровень: можно интегрировать Кубер с внешними системами управления секретами, например, HashiCorp Vault, с помощью специальных инструментов (Vault Agent Injector, External Secrets Operator). Это даёт централизованное управление, ротацию секретов и т.д.

Вы можете «подсунуть» данные из Secrets и ConfigMaps вашему приложению как переменные окружения для контейнера или как файлы, смонтированные в определённую директорию внутри контейнера.

Конечно, ваше приложение должно быть готово к этому. Оно должно уметь читать конфигурацию и секреты из переменных окружения или из файлов по указанным путям, а не из своего config.ini, лежащего рядом с бинарником. Часто это требует доработки кода приложения.

Но идеальный сценарий — это когда, например, кластер Cassandra создаётся автоматически через оператор типа k8ssandra, и приложение берёт креды для доступа из секрета, созданного оператором при запуске кластера. Ни в БД, ни в приложение ручками их никто не прокидывает.

Аутентификация и авторизация
В вашем кластере наверняка будут работать разные люди: DevOps/SRE, разработчики команды А, разработчики команды Б, может быть, QA-инженеры… Кто может деплоить приложения, кто может смотреть секреты, кто может удалять ноды?

• Аутентификация. Сертификаты X.509, токены (статичные, JWT, через OIDC-провайдера типа Keycloak или Dex), интеграция с LDAP/AD.
• Авторизация (RBAC — Role-Based Access Control). Вот это — самое главное. RBAC позволяет очень гибко настроить, что (какие действия: get, list, create, update, delete) с какими ресурсами (pods, services, secrets, nodes, etc.) в каких неймспейсах (или во всём кластере) и кто может делать (какой пользователь, группа или сервисный аккаунт). Вы создаёте Роли (Roles) или Кластерные Роли (ClusterRoles), где описываете набор разрешений. Затем вы создаёте Привязки Ролей (RoleBindings) или Кластерные Привязки (ClusterRoleBindings), чтобы связать роль с конкретным пользователем, группой или сервисным аккаунтом.
• Namespaces: используйте неймспейсы для логической изоляции ресурсов разных команд, проектов или окружений (dev, stage, prod). Это помогает упорядочить кластер и упрощает настройку RBAC (роли можно создавать внутри неймспейса). Хотя для окружений более правильно и эффективно использовать разные кластеры (опять же привет, облака).
• Золотое правило — минимальные привилегии. Давайте пользователям и сервисным аккаунтам только те права, которые им реально необходимы для выполнения их задач. Не надо всем раздавать cluster-admin: это прямой путь к катастрофе.

Observability
Вот мы и приехали к той самой волшебной части. Работать с кластером Kubernetes без настроенной системы мониторинга и логирования — это посадить админом слепого котёнка.

Метрики:

• Нужен Metrics Server — это базовый компонент (обычно ставится аддоном), который собирает основные метрики использования ресурсов (CPU, RAM) с нод и подов. Он нужен как минимум для работы kubectl top и базового HPA.
• Стек Prometheus + Grafana — это де-факто стандарт для сбора, хранения и визуализации метрик в мире Кубера. Prometheus — это база данных временных рядов, которая сама опрашивает метрики с разных источников (ноды, поды, сервисы). Grafana — инструмент для построения красивых дашбордов на основе данных из Prometheus (и не только).
• Приложения должны сами отдавать метрики в формате, понятном Prometheus (обычно это текстовый формат по HTTP-эндпоинту /metrics). Не только CPU/RAM, но и специфичные для приложения: количество запросов в секунду, время ответа, размер очереди, количество ошибок, бизнес-метрики. Без этого ваш мониторинг будет неполным.

А я предупреждал )

Логи:

• Контейнеры в Кубере обычно пишут логи просто в stdout и stderr. Эти логи собираются движком контейнеров (containerd/docker) и доступны через kubectl logs. Но смотреть логи каждого пода по отдельности — это ад.
• Нужен централизованный сбор логов. Необходимо настроить агентов (например, Fluentd, Fluent Bit, Promtail), которые будут бегать на каждой ноде, собирать логи из файлов или напрямую от движка контейнеров и отправлять их в центральное хранилище.
• Популярные варианты хранилищ логов — Elasticsearch (в составе стека ELK/EFK: Elasticsearch + Logstash/Fluentd + Kibana) или Loki (от создателей Grafana, хорошо интегрируется с Prometheus, обычно используется в стеке LGTM: Loki + Grafana + Promtail).

Это, кстати, значит, что логи должны быть структурированными, чтобы их было легко парсить и искать по ним. Вероятно, тут вам ещё раз придётся вернуться к разработке приложения и навести порядок в том, как оно кладёт логи под себя.

Трассировка. Если у вас микросервисная архитектура, то один запрос пользователя может проходить через десяток разных сервисов. Чтобы понять, где именно возникла задержка или ошибка, нужна распределённая трассировка. Инструменты: Jaeger, Zipkin, Tempo.

Конечно, приложения должны уметь принимать и передавать дальше специальные заголовки (trace ID, span ID) и отправлять информацию о своих операциях (спанах) в коллектор трейсов. Это тоже требует доработки кода.

Масштабирование
Ну что, база есть, доступ настроен, всё видно. Теперь можно и фишками обмазаться.

Устали поднимать руками и настраивать PostgreSQL, Kafka, Redis, Elasticsearch в Кубере? Следить за их состоянием, бэкапами, обновлениями? Для этого придумали операторов. Оператор — это, по сути, ваш кастомный контроллер внутри Кубера, который знает, как управлять определённым типом сложного приложения. Он расширяет API Кубера с помощью Custom Resource Definitions.

Работает это так:

• Вы устанавливаете CRD для, скажем, PostgreSQL. Теперь Кубер знает о новом типе ресурса, например, PostgresCluster.
• Вы устанавливаете сам Оператор PostgreSQL (это обычное приложение, работающее в поде).
• Вы создаёте простой YAML-файл, где пишете — kind: PostgresCluster, name: my-db, spec: { replicas: 3, version: «15», storage: «fast-ssd» }.
• Применяете этот YAML (kubectl apply-f).
• Оператор видит, что вы создали новый ресурс PostgresCluster, и начинает действовать: создаёт нужные StatefulSets/Deployments, заказывает диски (PersistentVolumeClaims) нужного StorageClass, настраивает сервисы для доступа, конфигурирует репликацию, может настроить бэкапы и мониторинг — в общем, делает за вас всю грязную работу по развёртыванию и поддержке сложного stateful-приложения.

Существует огромное количество готовых операторов от сообщества и вендоров для баз данных, очередей, мониторинга, CI/CD — да чего угодно! Это очень мощный механизм расширения Кубера. Для совсем уж специфичных внутренних систем можно даже написать свой оператор (но это уже высший пилотаж).

Автомасштабирование — одна из главных фишек Кубера, ради которой его часто и внедряют.

• Горизонтальное автомасштабирование подов (HPA — Horizontal Pod Autoscaler) — самый частый и полезный вид. Вы создаёте HPA-ресурс и говорите: «Хочу, чтобы количество реплик моего приложения my-app было от двух до десяти, и чтобы оно масштабировалось, если средняя загрузка CPU по подам превысит 70 % (или RAM, или кастомная метрика из Prometheus, например, длина очереди)». Кубернейтс сам будет следить за метриками и автоматически добавлять или удалять поды my-app в указанных пределах.
• Вертикальное автомасштабирование подов (VPA — Vertical Pod Autoscaler). Менее популярный, но тоже бывает полезен. VPA анализирует реальное потребление ресурсов подами и может автоматически изменять requests и limits по CPU/RAM в манифесте пода. Чаще используется в режиме «рекомендаций», чтобы понять, сколько ресурсов реально нужно приложению. Использовать VPA вместе с HPA нужно осторожно: они могут конфликтовать.
• Масштабирование кластера (Cluster Autoscaler). Это уже про добавление и удаление целых серверов (нод) в кластер. Работает так: если в кластере появляются поды, которые не могут никуда запланироваться (состояние Pending) из-за нехватки ресурсов (CPU, RAM) на существующих нодах, то Cluster Autoscaler замечает это и автоматически заказывает у облачного провайдера новую ноду (или несколько), ждёт, пока она не поднимется, и добавляет её в кластер. Поды тут же планируются на неё. И наоборот: если Cluster Autoscaler видит, что какие-то ноды долгое время недозагружены и все их поды можно переместить на другие ноды, то он может автоматически удалить эти лишние ноды, чтобы сэкономить деньги. Это главная фишка облачных Managed Kubernetes. Там это обычно работает «из коробки». Если у вас свой кластер — на железе или виртуалках, то заставить Cluster Autoscaler работать можно, но сложнее. Нужно использовать Cluster API. Это такой проект, который позволяет управлять жизненным циклом кластеров Kubernetes (в том числе создавать и удалять ноды) с помощью самого Kubernetes. Cluster API имеет провайдеров для разных инфраструктур (vSphere, OpenStack, AWS, Azure, Bare Metal через Tinkerbell/MAAS). Но это отдельная большая тема.

Кстати, тут надо передать пламенный привет некоторым российским облакам. У них часто есть довольно смешные лимиты на максимальное количество нод в одном Managed-кластере: где-то — 100 (привет, ТаймВеб), где-то — вообще 32 (Яндекс). А Кубер, на минуточку, сам по себе спокойно тянет 5 000 нод в кластере и 150 тысяч подов и даже не поперхнётся (по официальным тестам). У ВК вроде лимит побольше — 500 нод, у Сбера — 249 (хотя в доке пишут, что 500). Всё равно не 5 000. У нас в H3LLO CLOUD мы постарались эту проблему решить и даём возможность строить реально большие кластеры, близкие к максимальным возможностям Кубера.


Думаете, это конец?
Нет, это начало.

Развернули кластер, настроили сеть, сторадж, мониторинг? Поздравляю! Вы прошли… ну, скажем, разминку.

• Короткий анонс. Приложения должны быть готовыми жить в динамичной эфемерной среде Кубера. Почитайте про 12-factor app — это мастхэв. Приложение должно:
• Читать конфиги и секреты из окружения или файлов (никаких локальных config.xml!).
• Писать логи в stdout/stderr (а не в файлы!).
• Быть максимально stateless (состояние хранить во внешних базах, кэшах, хранилищах).
• Быстро стартовать.
• Корректно обрабатывать сигналы SIGTERM для graceful shutdown.
• Уметь отдавать метрики для мониторинга (health checks, readiness/liveness probes).
• Быть упаковано в легковесный Docker-образ.

Вам нужны конвейеры, которые будут автоматически:

• Собирать Docker-образы вашего приложения при коммите в Git.
• Пушить образы в Docker Registry (типа Harbor, GitLab Registry, Docker Hub).
• Обновлять YAML-манифесты (Deployments, StatefulSets, Services, Ingresses) с новой версией образа.
• Деплоить эти манифесты в Kubernetes (например, с помощью kubectl apply, Helm, Argo CD, Flux).
• Проводить тесты после деплоя.
• Обеспечивать лёгкий откат на предыдущую версию.

Инструментов для этого — море: Jenkins, GitLab CI, GitHub Actions, Tekton, Argo CD, Flux…

В идеальном розовом мире единорогов ваши разработчики вообще не должны знать слова «Kubernetes». Они просто пишут код, коммитят в Git, а дальше некая «платформа» сама всё собирает, тестирует и выкатывает куда надо. Нажал кнопку — получил фичу в проде. Достичь такого уровня абстракции — это Грааль платформенного инжиниринга. Это требует не только зрелого Кубера со всеми обвесами, но и глубокого понимания ваших приложений, процессов разработки и кучи инструментов поверх Кубера (часто это называют Internal Developer Platform). Это долгий и сложный путь.

А оно вообще того стоит? Если у вас реально сложная, большая, динамичная система, которая должна быть отказоустойчивой, масштабироваться под нагрузкой, часто обновляться без простоя, то однозначно — ДА, стоит. Головной боли на старте будет много, но потом вы получите такие гибкость, скорость и надёжность, которых другими путями добиться очень сложно, если вообще возможно. Вы реально сможете выкатывать фичи быстрее и спать спокойнее (но это неточно).

Если вы прочитали всё это и подумали: «Мама дорогая, да я в этом никогда не разберусь!», но при этом фишки Кубера вам нужны — не отчаивайтесь. Есть решения, которые берут на себя большую часть этой боли:

• L1VESTACK или другой контейнерный хостинг — тут мы пошли по пути максимального упрощения: полностью спрятали оркестратор под капот. Вы просто даёте нам свой docker-compose.yaml (да-да, прямо его!) или используете наш простой CLI — и ваше приложение магическим образом разворачивается и работает на нашей инфраструктуре. Вообще не надо думать ни про ноды, ни про сети, ни про стораджи, ни про Ингрессы, ни про RBAC. Просто код и деплой. Идеально для тех, кто хочет «просто чтобы работало». Естественно, нет фишек инфраструктуры для продвинутых, потому что вы запустили контейнер, который работает.
• H3LLO.CLOUD — на нашей платформе есть Managed Kubernetes. Здесь мы не прячем Кубер полностью, но берём на себя самую нудную и сложную часть: бутстреппинг, Control Plane, etcd, обновления базовой системы, обеспечение работы сети и хранилища, предоставляем автомасштабирование нод «из коробки». Вам всё ещё нужно понимать основные концепции Кубера (поды, сервисы, деплойменты) и уметь пользоваться kubectl, но основную инфраструктурную рутину и сложность мы снимаем. Это хороший баланс между контролем и удобством.

Что почитать или посмотреть

• Для старта — Minikube.
• Запуск Кубера без заморочек — kubespray.
• Концепции Кубера из первоисточника — курим доку. Начать лучше с туториала, а потом читать Concepts и Tasks.
• Хорошая книга — Production Kubernetes. Есть на русском.
• Глубже по сетям — Networking and Kubernetes.
• Тоже есть на русском.
• GUI для Кубера — Lens
• The Twelve-Factor App

Жирнющие бесплтаные лимиты на облачные сервисы на целый год, включая Managed Kubernetes — H3LLO.CLOUD.

Не менее щедрые лимиты на платформу для запуска приложений в контейнере — L1veStack.

beta.h3llo.cloud
h3llo.cloud

В феврале мир разработки перевернулся с выходом Sonnet 3.7. Потому что вдруг внезапно оказалось, что джуны уже не очень-то и нужны. И нейросетка нормально заменяет мидлов тоже.

Я откидываюсь в кресле, беру наушники и смотрю, как работает LLM. Можно сразу несколько, работающих над разными частями проекта:


Пример проекта с прикручиванием аналитики к инфраструктуре:

• Сначала в GPT 4.5 провёл продуктовые исследования и сформулировал требования.
• Попросил превратить это в архитектурный план.
• Отревьюил, поправил тупые ошибки.
• Затем этот план (как метапромпт) скормил Sonnet в VS Code через плагин Cline. Попросил сначала создать общую структуру, шаблонные имплементации, документацию, спецификации API (protobuf для gRPC, REST API).
• Архитектурно сразу заложил микросервисы. Sonnet для каждого сервиса подобрал и обосновал оптимальную базу данных (где-то Postgres, где-то ClickHouse и т.д.).
• Сгенерировал SDK для взаимодействия, примеры использования. Сразу заложил observability: централизованные логи, метрики Prometheus, трейсинг Jaeger/Tempo, дашборды для Grafana.
• Потом итерационно генерировал код: сначала тесты (End-to-end, BDD), потом имплементацию под эти тесты.
• Написал манифесты для Kubernetes и Docker Compose для локального запуска.
• Сгенерировал даже скрипты для тестов REST API через curl и gRPC через gRPCurl.

И всё.

А теперь практика — что делать с тем, что современные нейросети учились преимущественно на говнокоде и как быть с джунами.
Качество LLM-кодинга сильно зависит от языка программирования
Главная проблема — объём блока (точнее, зависимостей) и нормальная обучающая выборка.

Scala
Попытки написать на Scala работающий микросервис по OpenAPI-спецификации провалились.

Модель генерирует код, он не компилируется. Скармливаешь ошибки компиляции — следующая итерация кода содержит ещё больше ошибок.

Вероятно, это высокая сложность и неоднозначность языка Scala (функциональный стиль, множество способов сделать одно и то же) плюс, вероятно, меньшая и менее качественная обучающая выборка по сравнению с другими языками.

Попытки транслировать код с другого языка (например, с Go) в Scala тоже могут быть проблематичны, особенно если требуется сохранить функциональный стиль Scala — на понятиях PHP, например, такое просто не опишешь.

Скала очень недетерминирована, её стиль отличается от мейнстримовых других языков достаточно сильно, а кодовая база не очень большая. В итоге LLM для сложных проектов на практике пока непригодны.

Golang
Совершенно другая история. Современные модели генерят на Go очень хороший, часто компилирующийся из коробки код. Скорее всего, работает комбинация факторов:

• Go — очень квадратно-гнездовой язык. Задачу чаще всего можно решить одним, максимум двумя способами. Нет такого разброса стилей и подходов, как в Scala или даже JS. Это упрощает обучение для LLM: меньше вариативность «правильных» ответов на один и тот же запрос. Эта прямолинейность отличается от C, который хотя и прост на первый взгляд, как автомат Калашникова, но позволяет легко «провалиться» на низкий уровень, иногда незаметно. Go тоже позволяет уйти в сторону ассемблера, но при решении стандартных задач он очень явно описывает путь.
• Строгая стандартизация. Встроенный форматер (gofmt), линтеры (golint), общепринятые конвенции — всё это делает кодовую базу на Go очень однородной. Это лучше, чем в Python, где тоже есть линтеры, но вариативности в написании больше. В Go сама идея языка была в том, чтобы код легко читался всей командой.
• Качественная и большая обучающая выборка. Огромное количество успешного Open Source написано на Go (Kubernetes и вся его экосистема, Docker, Prometheus, Terraform и т.д.). Вероятно, этот код использовался для обучения моделей с высоким весом, возможно, даже с усилением (как если бы Википедию добавили в базу 10 раз).
• Меньше «говнокода». Возможно, Go — язык более молодой, его чаще выбирают уже более опытные разработчики для серьёзных проектов (это сейчас слабое допущение). В отличие от Python или JS, куда порог входа ниже и больше новичков, генерирующих код не самого высокого качества, который тоже попадает в обучающие выборки. Плюс сам язык Go меньше прощает ошибок и не провоцирует написание «кривого» кода так, как это делает, например, JS. Сам язык как бы «не предусматривает» говнокода в той же мере.
• Почему мы сами выбрали Go — бинарники маленькие, памяти ест мало, работает быстро. Хотя и PHP последних версий тоже компилируется, но это отдельный спор. До сих пор, кстати, не утих другой холивар — можно ли считать PHP языком программирования или нет. Я придерживаюсь мнения, что можно. Но пишем мы преимущественно на Go.

Rust
Тоже хайповый современный язык. LLM генерят код, который проходит проверку синтаксиса в IDE. Но при попытке сборки (которая в Rust сложнее, чем в Go) вылезает куча ошибок. И вот с исправлением этих ошибок сборки LLM справляются хуже, чем с написанием изначального кода или исправлением ошибок в Go. Вероятно, дело опять же в сложности языка и, возможно, пока ещё менее репрезентативной выборке кода с решёнными проблемами сборки.
Экспериментировали мы не очень много.

Java
Самая интересная ситуация, показывающая принципы LLM-кодинга.
Проблема — в структуре типичного Java-проекта: там везде глубокая вложенность пакетов, сложные цепочки наследования. Чтобы понять, что происходит в одной функции, LLM нужно проанализировать много связанного кода.
Это требует огромного окна контекста: меньше 64к токенов — почти бесполезно для серьёзного Java-кодинга. К счастью, модели с большими окнами появились.
Ещё нужны агенты для исследования кодовой базы. Инструменты вроде Cursor, Cline позволяют LLM «ходить» по проекту. Но и тут проблема: системный промпт агента (который сам по себе может быть большим, на тысячи токенов), прочитанные файлы классов и интерфейсов, дерево проекта — всё это быстро забивает даже большое окно контекста, особенно учитывая, что в Java много мелких лексем (точки, скобки), каждая из которых — токен.
То есть сама структура проектов на Java такая, что нужно не только смотреть тот блок, где сейчас идёт редактирование, но и держать «в голове» вообще всё то, что происходит в зависимостях. Это, кстати, причина тех самых мемов про состояние потока программиста. Вот у LLM то же самое.

Идеальное решение (которого пока нет в массовом использовании) — агенты, способные хранить состояние проекта в долговременной памяти, а не только в текущем окне контекста. Тогда LLM сможет «помнить» всю структуру и историю изменений. Сейчас же каждый новый агент начинает почти с нуля.
Сравните с Go: там часто достаточно контекста одного файла + импортов, чтобы понять, что происходит. Добавьте нашему вымышленному программисту не только отвлекающие звонки, но и болезнь Альцгеймера, чтобы он забывал задачу каждые 15 минут, — и вы получите примерное представление о LLM-кодинге на Java.

JavaScript
Динамическая типизация, язык многое прощает, разные стили, потенциально огромное количество некачественного кода в обучающей выборке. LLM сложнее строить логические цепочки, одна и та же лексема может иметь разный смысл.
TypeScript показывает заметно лучшие результаты благодаря статической типизации.

Регулярные выражения
В целом LLM пишут их неплохо. Но из-за того, что регулярки состоят из очень маленьких лексем (часто одиночных символов), а модели часто работают с ненулевой «температурой» (параметр, отвечающий за креативность/случайность ответа), они могут быстро начать «галлюцинировать» и вставлять не те символы, ломая логику выражения. С математикой тоже бывают проблемы, хотя современные модели умеют подключать внешних «экспертов» или писать код для вычислений, это не всегда работает идеально.

Про Python рекомендую вот эту публикацию.
github.blog/news-insights/octoverse/octoverse-2024/



Что получается
Для Go-проектов и ряда других LLM уже применимы на уровне мидлов, которые хорошо кодят, но которым надо давать точное техническое задание.

От разработчика нужны глубокие архитектурные знания и умение делать качественное ревью, иначе никак.

Если это есть и он готов выступать тимлидом LLM-агентов, то эффективность растёт в разы.

Разработчик общается с LLM так же, как раньше с джунами — ставит задачу, проверяет, корректирует.

Рутинные задачи, написание бойлерплейта, стандартных функций — всё это автоматизируется. Время освобождается. Фокус смещается с написания строк кода на архитектуру, декомпозицию задач, правильную постановку технического задания, которое теперь превращается в промптинг.

Код-ревью становится важнее: генерируемый код нужно внимательно читать.

Понимание архитектуры и умение читать чужой код становятся критически важными.

Меняется структура команд: потребность в джунах, которые в основном занимаются рутиной, снижается. Мидлы должны быстро расти до уровня Middle+, способных работать с архитектурой. Сильно растёт ценность Senior и лидов, способных грамотно ставить задачи и контролировать результат.

Результат: проект, который силами небольшой команды делался бы минимум месяц до начального рабочего состояния, у нас был собран за три дня. Ещё примерно столько же ушло на ревью (в том числе по ИБ), ручное тестирование крайних случаев и подготовку к продакшену. Затраты на токены — около 150 $.

Уверенность в коде? После моего ревью — высокая. Если сравнивать сгенерированный код до ревью с кодом джуна до ревью — уверенности в LLM-коде у меня больше. Он сразу пишет с учётом observability, тестов, лучших практик (если правильно попросить), даже с интеграцией токенов для защиты вызовов. Джуна этому ещё учить и учить.

Но это не освобождает от финального ручного ревью и тестирования крайних случаев, чтобы убедиться в отсутствии явных дырок, особенно в части информационной безопасности. Но пока тесты, которые генерируются в нашем флоу на этапе описания и документации, дырок не оставили.

Правильное техническое задание становится самой дорогой и важной частью.

Пайплайн «задача -> реализация» у нас уже радикально упростился. При обсуждении фич мы меньше зависим от опыта конкретного разработчика в конкретной технологии. Нужно интегрировать Cassandra? Не проблема, даже если у человека нет 5 лет опыта с ней. LLM выдаст «курс молодого бойца», поможет спланировать интеграцию, сгенерирует код. Разработчик контролирует процесс, вносит правки с учётом специфики нашего Go-кода. Стек стал гибче. Мы можем выбирать лучшие технологии под задачу, не ограничиваясь текущими знаниями команды. LLM помогает быстро вкатиться и интегрировать. Разработчик при этом получает реальный опыт с новыми инструментами.

Практическая скорость выросла, по нашим оценкам, примерно вдвое.

За один спринт (две недели) команда делает то, что раньше заняло бы месяц, и это при работе над новым проектом с нуля. Создать новый микросервис по образу и подобию существующих? Даёшь LLM пример, и он генерирует всю обвязку. Остаётся наполнить бизнес-логикой.

Время разработчиков перераспределилось: меньше совещаний (экономия оценивается примерно в 8 часов за две недели на человека), так как синхронизироваться по архитектуре нужно меньше.

И давайте ещё раз: меньше совещаний. Это важно. Синки только по необходимости.

Освободившееся время уходит на ревью, продумывание сложной логики и тот самый «вайб-кодинг» — параллельную работу, где на одном экране код генерит LLM, на другом — правишь или пишешь сам, потом меняешься ролями для ревью. Работа становится более «дирижёрской». Даже DevOps-задачи частично можно переложить на LLM (генерация Dockerfile, K8s-манифестов).

Но есть и проблема контроля. Иногда тяжело ограничить место изменений. Просишь LLM поправить что-то в одном конкретном месте, пишешь «только здесь, только это», но нет гарантии, что он не затронет что-то ещё в другом файле или модуле.

Интересно, что даже размер микросервиса теперь может определяться не только бизнес-контекстом, но и размером контекста LLM — микросервисы стали де-факто стандартом, потому что с ними LLM справляются легче.

Как мы теперь нанимаем
Мы требуем уметь хорошо кодить руками на входе.

LLM — это мощнейший ускоритель, но он не заменит фундаментального понимания принципов разработки, алгоритмов, структур данных, архитектуры. Без этого вы не сможете ни правильно поставить задачу LLM, ни адекватно оценить и отревьюить результат.

Про джунов есть опасения. Возможно, входной барьер в профессию станет выше — придётся больше учиться самостоятельно, на пет-проектах, прежде чем сможете претендовать на позицию, где ваши навыки постановки задач и ревью будут востребованы.

Этап джуна придётся проскакивать на тренировках, а не на реальных проектах.

Сам промпт-инжиниринг из области заученных лайфхаков превратился в умение сформулировать задачу. Модели достаточно развились, чтобы понимать свободные формулировки. Осталось только внести в них смысл — ради смысла и нужен профессионал. Нужно декомпозировать задачу, учесть все нюансы: версии библиотек и фреймворков (сказать: «Next.js», не уточнив App Router vs Pages Router — получить не то), протоколы взаимодействия (не указать gRPC — получить HTTP по умолчанию), конкретные требования к архитектуре, базам данных, безопасности.

Промптинг становится итерационным. Мы часто сначала генерируем верхнеуровневую архитектуру (например, в Markdown), правим её руками. Потом генерируем схемы взаимодействия между микросервисами (Protobuf, GraphQL, OpenAPI, SQL DDL) — это становится критически важным шагом, и только потом используем эту схему как часть промпта для генерации кода самих сервисов. Потом — документацию. Потом генерируем тесты (интеграционные тут особенно важны). Потом — структуру файлов и сигнатуры функций с комментариями. И только потом — сам код.

У новых людей меняется отношение к коду. Он становится расходным материалом, а не домашним питомцем — если что-то пошло не так, часто проще откатиться, доработать промпт и сгенерировать заново (иногда и 10 раз), чем пытаться исправить сложный баг в машинном коде.

Ценность навыка написания кода снижается в пользу навыка чтения чужого кода. Однако и тут есть нюанс: после оперативного запуска нового кода ценность смещается в сторону знания кодовой базы. И именно этот фактор делает разработчиков незаменимыми (вспоминаем про bus factor, которого боятся все инвесторы).

Тим О'Райли недавно написал отличную статью о том, как меняется кодинг. Его мысль перекликается с нашими наблюдениями: LLM — это следующий уровень абстракции после фреймворков. Если раньше многие разработчики использовали фреймворк, не до конца понимая, как он работает «под капотом», то скоро появится целый класс специалистов, которые будут «просить LLM сделать», не зная деталей реализации. Программирование как навык и как бизнес ждут серьёзные трансформации в ближайшие 5–10 лет. Да, похожие вещи говорили с появлением BASIC и других высокоуровневых языков, и это нормально — каждая такая революция меняла ландшафт.

Как реагируют программисты? Похоже, сообщество разделилось на несколько групп, как отмечалось в Wired. Первая группа верит, что разработчики будут не нужны. Вторая считает LLM продвинутыми стажёрами, верит в рутину, но не верит в понимание. И реалисты — видят усилитель возможностей и личной эффективности. Мы скорее относим себя к реалистам. LLM не убьёт профессию, но сильно её изменит. Мир разработки переживает переломный момент, и важно адаптироваться. Работы не становится меньше, она становится другой.

beta.h3llo.cloud
h3llo.cloud

Вам станут доступны бесплатно на год:

• 2 виртуальных машины с 2 vCPU и 4 ГБ RAM
• 40 ГБ сетевого диска
• объектное хранилище на 50 GB
• белый статический IPv4

Запускаем последнее в России коммерческое облако. Успейте войти в число бета-тестеров и на целый год мы предоставим не только большой объем бесплатных ресурсов, но и скидку до 90% на все сервисы.



beta.h3llo.cloud

Мы тут запускаем последнее в России коммерческое облако, и один из побочных эффектов этого процесса — настраиваем тесты всех конкурентов, чтобы понимать объективную картину. Прошлый тест был про переподписку ядер процессора, и он вызывал нехилое такое пригорание пятой точки у суперпереподписанного Таймвеба (хотя по цене за производительность они оказались вполне в порядке).

Так вот, нашу подсеть уважаемый конкурент забанил, чтобы было неповадно их тестировать. А затем, похоже, подкрутил тесты для наших машин так, что они показали скорость света.

Облака в тесте:

• Selectel.
• Cloud.ru.
• Timeweb.
• VK.
• Yandex.
• Rostelecom.
• H3LLO.CLOUD.

Коротко о результатах


Radar chart по трём показателям: производительность, стоимость к производительности и задержка инвертированная. Больше площадь — лучше

• Timeweb показал одну из самых низких производительностей, но при этом снова хорошую цену за единицу вычислений.
• VK Cloud и Яндекс оказались аутсайдерами: и производительность не впечатляет, и стоит дорого. У Яндекса есть ограничитель на максимальную производительность.
• Потом вы просили добавить нас в тесты, чтобы потом можно было предъявить, если что, и мы добавили. Нам надо было установить цену для своих тарифов, мы взяли её как медианное значение между Cloud.ru и Selectel.

Нельзя просто взять и протестировать
Мы не ожидали, что это обернётся почти масштабным научным исследованием, а не простым «запустил и померил». Делов-то было на 20 минут, как казалось вначале. Ну, поставим бенчмарк, запустим скрипт, получим циферки, забабахаем красивые графики. А в итоге погружаешься в какую-то научную диссертацию, где каждое число может быть оспорено, а каждое методологическое решение требует обоснования.

Потому что вы нас немного заклевали за подход «херак-херак и в продакшен» на первом тесте. Хотя он вполне решал свою задачу — оценить производительность связки vCPU-RAM на машинах с одинаковыми характеристиками у разных провайдеров. Или, проще говоря, выяснить, кто же больше охренел )

В общем, методология. Сразу решили не изобретать велосипед и взяли встроенный в PostgreSQL тест pgbench. Он создаёт три таблицы разного размера, которые отличаются друг от друга в 10 и в 100 000 раз по числу записей. Выбрали фактор масштабирования 200, и это дало нам таблицы размером 200, 2000 и 20 миллиона записей. Достаточно, по нашему мнению, чтобы проверить, как облака справляются с нагрузкой.

Главная проблема методологии: если вы запускаете тесты с локального компьютера, то результаты будут зависеть от вашего интернет-соединения. Человек в другом городе с другим провайдером получит совершенно иные цифры. Все тесты запускались с виртуальных машин, которые находились в той же подсети и зоне доступности, что и тестируемые базы данных. Так мы исключили влияние внешних сетей.

• База данных Postgres 16.
• 4vCPU + 16 Гб RAM + 40 Гб SSD (где был выбор между дефолтным флейвором БД и настраиваемым сайзингом, мы выбирали дефолтный флейвор).
• Где был выбор между Ice Lake vs Cascade Lake мы выбирали Ice Lake.
• Без пулинга, репликации и бекапов.
• Без тонкой настройки дополнительных параметров конфигурации Postgres.
• Для бенчмаркинга выбрали стандартный pgbench, который входит в состав Postgres.
• Для минимизации времени отклика pgbench запускался из виртуальных машин находящихся в той же приватной подсети, что и Managed Postgres, без SSL.
• Проводили 4 итерации: 1 разогревочная + 3 фактических.
• Бенчмаркинг проводился в рабочее время.

4 стандартизированных нагрузки pgbench:

• default, «Стандартная нагрузка TPC-B»
• simple_update, скрипт обновляет баланс в таблице `pgbench_accounts`
• select_only, скрипт выполняет выборку данных из таблиц `pgbench_accounts`, `pgbench_branches` и `pgbench_tellers`
• complex_write, скрипт обновляет балансы в таблицах `pgbench_accounts`, `pgbench_tellers` и `pgbench_branches`, моделируя сложную транзакцию

Отказались от использования 2 нагрузок, поскольку по результатам предварительных тестов бенчмаркинга они не добавляли информативности к результатам от уже существующих стандартных тестов, а только удлиняли бенчмаркинг:

• join_heavy: скрипт выполняет соединение таблицы `pgbench_accounts` самой с собой несколько раз, что позволяет оценить производительность при выполнении joins
• insert_with_indexes: скрипт вставляет новую запись в таблицу `pgbench_history` и обновляет баланс в таблице `pgbench_accounts`, что позволяет оценить производительность при выполнении операций вставки и обновления с использованием индексов

Измеряли 2 метрики:

• Количество транзакций в секунду (TPS): Сколько операций база данных может выполнить за одну секунду.
• Время отклика запросов: Сколько времени требуется базе данных для выполнения запроса.

Коэффициент стоимости считался в руб/час/TPS.

Параметры бенчмаркинга:

• scale factor = 200 (это значит что в базе будут 3 таблицы, по 20 млн записей, 2 тыс. записей и 200 записей соответственно).
• Одновременные клиенты базы данных client_counts = [16, 32, 64].
• Рабочие потоки thread_counts = [32, 64, 128].
• run_time одной итерации = 30 секунд.

Всего для каждого провайдера было проведено 108 тестов: 3 различных client_counts * 3 различных thread_counts * 4 типа нагрузки * 3 итерации.

Где только можно, отключали репликацию и пулинг подключений. С пулингом интересный момент: он реально помогает базе данных не захлебнуться при нагрузке, но мы его специально отключали, чтобы увидеть «чистую» производительность самой СУБД без костылей.

В Timeweb такой возможности вообще не было. Так что мы до сих пор не знаем, тестировали мы их с пулингом или без.

Сберклауд и Яндекс просто не дают подключиться к базе извне их экосистемы. То есть, если у вас приложение не в их облаке, вы к своей базе данных подключиться не сможете. Занавес.

Обе этих компании демонстрировали потрясающий user experience — он был совершенно не приспособлен для обычного человека, который достаточно издалека знает, что такое сеть. По-хорошему нужно в этих сценариях с этими провайдерами приглашать нормального сетевика, который вам всё настроит. Если вы не профессиональный сетевой инженер, настроить подключение — это квест уровня «найди все тайные комнаты в Хогвартсе». Причём на старых аккаунтах всё работает совсем не так, как на новых.

На новых всё запускалось предельно плохо, непонятно, с какими-то невнятными ошибками уровня «обратитесь в поддержку, мы не можем что-то создать». Решение такое: старые аккаунты мы не удалили, но убрали из них старые организации и перевоссоздали новые организации в рамках старого аккаунта. И там всё было совершенно иначе. Вообще другой UX.

Таймвеб нас забанил тогда, когда мы начинали тестировать с локальной машины. Несколько раз мы запускали и перезапускали скрипт. Надо сказать, что мы его запускали синхронно с другими провайдерами. И в определённый момент мы увидели странное поведение от Таймвеба. Сначала посыпались ошибки, а потом скрипт сам перестал работать, потом перестал работать сайт Таймвеба с нашего публичного IP )

Мы не делали ничего необычного — просто запускали стандартный pgbench, который создаёт нагрузку не больше, чем обычное приложение. Примерно так интернет-магазин обращается к своей базе данных. На следующий день Timeweb нас разблокировал, и мы попытались запустить тесты уже с виртуальной машины внутри их сети. И тут произошло что-то странное: они сделали что-то со своим кластером managed db, что он вдруг резко стал показывать производительность гораздо выше, чем всё, что у нас было в тестировании — даже выше, чем наш собственный локально размещённый сервер GEN11 на Xeon 6430.

Какую магию они там применили — мы так и не узнали, но решили, что эти результаты слишком подозрительны, чтобы включать их в финальный отчёт. Когда мы попытались повторить тесты, система начала выдавать ошибки. В общем, похоже, это активное противодействие тестам с их стороны. Привет, коллеги. Приходите снова писать в комментарии, какие мы ужасные, только на этот раз не забудьте сразу удалить у пользователя место работы, пожалуйста. А то будет как прошлый раз, когда его сначала заминусовали, а потом через несколько часов он убрал место работы из профиля и внезапно рейтинг восстал из мёртвых за несколько минут )

Ростелеком — наш гомерический смех продолжается! Их мы вообще исключили из теста. Потому что снова бюрократия. Мы не смогли запустить облако. Потому что база данных до сих пор на согласовании у их менеджера.

Казалось бы, 21-й век. Но нет, Ростелеком продолжает жить в эпохе «ждите звонка менеджера». Я готов предположить, что они так сделали для того, чтобы избежать потока людей с непонятной репутацией.

Результаты
Зависимость скорости транзакции к задержке


Количество транзакций в зависимости от соединений


Количество транзакций в секунду по типам нагрузки


Кривая распределения по совокупности тестов всех вместе. Чем выше верхняя группа точек, тем лучше и больше вероятность получить более высокую скорость транзакции


Отношение стоимости к производительности


Распределение количества транзакций в секунду


Среднее количество транзакций по провайдерам


Средние задержки по провайдерам


По результатам тестов явно выделились два лидера: Клаудру и Селектел с практически идентичными показателями. Разница между ними была в пределах статистической погрешности.

ВК Cloud оказался примерно на 30–40% ниже лидеров. Это, кстати, полностью коррелирует с нашими предыдущими тестами виртуальных машин на Geekbench — похоже, у ВК просто железо послабее.

С Яндексом получилась совершенно абсурдная ситуация. Как только мы пытались подключить 64 клиента — тесты валились с ошибками. Мы просто не могли провести полноценное тестирование, отрезав весь верхний диапазон производительности. Как это интерпретировать? Да никак. Как будто вы пришли тестировать машину на автодроме, а вам говорят: «Извините, больше 60 км/ч ехать нельзя, у нас такие правила».

У большинства хостингов кривая выходит на плато или даже падает при увеличении числа соединений. А у нас для сравнения — практически линейный рост — то есть чем больше клиентов подключается к базе, тем выше общая производительность. Мы не ожидали такого эффекта. Железо действительно решает!

В результате по цене — Timeweb, несмотря на низкую абсолютную производительность, выглядит довольно неплохо. Они компенсируют технические ограничения привлекательной ценой. Как я уже говорил, VK Cloud и Яндекс — производительность не впечатляет, стоит дорого.

Среднее количество транзакций. Мы уверенно обходим всех. По цене получилось 9 тысяч рублей за кластер в месяц. Возможно, имеет смысл перетестить его )


Дисклеймер

Важный момент: все тесты мы проводили только в рабочие дни и только в дневное время.

Никаких ночных или выходных измерений.

Ограниченное количество конфигураций тестов: 3 варианта thread counts и 3 варианта client counts, только 1 вариант scale factor. Фиксированная конфигурация — тестировалась только одна конфигурация CPU/RAM/SSD (4vCPU + 16 Гб RAM + 40 Гб SSD).

Есть влияние факторов, не зависящих от работы сервиса Managed Postgres, таких как сетевая задержка, переподписка, колебания нагрузки в рабочее время у разных провайдеров. Мы минимизировали сетевые задержки за счёт проведения теста на виртуальных машинах в той же зоне доступности и подсети, что и тестируемый сервис Managed Postgres. Тесты выполнялись параллельно, где это было возможно, чтобы минимизировать влияние времени суток на нагрузку на инфраструктуру облачного провайдера; там, где было невозможно обеспечить параллельность, мы выполняли тест в другие дни в примерно одинаковое время суток.

Длительность исследования (несколько дней) и продолжительность итерации (30 секунд) могут быть недостаточны для выявления снижения производительности в долгосрочной перспективе. Мы включили 3 итерации для статистической значимости плюс 1 предварительная прогревочная итерация.

Не принимаются во внимание кастомные модификации в конфигурациях Postgres, которые могут иметь место у различных провайдеров.

Итого: тест — не измерительный инструмент, а ориентир! Результаты стоит рассматривать как примерный подход. Если вы выбираете хостинг для своего проекта, лучше провести собственное тестирование с учётом специфики вашей нагрузки.

Все скрипты и материалы нашего исследования мы выложили на GitHub, чтобы любой желающий мог воспроизвести результаты или провести свои тесты по той же методологии.

h3llo.cloud
auth.h3llo.cloud/register

Контейнер — это типа виртуальной машины, только меньше и другое. Несколько контейнеров запускаются внутри одной машины и разделяются друг от друга.

Это значит, что можно запустить приложение с одним набором зависимостей, а рядом — второе с другим. Это значит, что можно сохранить все связки приложения, упаковать его в контейнер и деплоить где угодно — и знать, что оно точно запустится. Есть нюансы с переходом между ARM-архитектурой и x86, но в целом контейнеры универсальны.

В контейнерной упаковке огромное количество софта, в том числе очень много опенсорса. Можно поднять готовый контейнер с сервисом из хаба без проблем вообще. И это не создаёт сложных взаимозависимостей. Нужен PostgreSQL? Docker pull postgres — и он у вас.

К контейнерам монтируются свои ресурсы — диски, сети, конфиги и секреты.

Контейнеры оплачиваются за потребление, то есть можно сделать сервис, который слушает порт и делает обработку, повесить и забыть. За год вы заплатите рублей 20.

Рои контейнеров могут масштабировать крупные корпоративные проекты, про это ниже.

И, наконец, никакой современный CI/CD почти не делается без контейнеров. Системным администраторам, DevOps-инженерам, разработчикам и СТО критически важно разобраться в контейнеризации.

Это будущее, и у этого будущего довольно странная кривая обучения. Сейчас коротко расскажу, попробуем разобраться, как её лучше проходить и где там грабли. Ну и ещё, если вы дойдёте до середины, ваша зарплата будет 450 тысяч рублей в месяц и выше.

Короткая вводная
Раньше всё было просто: есть админы, которые настраивают серверы, и есть разработчики, которые пишут код. Между ними как будто была стена, через которую разработчики кидали админам сборку софта, а админы в обратку кидали проблемы с деплоем и рантайм-эксепшены.

А теперь границы размываются. Разработчики должны понимать, как их код будет жить в продакшне. Админы должны уметь автоматизировать развёртывание. СТО нужно планировать архитектуру с учётом масштабирования и отказоустойчивости.

И здесь на сцену выходят контейнеры — технология, которая объединяет эти миры. Но чтобы в 2025 году оставаться в игре, нужно не просто знать, что такое Docker. Нужно понимать всю экосистему — от простейших контейнеров до оркестрации в Kubernetes и интеграции с нейрокодингом.

Сначала у нас были физические серверы — железки, которые занимали целые стойки. Хочешь новое приложение? Покупай новый сервер. Нужно больше мощности? Апгрейдь железо.

Потом пришла виртуализация и изменила правила игры. Теперь на одном физическом сервере можно запустить несколько виртуальных машин с разными операционками. Это был прорыв: меньше железа, больше гибкости, лучше утилизация ресурсов.

Но виртуализация принесла и свои проблемы. Каждая виртуалка — это полноценная операционная система со всеми потрохами. Это гигабайты дискового пространства, сотни мегабайт оперативки только на старте и заметное время запуска.

Виртуалки — штука классная, но у них есть несколько серьёзных ограничений:

• Проблемы масштабирования. Допустим, у вас «чёрная пятница» и нагрузка выросла в три раза. С виртуалками у вас два пути: либо увеличить ресурсы существующей машины (ресайз), либо клонировать её. Оба варианта требуют времени и дополнительной настройки.
• Сложности с зависимостями. Представьте: у вас на одном сервере два приложения. Одному нужна Java 8, другому — Java 11. С виртуалками решение одно: две отдельные виртуалки. Это лишние ресурсы и головная боль с администрированием.
• Неэффективное использование ресурсов. Каждая виртуалка жрёт ресурсы даже в простое, потому что крутит полноценную ОС. Это как держать заведённую машину на парковке.

Разница между виртуализацией и контейнеризацией

Здесь важно понять ключевую разницу в подходах.

Виртуальные машины — это «домашние питомцы». Вы их поднимаете, называете по имени, заботитесь об их здоровье, бьётесь над их аптаймом. Вы знаете их всех в лицо, все ваши восемь виртуалок. Стараетесь, чтобы они прожили как можно дольше.

Контейнеры — это «стадо». Вы не знаете их по именам, их может быть сотни. Один упал — и ладно, поднимется другой. Это нормально, если за рабочий день вы запустите и грохнете пару сотен контейнеров.

Жизненный цикл виртуалки рассчитан на месяцы и годы. Она копит проблемы и болезни, как старый человек. Контейнеры же могут жить минуты или часы, а потом уступить место свежему контейнеру с новой версией кода.

Собственно, именно так контейнеры чаще всего и используются.

Существует даже кейс с очень коротким жизненным циклом контейнера: за 1–2 секунды поднимается контейнер, отрабатывает запрос, умирает. Это крайне удобно. Так делают на платформах приложений и в CI/CD-pipeline.

Контейнер — это изолированный процесс, которому кажется, что он запущен в отдельной системе. Но на самом деле он использует ядро хостовой ОС. Для изоляции контейнеры используют не возможности железа (как виртуалки), а возможности ОС — так называемое пространство имён. Например, Docker использует cgroups в ядре Linux.

Виртуалка весит гигабайты, контейнер — мегабайты. Postgres в контейнере (без нагрузки) — всего 9 мегабайт оперативки. Девять! Это просто смешно по сравнению с полноценной виртуалкой.

Виртуалки запускаются минуты, контейнеры секунды.

Но самое главное — портативность между различными средами. «У меня локально работает, а на проде — нет». С контейнерами такое почти исключено. Запаковали приложение в контейнер, и оно будет работать одинаково, что у вас на ноуте, что на тестовом сервере, что в продакшне.

Допустим, у вас типичная система из веб-сервера, приложения и базы данных. Описав всё это в Docker Compose файле, вы можете одной командой поднять всю инфраструктуру на любой машине.

Чтобы было удобно разворачивать контейнеры в разных средах, образ заливается в репозиторий (публичный или приватный), и тянется оттуда. Не надо ручками раскидывать образ на хосты — они сами стянут его из репы. Существуют миллионы готовых образов и создавать их с нуля не надо.

Вот почему они такие крутые.

Первые шаги: знакомство с Docker’ом

Сначала вы не понимаете, зачем нужен Docker и все эти статьи на Хабре про него. Скачиваете его из любопытства, долго пытаетесь разобраться, как создать свой первый контейнер. Потом замечаете, что запустить Postgres в Docker — это мизинцем левой ноги, когда в обычной установке это адская головная боль.

Docker и GUI к нему (Docker Desktop) можно поставить и на Linux, и на Mac, и на Windows. Для начала работы достаточно знать несколько команд: docker run, docker build, docker ps, docker stop. Не пугайтесь — это проще, чем кажется. Чуть-чуть покурить обучение на Ютубе или официальный get started — и вот у вас появляется первый контейнер.

Порог входа обманчиво простой.

Дальше идёт работа с образами и репозиториями — Docker Hub и прочие Container Registry. Docker Hub — это как GitHub, только для контейнеров. Там уже есть готовые образы для большинства популярных программ.

Первый Dockerfile можно написать за 10 минут. Это просто текстовый файл с инструкциями: откуда взять базовый образ, какие команды выполнить при сборке, что запустить. LLM сейчас отлично умеют генерировать Dockerfile — это ваш первый помощник.

Обычно с Docker знакомятся так: когда вы инди-хакер с одной виртуалкой в облаке, контейнеры вам, возможно, и не нужны. Момент истины наступает, когда:

• Бизнес начинает расширяться.
• Проект превращается во что-то более крупное.
• Вы обновляете приложение несколько раз в день.
• В команде появляется больше 3–5 разработчиков.

Дальше идёт описание многокомпонентных систем в Docker Compose. Docker Compose позволяет описать в одном YAML-файле целую инфраструктуру: несколько связанных контейнеров, их сети, тома для хранения данных. Одна команда — и всё поднимается автоматически в нужном порядке.

Но до этого вас ждёт ещё пара ответвлений в дереве развития навыков.

Podman как альтернатива Docker. Со временем вы узнаёте, что Docker — не единственный вариант. Podman, например, не висит постоянно в памяти. Можно даже сделать алиас, alias docker=podman, и забыть, что у вас на самом деле не Docker.

Podman хорош для простого докерного опыта, но если нужен Docker Compose — это фича исключительно докеровская (хотя последние Podman уже поддерживает Docker Compose через плагины).

По мере того как вы и ваш проект растёте, вы начинаете задумываться об оркестрации.

Продвинутый этап: мультихостовые решения и CI/CD
Когда контейнеры на одной машине уже не справляются, вы смотрите в сторону кластеров и автоматизации.

Самое главное — контейнеры упрощают CI/CD. До контейнеров CI/CD был про скрипты, которые что-то собирают, тестируют и куда-то выкладывают. Контейнеры всё упростили: среда сборки такая же, как среда запуска. Куча головных болей с зависимостями просто исчезла.

CI-системы могут собирать контейнеры в чистой среде, гарантируя, что никакой левый код не попадёт в продакшн. Вы просто пушите изменения в репозиторий, а CI автоматически собирает новый образ. Дальше CD раскатывает его по разным окружениям.

Это управление образами и их версиями. Для каждой версии вашего кода создаётся отдельная версия образа. Хотите откатиться? Просто укажите предыдущую версию. Никаких сложных процедур отката.

Docker Swarm обычно выступает как первая попытка оркестрации. Docker Swarm кажется логичным продолжением Docker — всё-таки от тех же разработчиков.

Вы в нём пытаетесь что-то сделать, плюётесь и думаете: «Хорошо, видимо, судьба ведёт в Кубер».

И в этот момент контейнеры ломают вас об колено.
Установить «настоящий» Кубер (тот, что в репозитории github.com/kubernetes/kubernetes) ужасно сложно. Тут возникает развилка: либо пользоваться облачными Managed Kubernetes, либо использовать упрощённые дистрибутивы вроде k3s, k0s, Minikube или Kind.

Дело в том, что в k8s вообще другой подход к тому, что кажется логичным. Он очень дружелюбен. В основном, как кажется поначалу, к шизофреникам. Но по мере того, как вы научитесь думать контейнерами, всё станет очень логичным и понятным. Возможно.

В Kubernetes базовая единица — не контейнер, а pod. Это такая абстракция, в которой может жить несколько контейнеров. Обычно требуется больше одного дня, чтобы врубиться, что же это такое. Вместе с этим меняется представление о контейнерах, ведь теперь у них появляются роли (init container, side-car container).

Kubernetes автоматически делает то, о чём ты раньше мог только мечтать: если приложение падает, оно автоматически перезапускается; если нагрузка растёт, оно автоматически масштабируется; если нода выходит из строя, рабочие нагрузки перераспределяются. Ну, то есть после настройки кучи всего, конечно. Например, для автомасштабирования понадобится Horizontal Pod Autoscaler и включённые метрики.

Ещё есть манифесты и Helm-чарты. В Kubernetes всё описывается в виде YAML-манифестов. В манифесте описывается желаемое состояние системы и Кубер сам заботится о поддержании этого состояния. Это как инфраструктура-как-код, но для контейнеров. Helm-чарты позволяют упаковать несколько манифестов в один установочный пакет и использовать шаблонизацию.

И ещё бывает автоматическое обновление без простоев. Kubernetes умеет обновлять приложения по принципу rolling update: постепенно заменяет старые поды новыми, поддерживая доступность сервиса. Пользователи даже не заметят, что произошло обновление.

Дальше надо понять базовые принципы сетевого взаимодействия контейнеров:

• TCP/IP и Linux bridge. Контейнеры общаются через обычную сеть. В пределах одной машины это виртуализированная сеть через Linux bridge. Создаётся виртуальный адаптер, крепится к контейнеру, появляется интерфейс с IP-адресом. К этой же виртуальной сети подключаются другие контейнеры.
• Виртуальные сети между контейнерами. С Docker Compose можно создать несколько разных сетей и ограничить общение контейнеров друг с другом. Это как виртуальные VLAN в мире контейнеров. Ручками тоже можно, но с Docker Compose — проще.
• Ingress и маршрутизация трафика. Ingress в Kubernetes — это способ маршрутизировать внешний трафик к сервисам внутри кластера. Если ставить Кубер на голом железе (или в виртуалках на голом железе), то на этом месте можно сломать голову и любой новичок гарантированно забуксует. Без возможности выставить сервис наружу Кубер превращается в чемодан без ручки дом без окон и дверей — все системы прекрасно работают внутри него, общаются между собой, но достучаться к ним снаружи кластера невозможно. Сейчас рекомендуется переходить с Ingress на Gateway API. Совет — не делайте этого, не освоив Ingress. И ни в коем случае не ставьте сразу Kong (он хорош, но о-о-о-чень сложен для начала).
• Балансировка нагрузки. Kubernetes умеет распределять запросы между несколькими репликами приложения. Managed Kubernetes обычно использует LoadBalancer от провайдера. Если ставить Кубер на своём железе — можно попробовать MetalLB — проект специально сделан, чтобы дать функционал LoadBalancer там, где он не предусмотрен по дизайну. Без балансировки между инстансами ничего не получится, иначе вы опять будете реплицировать монолит. Монолит, кстати, тоже можно разворачивать через контейнеры, но обычно смысл в другом.
• Инструменты визуализации (Hubble для Cilium). Kubernetes умеет дружить со множеством различных реализаций контейнеров, сетей и хранилищ. Делается это за счёт интерфейсов. Так вот для сетей есть Cilium, а для Cilium есть Hubble — визуальный интерфейс. Можно буквально увидеть, как взаимодействуют компоненты, куда идёт трафик. Это одна из самых частых проблем — нужно держать в голове карту взаимодействия, и это решение помогает быстрее освоиться.

Грабли, которые вы соберёте
В этом месте, если вы научитеcь оркестрировать, возникнет следующий уровень сложности — ИБ. Она, как и везде, ошибок не прощает.

Настройка портов и их экспозиция. Даже Senior-разработчики, бывает, путаются в настройке портов: что такое publish, expose, когда использовать ClusteIP, а когда NodePort. Это нормально — все через это проходят. Каждый раз, когда вы открываете порт наружу, вы создаёте потенциальную дыру в безопасности.

Второе правило контейнерного клуба: не запускайте всё от рута. Контейнеры изолированы не так хорошо, как виртуалки, поэтому использование непривилегированных пользователей критически важно.

Контейнеру не нужны все права в мире. Дайте ему только то, что ему действительно необходимо для работы. Используйте seccomp, AppArmor или SELinux для дополнительных ограничений. Если Junior-разработчик предлагает запустить контейнер с флагом --privileged, это повод для серьёзного разговора (или увольнения, в зависимости от обстоятельств).

Уделите время освоению модели RBAC и практикам её использования в Kubernetes.

Никогда не хардкодьте пароли и ключи в образ контейнера. В Docker есть Docker Secrets, в Kubernetes — Secrets API. Используйте их вместо переменных окружения с чувствительными данными. Это важно, когда вы начнёте раскатывать что-то за пределы одного проекта.

Ну и контейнеры должны знать, как обращаться друг к другу. В простом случае это имя контейнера, в Kubernetes — сервис с DNS-именем.

Заражённые контейнеры тоже бывают. Образы контейнеров, как и любой код, могут содержать уязвимости. Да и атаки на цепочки поставки никто не отменял. Используйте инструменты вроде Trivy или Clair для проверки образов перед деплоем.

Ну и не наступайте на грабли с лицензиями. В мире контейнеров доминирует открытое ПО. Postgres вместо Oracle, Nginx вместо IIS. Это не только дешевле, но и удобнее упаковывается. Если у софта всё же есть коммерческая версия, то чаще всего она подразумевает поддержку от разработчика и дополнительный функционал. Обычно в мире open-source софт лицензируется по фичам, а не по ресурсам. Вы покупаете энтерпрайз-версию, а как её масштабировать — ваше дело.

Зачем всё это?
Современные LLM генерируют не просто куски кода, а целые приложения. И идеальный способ их запустить — контейнеры. Sonnet 3.7 уже настолько круто кодит, что многие компании смогли увеличить производительность в разы.

Вы описываете словами, что хотите получить, и нейронка генерирует готовый код. Дальше дело за малым — упаковать его в контейнер и запустить. Этот процесс становится таким же простым, как отправка письма. Кстати, уже есть люди, которые не умеют в электронную почту )

Ну и сейчас у каждого уважающего себя облачного провайдера есть управляемый Kubernetes. Вам не нужно возиться с установкой и настройкой — просто выбираете количество нод и через несколько минут кластер готов к работе. Но есть нюансы.

Решения для запуска приложений в контейнерах часто бывают и serverless, там основная единица — это контейнер, а не ноды кластера.

Яндекс, например, предлагает сервис, где контейнер запускается только на время вызова. Происходит HTTP-запрос, запускается контейнер, отрабатывает и умирает.

У нас в L1veStack подход, скорее — замена виртуалок. Serverless containers. Это логическое развитие контейнеризации: вы не думаете о серверах вообще. Есть контейнер, он запускается и работает пока вы его не остановите, и тарификация только за потреблённые ресурсы во время его работы. Наши контейнеры рассчитаны на долгую жизнь, но никто не мешает вам убить полстада и запустить заново. И повторить через 5 секунд.

Как учиться
Отличный первый проект для освоения контейнеризации — простой чат-бот. Он включает и фронтенд, и бэкенд, и базу данных — всё, что нужно для понимания взаимодействия контейнеров. Вот у нас пример. Там ещё и простой CI/CD на базе GitHub Actions, который собирает образ при каждом новом коммите.

Начните с запуска отдельных контейнеров, потом объедините их с Docker Compose, затем перенесите в Kubernetes. Это естественный путь освоения технологии.

Сейчас есть множество готовых Docker Compose файлов для популярных стеков. Хотите WordPress? Есть готовый рецепт. Хотите LowCode-платформу? Есть готовый рецепт. Нужна CRM-система? Есть готовый рецепт. Не изобретайте велосипед, используйте готовые решения.

Проиграйте failsafe-сценарии. Запустите несколько реплик, сымитируйте падение одной из них, посмотрите, как система восстанавливается. Это бесценный опыт, потому что он учит думать именно в философии контейнеров.

Грейды примерно такие:

• Junior: базовые знания Docker, умение запускать и останавливать контейнеры.
• Middle: сборка своих образов, Docker Compose, CI/CD с контейнерами, основы Kubernetes.
• Senior: глубокое понимание Kubernetes, настройка производительности, мониторинг.

Если говорить про администрирование, то джуны ломаются на Ingress и выставлении портов наружу. Мидлы поломаются на Gateweay API и настройке Auto Provisioning для persistent volumes — как настроить систему, чтобы она автоматически выделяла дисковое пространство, например в Ceph. Даже некоторые сеньоры спотыкаются на сетевых тонкостях Kubernetes.

Контейнеризация нужна везде: от стартапов до корпораций. Но особенно востребованы специалисты в компаниях, которым нужно быстро и часто деплоить обновления. В 2025 году умение работать с контейнерами — это уже не преимущество, а базовый навык. Не важно, кто вы — разработчик, администратор или CTO, вам нужно понимать, как работают контейнеры и зачем они нужны.

Нейронки сделали возможным выкатывать Proof-of-Concept целых систем за дни, а MVP — за недели. Скорость Time-to-Market решает в этой гонке, и её не повысить без инструментов автоматизации сборки и деплоя. И Kubernetes тут как нельзя в тему.

Если вы освоили всю стопку технологий и умеете их применять на практике (и не просто применять, а устанавливать и правильно настраивать), вы — мега-DevOps с зарплатой от 500к и выше. И спрос на таких специалистов только растёт.

Начать можно с официальной документации Docker и Kubernetes. Для углубления знаний рекомендую «Kubernetes в действии» и Docker: Up & Running. Есть даже отдельная книга «Kubernetes и сети» — для тех, кто хочет разобраться в сетевом взаимодействии.

Лучший способ учиться — делать. Пройдите интерактивные курсы на Katacoda или Play with Docker. Устройте себе хакатон выходного дня — запакуйте своё приложение в контейнер и запустите его в Kubernetes.

Почитайте Open Container Initiative.

Покурите service mesh решения (Istio, Envoy), которые важны при работе с микросервисами.

Разберитесь со StatefulSets (хранение состояния в контейнерах) — если не сломаете голову до этого.

На сладкое оставьте CRD и операторы (возможно, даже свои).

Подписывайтесь на телеграм-каналы DevOps-сообществ, следите за кейсами компаний, которые внедрили контейнеризацию. Вступайте в сообщества на Reddit, Stack Overflow, GitHub Discussions. Задавайте вопросы, делитесь своими находками. Контейнеризация — это живая экосистема, и лучший способ оставаться в курсе — быть её частью

h3llo.cloud
auth.h3llo.cloud/register

LiveStack — это бессерверная PaaS (Platform-as-a-Service) платформа, созданная для удобного развёртывания, управления и масштабирования приложений и сервисов, работающих на основе Docker-контейнеров. Она предлагает мощные инструменты для автоматизации процессов, облегчая работу разработчиков и DevOps-инженеров с современными облачными решениями и микросервисной архитектурой.






l1vestack.ru
auth.l1vestack.ru/register
console.l1vestack.ru

Первая тестовая стойка дома, до заезда в ЦОД. Уже после сборки я понял, что держать 35 миллионов рублей в квартире — так себе идея

Когда вы внутри, это, конечно, тяжко, печально и всё такое, но снаружи это всегда смешно.

Мы строим крупное российское облако, наверное, одними из последних в этой стране в ближайшие несколько лет. Потому что начали без заёмных средств до ставки 21% и ещё когда можно было более-менее внятно пройти бюрократию на лицензию.

Про ад с бюрократией я писал вот здесь.

В этом посте, кстати, было про Ростелеком, речь про Даталайн, который им стал в процессе нашего заезда:

Дальше выбор ЦОДа. Один из партнёрских ЦОДов, где мы размещаемся в Москве, — это Ростелеком. Первую стойку нам выделили в моменте: мы направили запрос, нам сказали: «В этом ЦОДе нет, но встаньте вот сюда» и прислали коммерческое предложение на следующий день. Это заняло буквально два письма туда-обратно и пару звонков. А вот предложение на последнюю стойку менеджер отправлял нам уже месяц. Возможно, согласовывал внутри.

Так вот. Через пару часов после публикации мне написал менеджер из Ростелекома и попросил отредактировать материал, чтобы не порочить деловую репутацию компании. Ну и мы согласились, потому что ничего принципиального для нас в этой истории не было и мы в целом больше за дружбу.

Знаете, в эти игры можно играть вдвоём.

Я попросил в ответ прислать проект правок, то есть предложить итоговые формулировки. Я абсолютно точно знал, что будет дальше — ведь отдельный человек в системе не может взять на себя такую ответственность.

И да, они собрали внутри себя совещание и сутки думали, что же именно нужно поменять. Мы до сих пор бы обменивались официальными письмами и шли бы им навстречу, если бы не решили оттуда уехать.

Второй случай связан с тем, что мы только спустя полгода после открытия офиса смогли провести туда интернет.

Наш интернет
Самое первое, что приходит в голову, — это история про провайдера, сапожника без сапог.

Это про наше подключение офиса к интернету.

Мы заехали в бизнес-центр, который принадлежит нашим друзьям. Приехали, посмотрели, всё понравилось. История классическая, как обычно, один провайдер. Просто никто не заморачивался подключать больше в сам БЦ. Собственники были не против завести кого-то ещё, но у них в принципе такой потребности и не было.

У нас потребность была. Начали смотреть предложения, считать, думать.

В это же время мы очень активно строили между двумя ЦОДами свои оптические линии. И внезапно поняли, что дойти и до офиса тоже — вообще не проблема. Закинули вопрос, сколько нам будет стоить по тёмному волокну включиться где-то здесь? Есть оно вообще где-то ближайшее?

Получили очень адекватное такое предложение — прямое включение, скорость любая, всё зависит от той пары трансиверов, которые поставишь на концах. Два волокна TX/RX, то есть одно на приём, одно на передачу.

По ценнику получилось дешевле, чем гигабитный инет в месяц.

Решили, что сейчас поставим 40 и врубим, потом 100 Гбит/с. Удобно же для офиса. Тем более команда быстро растёт.

Начали делать. Всё хорошо, но был один нюанс. Последние 150 метров достроить — надо согласовывать с собственником здания, через которое проходит как раз от ближайшего колодца трасса. У нас что с одного ввода люка, что с другого стоят жилые дома. В подвале этих жилых домов лежит трасса МГТС, в которой лежит оптика ШПД. Но когда вы ведёте там свою жилу, это становится не вопросом ШПД для дома, а отдельным проектом.

Прокинуть оптику — дело 2–3 дней. А вот этап согласования с собственником занял почти четыре месяца, из которых три он всячески пытался набить цену.

Собственник должен просто сказать: «Разрешаю, согласовываю». Подписать на плане, что согласовано, и, пожалуйста. Председатель ТСЖ, через которого предполагалось, что всё это идёт, хотел за это денег. От председателя надо получить документ, что трасса прокладки через подвал согласована. Она там уже по факту лежит и оказывает услуги дому. Казалось бы, надо как-то через неё класться. Но всё равно нужна его подпись. В этот момент мужик понял, что настал его звёздный час, и решил не упускать свой лучший шанс в жизни стрясти денег с коммерсов. Правда, он не знал, сколько именно трясти. А через помощника сигналил, что коммерческое предложение пришлите: сколько это, как это. Всё боялся продешевить. Непонятно же, сколько это стоит — 50 метров кабеля положить тебе в существующий лоток. Сколько за это взять? Разово? Ежемесячно?

Первые два месяца, пока это делали, мы сидели, как самый крутой провайдер, на мобильных интернетах. Потом получили L2 VPN с последней милей от другого провайдера, офис ожил.

А потом после примерно десятой итерации переговоров выяснилось, что председатель ТСЖ вообще не при делах. И его звёздный час прошёл. Подвал, через который всё идёт, давно выкупил другой человек — и он нам всё это очень быстро подписал. Безвозмездно.

Теперь по цене обычного офисного интернета у нас 40 Гбит/с напрямую к ЦОДу с минимальными задержками и без посторонних на пути. Но второй раз в такую игру я играть не хочу. Либо же сразу буду приходить с ультимативным коммерческим предложением.

При любой прокладке кабеля такая потенциальная проблема всегда присутствует. Поэтому когда мы брали собственный ЦОД, заодно купили ещё участок земли по дороге от электростанции — как раз на такой случай. В общих затратах на инфраструктуру он почти бесплатный.

Теперь представьте тех людей, которые строят трассу длиной не 150 метров, а 120 километров. И через сколько собственников она проходит. Сразу вспоминаются все эти жилые дома посреди скоростной трассы и прочие радости жизни.

Виртуализация туалета
Для офиса мы сняли почти весь этаж. Почти — потому что у нас только один сосед на этаже. Давно сидят в бизнес-центре, проверенные спокойные люди. У них там работает несколько человек, по нашей оценке, 4, плюс-минус 2.

И вот они с чего-то решили поделить территорию общего пользования, а конкретно туалеты.

Просто взяли и закрыли себе одну из двух кабинок туалетов.

Врезали в дверь замок и сделали выделенный персональный туалет.

К этому моменту у нас было уже под два десятка человек. А два десятка человек во вторую кабинку помещается не всегда.

Грубо говоря, их туалет dedicated, а у нас адская переподписка. Зашли на чай к собственникам бизнес-центра, они сильно удивились, и через 20 минут работы АХО, замок исчез. Всё, казалось бы, хорошо, я думал на этом и закончилось. Так нет, их учредитель пришёл к нам за эти туалеты качать права. Казалось бы, уже 25-й год на дворе, а кто-то додумывается поделить кабинки туалета. К счастью, быстро объяснили про общие права доступа.

Собеседования
Самое главное требование у нас — работа только из офиса, удалёнка невозможна. При этом у нас нет строгого расписания — кто-то приходит позже, кому как удобно. Отбор у нас идёт через два фильтра. Сначала с кандидатом обсуждают базовые условия, знакомятся. Потом проверяют технические навыки. И только после этого человек попадает ко мне на финальное интервью.

Как-то к нам пришёл парень, который назвался middle+ фронтендером. Когда он начал рассказывать о своём опыте, выяснилось, что на сайте одной крупной букмекерской конторы он просто вручную обновляет информацию о матчах.

— Я беру шаблон, копирую, вставляю весь контент в реактовские компоненты руками и загружаю на сайт.

Я осторожно выдохнул и спросил опытного middle+ про концепцию DRY (Don't repeat yourself) и как он применяет её в работе.

— DR что?

Я объяснил. На что кандидат просто сказал: «Нет, сдаюсь» и вышел с собеседования.

Сразу скажу, что место немного холиварное, потому что DRY не всегда однозначно хорошо — где-то вступает в противоречие с KISS. Но это, по крайней мере, можно обсудить. Да и реактовские компоненты сами по себе подразумевают DRY — ты определяешь компонент один раз, а потом просто вызываешь его с разными параметрами.

А где он руками копипастил — это крупная контора, реально на слуху у всех. В каждый видеоролик свою рекламу пихает и такой подход к разработке сайта. Я офигел, конечно, что там до сих пор не слышали про CMS.

Вторая история с собеседования была ещё веселее. И вот она уже заставила надолго задуматься.

Два Scala-разработчика. Забегая вперёд, скажу, что в итоге-то мы столкнулись с очень большими проблемами с набором Scala-команды и после выхода Sonnet 3.6 переключили часть компонентов на Go, но про это чуть позже. А Sonnet 3.7 вообще поставил точку в вопросе.

Но вот собеседование. Откликов совсем немного. Scala-разработчики — это нечто очень экзотическое, днём с огнём не найдёшь.

Пришёл, значит, к нам первый кандидат нормальный такой. Пообщались, всё понравилось, пригласили в офис. Дали небольшое тестовое задание — спецификацию OpenAPI с описанием эндпоинтов REST API для веб-сервера. Говорю: «Подними. Стек любой. Инструментарий любой. Как тебе удобно, так и делай. Главное — без нейронок». Мы же скил оцениваем. Так-то мы за LLM. Дали всё, что он попросил. Отошёл заварить кофе. Возвращаюсь. Он:

— Вот. Готово.

Я не понял.

Смотрю — действительно готово.

У него был свой фреймворк написанный, который берёт спеку OpenAPI и поднимает веб-сервер. Он просто несколько строчек кода имплементировал во внутреннюю логику к каждому методу, а всё остальное за него делал фреймворк. Потому что задача встречается не первый раз. Классная вещь. Я прям воодушевился: 10 минут и выполнен рабочий веб-сервер. Но денег этот кандидат хотел прям очень много. Мы ещё поговорили и решили, что надо подумать, потому что один такой человек с правильными инструментами заменяет целый отдел. А с нейросетками, возможно, два.

В этот момент пришёл другой кандидат. Такой дядечка уже в возрасте. Отметился в крупном банке. Всё хорошо рассказывает, дали то же самое задание. Он открыл Vim вместо IDE и начал быстро набирать пятую сонату код.

Спустя полтора часа на Play! Framework эта штука еле-еле завелась и выдавала один работающий метод. Не микросервис, а именно один метод. Без логики.

Контраст, конечно, был очевиден.

Денег он запросил столько же много. А за сакральное знание, как выйти из Vim, мы столько платить не готовы.

В итоге после всех обдумываний перешли на Go. Scala закрывает исключительно тот кусочек, который прям вообще не вариант ни на чём другом сделать, и в команде есть люди, которые с ней работают, в том числе я.

Ещё одна интересная особенность в том, что современные LLM обучены очень хорошо кодить на Go, но очень плохо на Scala, и использовать их возможности просто не выйдет. Возможно, выборка была не очень большая. Мы надеялись на o1 и R1, но тоже нет. В общем, Go. Там и проблем с разработчиками нет.

Третья история с собеседований — аналитики ИБ. Руководитель по ИБ в компании должен завестись сам, потому что публиковать вакансию всё равно не выйдет со всеми деталями. Да и на рынке специалистов по ИБ нет от слова «совсем». Как и самого ИБ в малом и среднем бизнесе.

Мы всё же взялись строить SOC и более-менее открыто прописали, что делать и как. И начался поток людей, которые умеют поднимать файрвол на роутере. И это потолок их навыков. До строки квалификационных требований про спокойствие так и не дошли. А спокойным надо быть.

Специфика бизнеса — в том числе не допустить открытия канала к ОРМ. Мы, как хостер, должны определённый формат СОРМ поддерживать. К счастью, мы не должны закупать никакое дорогостоящее железо как телеком-операторы. Но мы должны наружу выставить для них защищённые концы с доступом к определённой информации. Её перечень, структуры и так далее, они все открыты в нормативке. Там 70-страничный документ с описанием GraphQL схемы. Собственно, мы должны её поддерживать и не давать посторонним лицам. Это персональные данные и, в принципе, репутация. Ну и помимо СОРМ есть базовая гигиена ИБ, за которой необходимо следить.

Поиски, кстати, всё ещё продолжаются.

35 миллионов в квартире — плохая идея
Первая наша стойка для MVP, как вы видели выше, была не стойка, а груда серваков, стоящих друг на друге у меня дома. Выглядело зачётно. Светилось как новогодняя ёлка — и был это как раз конец зимы.

У меня несколько розеток отдельных под домашний кинотеатр, акустику и так далее. По идее каждый сервак — блоки питания 800–1400. После включения всё это начинает жужжать адски, как рой дронов. Я думал, что соседи испугаются, что сейчас атака будет.

Потом ёлочка начинает гореть, то есть греться. Естественно, включаешь кондей либо открываешь окно, когда холодно. Дальше можно с этим сидеть, жить, настраивать.

А вот дальше по факту я очень удивился, что вся стойка потребляет как микроволновка. Десяток серваков жрёт меньше, чем чайник. Я до этого привык, что если заявлено три с половиной киловатта на асике или видюхах в риге, значит, оно и будет жрать три с половиной киловатта. Так и есть, в принципе, плюс-минус пять процентов. А здесь, оказывается, ни фига.

Но самое смешное случилось, когда мы это через неделю настроили и повезли уже в ЦОД. Вызвали «Грузовичкоф». Приехала к нам Лада Ларгус и такой типичный водитель Ларгуса, который откуда-то с региона, видимо, приехал на заработки.

Посмотрел он на сервак. Мы ему объяснили, что стоит он дохрена и надо с ним очень аккуратно. Всё шикарно. Он потихонечку их перенёс. Мы помогли, загрузили. Всё это на грузовом лифте по нескольку штук за раз, на подземную парковку, всё уложили. Обмотали, естественно, плёнкой пупырчатой. Коммутаторы упаковали сверху. Всё хорошо.

Выезжаем из паркинга, и он говорит:

— Ребята, а незамерзаечки у вас не будет? У меня что-то закончилась.

Мы ему отдали канистру незамерзайки. Он, значит, что-то залил, а что осталось — положил в багажник.

Уже приехав в ЦОД, мы поняли, мало того, что он её хреново закрыл, он в багажник её кинул прям поверх серверов.

И вся незамерзайка по ним течёт!

Пока я матерился страшными словами, он всё поспешно выгрузил и уехал.

В незамерзайке спирт (этиловый или изопропиловый), что для серверов условно-безопасно. И вода. Вода уже не так безопасна. К счастью, дальше крышки это не протекло. В паре мест капнуло на платы, я протёр, просушил, и всё завелось.

Это были наши первые серваки для Proof-of-Concept. Сейчас эти серваки будут доживать в наших инстансах под CDN, а мы закупаем уже HPE Gen12. Надеюсь, скоро покажу. Их точно сразу в ЦОД и не на Ларгусе.

VDI
Изучали рынок VDI в России, когда думали, кому и что будем продавать.

Получилось как с той рисоваркой, для запуска которой нужен админ, Senior-разработчик, тимлид и уборщица.

Садится команда людей, среди которых DevOps опытный, который сам Linux-драйверы низкоуровневые пишет для железа. Тимлид, который поднял десятки проектов руками, до этого много в студии Лебедева отработал и в блокчейн-проекте. Собственно, L1veStack (наш контейнерный хостинг) под его руководством вышел. Другой тимлид (тоже с хорошим опытом за плечами), разработчики и я.

И вот мы логинимся в VK и начинаем делать себе VDI. Прям по кнопке «создать VDI». Перед нами мастер на 7 шагов. Проходим первый экран, и там такая хитрая кнопочка «протестировать, всё ли правильно». Нажимаем. Просто начинает крутиться кругляш, и ничего не происходит.

В ресурсах смотрим — херак, создалась виртуалка. Что-то там крутится, крутится, крутится и не меняется. Минут через пять вместо кругляша появляется галочка, что у нас всё окей.

Но виртуалку он не удаляет. Тарификация на неё капает.

Едем дальше. Дальше сетевые настройки, надо зайти в настройки сети, создать новую сеть. Причём диапазон 24-й ей маловат, ей подавай сразу минимум 22-й — и иди ещё с этим всем разберись и пойми из их описания. Ладно, курим маны и кое-как этот этап проходим.

Начинается третий шаг. Называется «введите данные для домена». И просит разные параметры LDAP. Прикол в том, что выскакивают всякие подсказки с ошибками, что введённая строка не соответствует формату. Проверка прикручена. Но вот авторизации по этим данным нет, и можно вставить чужой домен.

На следующем шаге запуск виртуалки под уже выбранную конфигурацию.

1 рабочий стол, 1 контроллер, минимальные ресурсы.

Запустить виртуалку невозможно, потому что квоты не хватает.

Дальше курим ман, и оказывается, что ни один новый аккаунт это всё запустить не сможет никогда.

Деньги есть, а вот лимиты стоят запрещающие. И иначе как через поддержку, это не решается.

Мы всё это посмотрели и поняли, что вряд ли кто-то эти сценарии проходит легко и хорошо.

Пошли тестить других. На третий день случайно вспомнили про ту виртуалку, которая включилась во время теста, пошли тушить. Тоже непросто, удаление заняло минут 20, потому что её нельзя просто удалить (кнопка тупо заблокирована). Сначала надо удалить все связанные с ней ресурсы — сеть, VDI-группу и так далее. А до этого надо ещё додуматься. Прикинули, сколько таких у других крупных клиентов )

Кстати, вероятно, если вы несколько раз запустите тест, виртуалок тоже будет несколько. Пробовать не стали.

В итоге после трёх дней такого тыкания во все VDI на рынке, мы для себя записали, как должен выглядеть проект. Думали, что клиенты этого не замечают, потому что всё падает на девопсов, — но дошли до знакомых архитекторов с 1200 столами, они посмотрели, увидели фотографии графического кластера в ванной и сказали, что мы первые адекватные, кто заглянул. Хорошо пообщались. Стало многое понятно.

Как покинуть офис
Лучшая история с офисом была, когда мы устроили вечеринку в пятницу с пиццей. Бизнес-центр у нас относительно небольшой, арендаторов не сотни, все уходят около 20–21. Охранник по стандартной привычке закрывает выход из здания и уходит на обход.

У нас корпоратив до 22. Мне понадобилось срочно уехать. Спускаюсь, охранника нет, выход закрыт. Соответственно, наши, кто любит просыпаться в 16 и работать вечером, делятся со мной лайфхаком — надо выйти в окно.

Показали окно. Я и вышел.

Охранник это увидел снаружи, и нам чуть не накрыли корпоратив группой быстрого реагирования. Дальше уже объяснили, что мы, айтишники, дикие люди, и можем не только приехать после завтрака в 17, но и уходить ночью. Больше таких инцидентов не было.

Привет Таймвебу
Ну и чисто хабровская история. Про комментарии к статьям. Буквально недавно столкнулся с тем, как эсэмэмщики работают в лучших традициях.

Вот наш пост про перформанс-тесты. Там есть про этих прекрасных облачных провайдеров, и не очень лестное. Хотя, несмотря на адскую переподписку, по деньгам там всё же довольно интересные условия. Но про переподписку тезисы, видимо, не понравились.

Сначала от них пришёл засланец просто, у которого стояла отметочка в профиле, что он работает в Таймвебе. Он накатал длинную-длинную телегу про то, какое мы говно. Его начали минусовать, спустили до -5. И внезапно попёрли плюсы, причём очень кучно! И это совпало с моментом, когда он отредактировал профиль и убрал, что он работает в Таймвебе. Прям отличная переобувка в воздухе — чудо, человек уволился, чтобы нас прокомментировать.

«Я вам оборудование закину погонять»
Напомню, когда мы только взяли площадку под ЦОД, там были развёрнуты ванны под асики. И ещё контейнеры стояли. И вот один из наших знакомых спрашивает, раз уж мы купили площадку, можно ли поставить своё оборудование.

Соглашаемся, но не проговариваем все детали. А важной деталью была цена этого оборудования, а не только условия аренды нашей площади.

Асиков там было почти на миллиард. Комплект майнера включал в тот момент травматический пистолет, и не один.


Набор майнера

Мы тогда с сооснователем вместе дополнительно дежурили в будущем ЦОДе в нагрузку к росгвардейцам, которые нас охраняли. Потому что места дикие, и если что — росгвардейцы убегут первыми. Потому что вопрос на миллиард и 15 минут погрузочных работ.

Объект мы за первую ночь утыкали камерами с детекцией движения, но детекцию нормально настроить не успели. И камеры реагировали не только на росгвардейцев, но и на птиц. Птицы летали не только снаружи, но и внутри ангара, и сильно чаще, чем я думал. А я на измене, представляю, что кто-то полезет это оборудование вытаскивать.

Когда история с асиками кончилась и в ванны мы перезалили другой диэлектрик под серверы, очень сильно выдохнули.

Всё же облаком в России заниматься гораздо спокойнее и предсказуемее.

h3llo.cloud
auth.h3llo.cloud/register

Когда вы строите облако, заниматься собственным дата-центром — звучит как слабоумие и слабоумие, потому что в структуре затрат самая большая часть — железо.

Аренда чужого ЦОДа в 5-летней перспективе даёт 10% от стоимости оборудования — это соотношение примерно одинаковое что для стойки, что для целого машзала по мере его заполнения.

Собственный дата-центр подарит вам незабываемый геморрой, опыт строительства, опыт неправильного строительства, кучу новых рисков (включая сложные отношения с местными чиновниками) и даст в итоге 5% от стоимости оборудования. Если вам не хватает геморроя в жизни, то можно заняться рефакторингом вашего софта — потенциальный выхлоп будет примерно таким же.

Тем не менее нам досталась котельная с прямым вводом во ВН (да поймут меня энергетики), то есть очень-очень дешёвым электричеством. Более того, на её территории уже был ЦОД, правда, из ванн с асиками для криптанов. Они даже не заморочились со зданием, а просто поставили контейнеры рядом.



Это асики, утопленные в диэлектрической жидкости. С каждой ячейки отводится до 5 киловатт тепла — как со среднестатистической серверной стойки

Ещё у нас изначально была большая масса железа с GPU, которая финансово дорогая. Её надо было куда-то пристроить. В обычные ЦОДы это эффективно не поставить, а готовых ЦОДов под иммерсионное охлаждение не было. Соответственно, нужен был свой.

Естественно, при ставке рефинансирования 21% мы бы в жизни не пошли в строительство своего ангара, подстанции, воздушного сегмента и завоз новых ванн с бурлящей охлаждайкой, не заморачивались бы на прокладку оптической трассы в соседний регион и так далее. Но начинали-то мы тогда, когда такой ставки не было, и теперь у нас есть ЦОД. Немного, скажем так, необычный.

В двух ДЦ Tier-3 в Москве мы ставим высокопроизводительное железо, а в своём занимаемся разгоном серверов в ваннах. В средней полосе.

Как выбирали ЦОДы в Москве
Сначала мы заехали в Даталайн (когда он ещё не был Ростелекомом) и в 3Data. Оба они на тот момент были отличными.

С 3Data мы завязались по той причине, что нашим ключевым провайдером и партнёром по всему направлению волоконных сетей стала Мастертел, и 3Data тоже в их конгломерат входящая структура. Поэтому по их же рекомендации мы посетили, посмотрели, нам понравилось. Встали, в том числе и у них. Как раз у них мы летом планируем брать машзал. 3Data — это сеть ЦОДов небольшого размера. Условный отдельный машзал — это как кейдж у большого хостинга, поэтому просто выгоднее прийти и взять машзал у них, чем строить большой кейдж где-то ещё. Вот на что мы нацелились, о чём мы предварительно уже договорились.

Потом в Даталайне завёлся (или правильнее сказать — окончательно установил свои порядки) Ростелеком, и мы смекнули, что мы не аудитория этого ЦОДа, всё-таки там госы или окологосударственные компании. Сейчас переезжаем в два крутых IXcellerate. Это второй по крупности оператор ЦОДов, то есть после Ростелекома у них самое большое количество стойкомест. У них два кампуса по несколько ЦОДов. И темпы их роста соответствуют нашим потребностям. Мы берём по несколько рядов в каждом машзале. Ряды там проектируют так, чтобы они были с энергонезависимыми вводами каждый. Ещё у них каждая стойка под отдельным СКУДом с биометрией.

Другие также рассматривали, но основные варианты вот такие. Почему так — потому что важны локация и связность. Между кампусами IXcellerate трассы выходят по 30 километров, это значит, что наши 400-гигабитные трансиверы между ЦОДами прекрасно добьют.

Всё, что расположено за МКАДом и так далее — это не очень интересная история.

Второй момент — это условия по количеству электричества на стойку и как оно тарифицируется. Основная история у ЦОДов — это 5–6 киловатт, а IXcellerate нам даёт 14.

И ещё есть свой ЦОД.

Откуда взялся свой
Были люди-криптаны, которые майнили битки и эфир. Для эфира они использовали риги — кастомные компы с кучей GPU. По сути, они меняли конкретное электричество на абстрактные деньги по довольно выгодному курсу. Бывший владелец любит шутить, что из оборудования на начало работ у него был только паяльник.

Потом эфир перешёл на другую систему счисления, на Proof-of-stake вместо Proof-of-work.

Оборудование одномоментно стало бесполезным, потому что считать смысла уже не имело. К счастью, в этот же примерно период появилась задача инференса нейросетей (запуска обученной модели, например, для промышленного видеонаблюдения, про которое тут очень много постов) и дообучения нейронок под конкретные задачи. Так вот, когда крупный завод говорит, что взял фотографии продукции из цеха, или розница говорит, что взяла фотографии продуктов с весов и обучила нейросеть — это происходит обычно либо в каком-нибудь дата-центре крупной корпорации зла, либо в таком вот ангаре, внутри которого стоят машинные залы.

Тот же ЦОД в Медведкове — частично ЦОД, частично — склад СДЭК. И это вполне нормальная история.

Потом оказалось, что если из ванны вынуть асики и положить туда сервер, то он будет охлаждаться сильно лучше. Ещё если процессор поддерживает разгон, можно разогнать его до неприличия, и получится очень даже ничего.

Параллельно мы строили своё облако в арендованных секциях и машзалах. И тут на нас упал этот самый недоЦОД с кучей иммерсионных вичислительных нод.

Мы поискали способы эффективно применить актив, и после ряда экспериментов оказалось, что это ещё очень хорошее дополнение к облаку. Как минимум потому, что дешёвое электричество и собственное здание дают возможность увеличить срок эксплуатации оборудования. Обычно оно заменяется на новое ещё и потому, что занимает меньше места и делает больше вычислений на потреблённую калорию. Но если у вас есть дешёвый ввод, можно использовать железо лишние 2–3 года, соединяя в кластеры, где для конечного клиента расчёт идёт по фактическим операциям, а не по аренде ядра.

Модель начала складываться. Собственный ЦОД внезапно получил экономическое обоснование (напомню, до повышения ставки рефинансирования).

Как считаем 5%
Берём затраты на строительство и раскладываем на срок амортизации. То есть, очень грубо говоря, считаем аренду исходя из затрат, как бы сдавая его самим себе. К счастью, тут мы не пошли в кредитные деньги, а делали за собственные, поэтому финансовые ужасы следующих лет нас не коснулись, а актив ещё и подорожал в приятном для нас, как владельцев, направлении.

Основная часть операционных затрат ЦОДа — электричество. Именно поэтому выбор места, где можно получать самое дешёвое электричество, сильно определяет будущую судьбу ЦОДа. Наши предшественники выбрали место по цене ввода. Мы же были очень рады такому решению.

Итак, зачем всё же свой
Подводя итог, условно, он нам достался почти что в наследство.

Как максимально эффективно эксплуатировать имеющийся ресурс? Решили, что построим свой ЦОД. Учитывая цену электричества, железо предыдущего поколения будет доживать там.

Плюс в своём мы также делаем иммерсию.


Это отдельная история, так как она у нас изначально как компетенция была. В иммерсию мы умеем очень хорошо.

Это значит, что в своём ЦОДе мы с GPU сможем снимать очень-очень много вычислительной мощности за раз. Каждая ячейка установки (а в одной ванне их 24 штуки) может снимать по 5 киловатт. Чуть меньше того, сколько снимает целая стойка в среднестатистическом ЦОДе. Соответственно, в каждую такую ячейку можно погрузить мощный процессор и ещё их подразогнать, если они это поддерживают. Можно погрузить много GPU, и в рамках одной ячейки всё это будет прекрасно жить.

Умножаем это на самый дешёвый тариф электроэнергии и получаем вполне подходящие условия для таких решений, как VDI, 3D-рендеринг и инференс.

То есть продавая это не как ресурс, а как конечную услугу где пользователь не платит за условные ядра или оперативную память, а оплачивает именно единицы вычислений, например, количество токенов в модели.

Облако IaaS — в ЦОДах партнёров, инференс и Архикад по VDI — в своём ЦОДе.

Почему так — потому что в самой Москве сейчас меняются условия игры, и HP уже 12-го поколения занимают, условно, в 7 раз меньше места, чем 10-го. По факту получается, что серваков нужно намного меньше, чтобы обеспечить хороший объём производительности и количество виртуальных машин для клиентов.

Поэтому решили, что самое эффективное для локации в Москве — это встать у партнёров.

А свой ЦОД — уже имиджевая и компетентная история. Так как основная часть в железе — это его энергоэффективность и производительность, то там, где этот ресурс нам очень дёшево обходится, как раз и имеет смысл довыжимать остатки из «устаревающего» железа. При этом делать как раз на нём сервис, который к количеству vCPU и RAM не привязан.

Но во второй собственный ЦОД я не пойду, это прямо точно лишнее.

В каком виде ЦОД был
Он нам достался в виде ангара, который был когда-то котельной, из которого просто всё котельное оборудование вынесено. Окна там заставлены просто поликарбонатом. Заливки пола не было. Энергохозяйство тоже по разрешённой мощности такое среднестатистическое.

Мы начали с энергии. Добавили трансформаторы. Сейчас у нас на площадке три стоит. Сделали расчёт кабельной линии — она у нас выдерживает на самом деле намного больше, кабель толстый, броня хорошая. Котельная столько не потребляла. Под эту возможность мы увеличили разрешённую энергомощность хозяйства. Фидер (ячейка на подстанции) тоже полностью наш, кабельная линия до него, распредустройство. Прямо всё от подстанции.

На улице стояли контейнеры, а само здание просто пустовало.

У нас есть ещё одна площадка, и она достаточно большая, чтобы разместить там воздушную часть ЦОДа. Потому что мы в процессе некоторое время назад взяли ближе к подстанции 0,6 гектара земли. Ровный кусочек, пригодный для строительства.

Проект ЦОДа на новой площадке


Пока мы решаем, будем ли мы его делать именно в этом здании, то есть выращивать два машзала, закрывать прорехи и так далее, или пойдём строить прям с нуля. Сейчас у нас буквально в процессе формируются и лягут на стол два варианта для расчёта. Здание при имеющейся инфраструктуре почти незаметно в расходах. Плюс в команде у нас есть те, кто строил ЦОДы.

Самое смешное, что при таких технологиях даже наш ангар будет с коэффициентом энергоэффективности 1,05. По расчёту. Это даже не мифические 1,4 для недостижимых воздушных ЦОДов, это классика иммерсивки.

Как мы собираемся сертифицировать по Tier котельную
Никак.
Мы строим под Tier-3, но не будем ничего сертифицировать.

Сертификация — это долгая, дорогая и ненужная история, если ЦОД не продаётся как услуга. Если у вас сервис, то важно SLA, фактический аптайм и т.п. Тот же Amazon, в принципе, долгое время вообще не заявлял никакую сертификацию у своих ЦОДов. Если долго искать, то можно найти, где они говорят что-то вроде «Tier3+». И вроде бы это на словах. Но в целом, когда у вас облачный сервис, которому плюс-минус пофигу, что целый ряд отрубился во время распределённой задачи, то сертификация не очень актуальна. Лишнее удорожание просто и лишний входной барьер.

h3llo.cloud
auth.h3llo.cloud/register

Чем короче полоска, тем, вероятно, больше вас переподписывают или более старое железо предлагают. Что это за график — ниже

Идея очень простая: покупаю одинаковые тарифы на одинаковом железе и гоняю тесты. Удивляюсь, немного охреневаю, снова гоняю тесты.

Ну и вот теперь показываю вам.

Задача: понять, насколько одинаковый тариф с одинаковым количеством vCPU и RAM выражается в реальную производительность у разных провайдеров.

Забегая вперёд — у меня нет вопросов к Селектелу, Клауд.ру (Сберу) и Яндексу (почти). У них переподписки, вроде, нет. А вот дальше начинается дичь.

Разница такая, что я чувствую, что оставлю свою инсталляцию и сделаю из этого сервис, чтобы можно было прогнать тесты каждому самостоятельно. Но пока давайте покажу результаты.

Какие тесты гонял
Обычный Geekbench 6. То есть это проверка CPU + RAM, но не дисковой подсистемы. Это синтетический тест, он не показывает производительность в реальных задачах вроде задёрганной 1С или реальной работы веб-сервера под нагрузкой, но считается, что его результаты достаточно показательны, чтобы админы могли ориентироваться на них. Со временем, возможно, я добавлю тесты дисковых подсистем и сети, но пока только вычисления.

В тест попали компании, которые предоставляют услугу публичного облака как основную или одну из основных.

Везде я брал виртуальную машину с одинаковой конфигурацией — 2 vCPU и 4 Гб оперативной памяти. Оговорка: у Рег.ру такой конфигурации нет, пришлось взять 2vCPU и 2Гб RAM.

Тест запускался одновременно на всех облаках, чтобы избежать разных оценок из-за разной нагрузки в разное время дня.

Тест гонялся больше суток, каждый час, чтобы увидеть возможную разницу. Каждый замер можно проверить по ссылке в таблице.

Тест запускался на трёх разных машинах у каждого провайдера, чтобы не упереться в ограничения какого-то конкретного локального проблемного сервера.

Результаты Singe Core теста

Тут всё чётко:


Здесь зависит от машины, с одной не повезло:


Аналогично:


Тут график пожевало:


Вопросов нет:


Вопросов больше, чем ответов:


Сводная:


Сводный средний балл:


Из расчёта на затраченный рубль (больше — лучше):


Коротко — лучше всего идти в Селектел, Сбер или Яндекс, а вот на ВК, Рег.ру и Таймвебе есть устойчивое ощущение переподписки. В случае Рег.ру — ПЕРЕПОДПИСКИ, которую пытаются компенсировать низкой ценой.

Результаты Multicore
Странный результат показывает Яндекс — показатели тестов почти как на SingleCore:


Облако ВК — есть просадки:


Клауд.ру — очень хорошие результаты, но была непонятная просадка:


Таймвеб — график попердолило:


Селектел — вопросов нет:


Рег.ру удивляет:


Сводная:


Сводный средний балл:


И вот из расчёта на затраченный рубль (больше — лучше):


Ссылки на сырые данные
pastebin.com/JK4i6wcC
static.h3llo.cloud/bench_final.xlsx

Результаты словами
Как я говорил, нет вопросов к Сберу, Селектелу и с натяжкой — к Яндексу. К остальным есть.

Облако ВК в среднем ниже на 15‐20%, а отдельные инстансы — на 30%, и может показать внезапную просадку на такой же конфигурации с таким же процессором, и это, похоже, рандом.

Дальше очень много вопросов к Таймвебу, но у них есть оговорка — они продают линейку «Стандарт» и нигде не указывают, что она переподписанная. Есть отдельная линейка Dedicated, где они говорят, что закрепляют одно ядро за пользователем без переключений. Там с производительностью всё более-менее, но цена примерно в два раза выше, чем у других провайдеров. То есть вы покупаете переподписанный тариф, но у вас складывается ощущение, что нормальный.

Производительность MultiCore тестов Яндекса сильно удивила — там, где другие провайдеры честно показали x2, результаты Яндекса почти идентичны Single Core-тестам.

У ряда других «публичных» сервисов мы не смогли попасть в консоль или вовсе не нашли публичного прайс-листа. У ряда облаков мы заполнили формы, и дальше с нами связался менеджер, который начал предлагать индивидуальное ценообразование.

Также мы не включили 1cloud.ru, потому что у них нет ни последних образов ОС, ни адекватного механизма тестирования, честной почасовой оплаты тоже не нашли — при создании ВМ консоль просит пополнить баланс на месяц. Этим, кстати, и Таймвеб грешит. Cloud4Y перезвонили и на пожелание разместиться в хостинге с прозрачной почасовой оплатой предложили «идти туда, где такое есть».

В общем, из рейтинга CNews мы не тестировали провайдеров, если у них не было публичного ценника, механизма доступа по регистрации без диалога с менеджером и т.п., то есть их сложно отнести к настоящим публичным облакам, которыми можно просто прийти и воспользоваться. RUVDS мы не включали, так как они позиционируют себя не как облачный хостинг, а как виртуальные машины VDS.

Основной вывод
Есть провайдеры, которые сильно переподписывают ресурсы, при этом ничего об этом не говорят (или говорят незаметно), когда вы покупаете за среднерыночную цену. Вы, возможно, ожидаете получить примерно то же самое, а получаете в два раза меньше производительности.

Ещё ограничение теста
Мы не проверяли две следующие гипотезы:

• Новые пользователи в первый месяц получают грейс-период, когда их не переподписывают. Это мы узнаем позже, потому что будем гонять тесты регулярно и оставим это как публичный сервис.
• Машзалы ряда провайдеров ещё не полностью загружены, переподписка есть, но не чувствуется. Это тоже мы узнаем по мере развития событий со временем. Но уже сейчас видно, что у некоторых провайдеров разные инстансы одинаковой конфигурации, созданные в одно и то же время, показывают разный результат.

Зачем я это делаю
Мы строим публичное облако в России. Хочется строить его сразу прозрачно, честно и чтобы было понятно, за что пользователи платят.

Мы оставим этот набор тестов, плюс, вероятно, сделаем позже дашборд и для публичных провайдеров, и для себя, чтобы можно было сравнить.

Пока же мне было просто интересно, кто насколько реально отдаёт 1 vCPU, и я получил числа. Что с ними делать и делать ли — решать уже вам.

Относительно нас самих — не думаю, что мы покажем плохие результаты в категории «производительность за вложенный рубль». Я точно не планирую так сильно переподписывать ресурсы. Кроме того, у меня стоят Xeon 4 на DDR5, которые в 2–3 раза производительнее того, что стоит у других.

Когда через несколько лет это оборудование устареет, мы планируем его ротировать в проекты, где оплата ведётся за конкретные операции, а не за ресурс. Конечно, оплаты за выполненные операции — это идеальная модель, но у нас в России всё же пока стандарт — за время. Да и Serverless Horrors — жанр, получающий всё более широкое распространение. Мы задались амбициозной целью изменить эту историю.

Соответственно, цикл жизни, который я строю для облака, такой: vCPU, продаваемые как самые топовые, когда проживают какое-то время и устаревают, уходят на PaaS-сервисы, где не тарифицируется само железо.

h3llo.cloud
auth.h3llo.cloud/register