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

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

Прежде всего:
Действующие контракты остаются без изменений (= их стоимость не будет увеличена), и вы по-прежнему можете обновить их по старой цене (подробнее см. раздел «Преимущества действующих контрактов»).

VPS Lite:

• Мы повысили цены на серверы VPS Lite до 20%.
• Технические характеристики сервера остаются прежними.

VPS:

• Цены на виртуальные серверы x86 повышаются до 40%.
• Кроме того, мы сокращаем объем дискового пространства. Это основано на предварительном анализе фактического использования дискового пространства.
• Мы продолжим развертывать наши VPS на флэш-накопителях с использованием RAID 6, но гарантировать работу с NVMe мы не можем.

Корневые серверы:

• Цены на серверы с правами root повышаются на 70–110%.
• Кроме того, мы сокращаем объем дискового пространства. Это основано на предварительном анализе фактического использования дискового пространства.
• Мы также представили RS 500, чтобы вы могли получить преимущества корневого сервера и для небольших систем.
• Мы вернули в наш ассортимент большие системы RS 12000 и RS 16000, но пока они доступны только по запросу.

Другой:

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

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

• Существующие клиенты с имеющимися серверами могут продолжить модернизацию своих серверов по ранее известным ценам и с сохранением технических характеристик. Это в равной степени относится как к VPS (включая VPS Lite и VPS ARM), так и к корневым серверам.
• Другими словами, RS 1000 G12 можно модернизировать до RS 2000 G12 по старой цене 18 евро (без НДС). Мы намеренно сохранили свободные ресурсы на существующем оборудовании для вас. Это также относится к продлению действующих контрактов.
• Обновленные цены применяются только при заказе нового сервера.
• Воспользуйтесь нашей биржей обмена серверов (Tauschbörse): вы сохраните старые цены на G12, даже если передадите право собственности через нашу биржу обмена. Однако это предложение действительно только до тех пор, пока товар есть в наличии, или пока клиенты предлагают для обмена ненужные им серверные планы.

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

Вот несколько оптовых цен на DDR5 (источник: TrendForce)


DDR4 выглядит ничуть не лучше (источник: TrendForce)


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

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

Таким образом, перед нами стояло четыре варианта:

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

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

Что касается вариантов:

• Вариант 1 хуже, чем просто повышение цен, потому что если у вас уже запущены проекты, и вам понадобится еще один небольшой сервер от нас, у вас вообще не будет возможности его получить, а нам это не нужно.
• Вариант 2 означал бы размещение большего числа клиентов на одном и том же оборудовании. Технически это возможно, но мы не хотим этого делать и не будем. Та же цена за худшую производительность — это скрытое увеличение затрат, а мы выступаем за высокую производительность наших серверов. Мы намеренно не будем этого делать и никогда не будем.
• Вариант 3 был бы невозможен, поскольку он не привел бы к получению каких-либо разумных предложений.

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

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

В Netcup мы с пользой проведем это время и уже работаем над следующим:

• Мы совершенствуем наши внутренние процессы, чтобы в будущем предлагать вам еще более качественное обслуживание.
• Мы предложим вам дополнительные товары и услуги. Подробнее об этом мы расскажем на нашем мероприятии для сообщества примерно через месяц.
• Мы также улучшим нашу кодовую базу и предложим вам более удобные панели, хотя работа над этим еще продолжается.
• В нынешних рыночных условиях никаких ценовых акций, подобных «Черной пятнице», проводиться не будет.

Окончательно:
Все мы в Netcup понимаем, что повышение цен вряд ли кого-то обрадует. Однако рыночная ситуация не оставляет нам иного выбора, кроме как пойти на эту корректировку.

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

Спасибо всем за понимание. Я открыт для любых вопросов и, как и в прошлый раз, постараюсь ответить на них здесь.

С уважением,
Алекс

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

С 22 сентября по 22 октября проводим «Осеннюю распродажу серверов» — скидки до 30% на гибкие конфигурации.
1dedic.ru/promo/sale-autumn

Скидка 15%
На гибкие конфигурации на базе процессоров:
Xeon Scalable

• Silver-4516Y+ 2.2-3.7ГГц (24 ядра)
• Silver-4210 2.2-3.2ГГц (10 ядер)

Скидка 20%
На гибкие конфигурации на базе процессоров:
AMD Ryzen

• Ryzen 9 5950X 3.4-4.9ГГц (16 ядер)
• Ryzen 9 3900X 3.8-4.6ГГц (12 ядер)
• Ryzen 9 9950X 4.3-5.7ГГц (16 ядер)
• Ryzen 9 7950X 4.5-5.7ГГц (16 ядер)

Скидка 30%
На гибкие конфигурации на базе процессоров:
Intel Xeon Е5

• E5-2630v4 2.2-3.1ГГц (10 ядер)
• E5-2620v4 2.1-3.0ГГц (8 ядер)
• E5-2630v3 2.4-3.2ГГц (8 ядер)
• E5-2640v4 2.4-3.4ГГц (10 ядер)

Intel Xeon Е3

• E3-1270v6 3.8-4.2ГГц (4 ядра)
• E3-1230v6 3.5-3.9ГГц (4 ядра)

Скидка действует при заказе нового сервера на любой выбранный период (1, 3, 6 или 12 месяцев) и суммируется со специальной ценой за период. Чем дольше период оплаты, тем больше выгода.

С каждым сервером вы получаете бесплатный выделенный IPv4-адрес и неограниченный трафик 100 Мбит/с.

https://firstdedic.ru

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

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

А чтобы апгрейд был ещё приятнее, дарим скидку 25% на новые VDS при заказе на 1, 3, 6 или 12 месяцев.
Акция действует для всех локаций: России, Нидерландов и Казахстана.
firstvds.ru/actions/dev_day_2026
firstvds.ru/?from=86281

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

• Запустили сервис «Управляемые приложения» (Managed Apps)
• Вы выбираете готовое приложение, а HOSTKEY берёт на себя сервер, установку, настройку, обновления и техническое обслуживание.
• Для ранних клиентов действует скидка 25%.

hostkey.ru/apps/managed-applications/

Обновили S3-хранилище

• Линейка тарифов пополнилась Cold Storage для долгосрочного хранения данных с редкими запросами.
• На сайте появился калькулятор для расчёта прогноза расходов.
• Хранилища доступны в России, Нидерландах и Франции.

Расширили функционал личного кабинета:

• Добавили возможность управлять инфраструктурой как кодом с помощью Terraform.
• Обновили раздел «Обслуживание» — теперь это «Центр поддержки». В нём можно создавать обращения в техническую поддержку и другие службы, а также отдельно оформлять и отслеживать заявки на работы по конкретным серверам.
• В панели управления серверами появилась возможность самостоятельно менять IP‑адрес — бесплатно один раз в 7 дней. Продолжаем улучшать механизм ротации IP‑адресов, доступных при замене.
• Добавили сканирование портов арендованного сервера с помощью Nmap.
• Запустили новую версию Native‑консоли и обновили интерфейс SSH-доступа к виртуальным серверам.

В ближайших планах

• В бета-режиме запустили новую схему тарификации услуг: все списания производятся с баланса аккаунта. Это позволяет реализовать классическую почасовую тарификацию: сервер остаётся активным, пока на балансе достаточно средств. Почасовая тарификация для всех новых заказов серверов уже скоро!
• Также в тестовом режиме запустили Status Page: публичную страницу, которая показывает доступность отдельных элементов нашей инфраструктуры, например узлов виртуализации. Статус сервисов обновляется в реальном времени, а в дальнейшем добавим историю инцидентов. Публичный запуск уже скоро.
• Продолжаем работать над новыми сервисами: управляемым Kubernetes, резервным копированием по расписанию и комплексным сканированием на уязвимости.
• Одновременно расширяем возможности существующих сервисов: готовим развертывание пользовательских приложений из GitHub-репозиториев и Docker‑образов в качестве управляемых приложений, а также расширяем географию S3‑хранилища.

Инфраструктура

• Пополнили парк оборудования в Испании, США и Франции и добавили новые конфигурации в России — в том числе серверы на AMD Ryzen 9 9950X3D и GPU‑серверы на базе NVIDIA RTX PRO 5000 Blackwell с объёмом видеопамяти 72 ГБ.
• Запустили новую площадку в Нидерландах — NorthC Amsterdam 1 уровня надёжности TIER III.
• Расширяем георезервирование внутренних ресурсов и оптимизируем инфраструктуру для повышения отказоустойчивости и безопасности сервисов.
• Обновляем логику проверки и выделения новых подсетей IP‑адресов.

Виртуализация

• Добавляем для ряда конфигураций VPS автоматическую защиту от подбора паролей методом грубой силы (брутфорс). Это поможет снизить нагрузку на процессор от массовых попыток авторизации сразу после появления нового сервера в сети.
• Сокращаем сроки сдачи новых серверов и продолжаем улучшать процессы переустановки.
• Внедряем OpenStack в отдельных локациях.

В ближайших планах VM

• Минимальная конфигурация для знакомства с услугой.
• Обновление линейки Storage: конфигурации с быстрыми дисками.

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

• Управляемый n8n Community Edition
• Запускайте ИИ‑ассистенты и настраивайте автоматизацию рабочих процессов прямо через браузер.
• Управляемые мессенджеры Rocket.Chat и Element Messenger
• Получите свой собственный мессенджер и настройте для своей команды.

hostkey.ru/apps/managed-applications/

Что такое ИИ‑агенты: создание, примеры и возможности в 2026 году
Разбираемся в архитектуре ИИ‑агентов, MCP и актуальных инструментах. Показываем рабочий код и рассказываем о скрытых расходах и рисках.
hostkey.ru/blog/258-chto-takoe-ai-agenty-sozdanie-primery-i-vozmozhnosti-v-2026-godu/

Внутренняя документация: как сделать, чтобы её читали, на примере ONLYOFFICE Workspace
Делимся, как создать удобную и актуальную базу знаний на примере ONLYOFFICE Workspace: шаблоны, роли и регулярное обновление данных.
hostkey.ru/blog/261-vnutrennyaya-dokumentatsiya-kotoruyu-nikto-ne-chitaet-kak-sdelat-chtoby-chitali-na-primere-onlyoffice-workspace/
Большие модели и цена миллиона токенов
Действительно ли китайские модели дешевле, и почему цена не всегда отражает реальные расходы на ИИ. Отвечаем на эти вопросы.
hostkey.ru/blog/264-bolshie-modeli-i-tsena-milliona-tokenov

Поскольку ожидается, что дефицит чипов приведет к росту стоимости серверного оборудования на 15–35 % к концу 2026 года, мы напоминаем всем, что цены на наши серверы, имеющиеся на складе в Германии, по-прежнему соответствуют рыночным ценам до этого повышения, и любой заключенный сейчас контракт фиксирует эту цену на весь срок действия договора.

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

Наши немецкие серверы уже установлены в стойки, протестированы и готовы к развертыванию.
Это вам подходит, если:

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

www.leaseweb.com/en/c/dedicated-server

Наша линейка следующего поколения появится этой осенью.
Хотите обсудить сроки? Наша местная команда расскажет вам о том, что уже доступно и что будет доступно в будущем: sales@de.leaseweb.com

С наилучшими пожеланиями,
Ваша команда Leaseweb в Германии

А вы тоже организуете общение между микросервисами по HTTP/1.1 + JSON? Так вот, адекватные люди на хайлоаде давно так не делают.

Как это выглядит в классическом REST: какой-нибудь сервис заказов стучится в сервис оплаты и отдаёт JSON-файлик: {«user_id»: 123, «amount»: 1000}. Принимающий сервис этот текст читает, парсит, валидирует, переводит в машинный код…

JSON сделан для людей. Человеку удобно читать JSON, потому что это текст. Но серверу для обработки текста приходится тратить драгоценные такты процессора на поиск и разбиение. Ещё классический HTTP тащит за собой гигантские заголовки с метаданными. Часто они весят больше, чем сама полезная нагрузка. Ещё если вы передаете число 123456789, в JSON оно займёт 9 байт (по байту на символ), а в бинарном виде — всего 4 байта.

Гугл ещё в 90-х это посчитал. Они со своими масштабами столкнулись с проблемами за 10 лет до того, как с ними столкнулся весь остальной мир. Для DNS-а в Гугле сделали внутреннюю систему Borg-NS. Они пытались сделать предка gRPC, чтобы решить две фундаментальные проблемы. Во-первых, зоопарк технологий. Когда у тебя тысячи микросервисов — одни на Java, другие на C++, третьи на Python, четвёртые на Go (ладно, этих тогда точно не было) — им нужен единый язык общения. Нужно было запилить стандарт: описали спецификацию интерфейса в одном независимом стиле — и система сама сгенерировала готовый сетевой код для всех нужных языков.

А во-вторых — это как раз производительность обмена.

Поэтому сейчас используется gRPC. И вот когда началась какая-то там по счёту волна санкций, внезапно выяснилось, что в России нет поддержки серверов gRPC.

Не было, пока не появился наш клиент EasyP. Передаю слово Эдгару Сипки — Founder EasyP & Sipki Tech. Он расскажет, зачем и как это сделали.

Зачем это обычным людям?
99% наших пользователей — это бэкендеры, которые строят микросервисы. Бэкенд общается с бэкендом. Да, связывать бэкенд с фронтом, например, с мобилой, тоже можно, это не проблема, но это просто не стандарт рынка. В России, да и вообще во всём мире, я знаю буквально только одну компанию — Uber, кто реально сидел с gRPC на мобилках.

Первый запрос — стандартизация. Объёмы, как у Гугла, есть не у всех, а вот зоопарк — точно у всех. Можно использовать OpenAPI, а можно gRPC. Big Tech (американские Google, Amazon, Microsoft или наши Ozon, WB и Сбер) ещё и экономят на железе. В рамках их гигантских архитектур работают тысячи микросервисов, и в секунду происходят сотни тысяч таких внутренних вызовов.

Чтобы стал понятен масштаб: представьте, что вы открываете приложение, чтобы заказать такси или купить кроссовки. Вы нажимаете всего одну кнопку «Заказать», но под капотом этот единственный клик порождает каскад из 50−100 микросервисных вызовов. Сервис авторизации проверяет токен, сервис геопозиции ищет водителя, биллинг проверяет карту, сервис рекомендаций обновляет вашу ленту, антифрод анализирует паттерн поведения, а пуш-сервис готовит уведомление. И все они общаются между собой. Если на каждом таком шаге сервер будет тратить миллисекунды на открытие новых соединений и парсинг текстовых JSON-ов со скобочками, то на 10 тысяч пользовательских запросов в секунду вы немного охренеете. Гонять тяжёлые текстовые данные со всеми массивными HTTP-заголовками и постоянно их парсить обходится для серверов дорого.

gRPC работает поверх HTTP/2 и использует бинарную сериализацию: данные передаются не как текст, а как архив. HTTP/2 умеет мультиплексировать запросы, он не открывает новое соединение для каждого чиха, а гоняет сотни параллельных запросов по одной уже открытой «трубе». Во-вторых, данные пакуются в бинарный формат. Сервер-отправитель не пишет ключи типа «user_id», он отправляет только числовые теги и сами значения. Сервер-получатель не занимается парсингом текста, он просто считывает смещения в памяти процессора. Это работает куда быстрее.

В итоге это раза в 2−3 дешевле по пропускной способности сети и нагрузке на процессоры. То есть gRPC реально очень сильно экономит деньги на железе (мы говорим про миллионы долларов на закупку и обслуживание серверов), но этот эффект в полной мере ощущается только при огромных объёмах.

Ну и де-факто этот протокол сильно защищённее, там есть ещё ряд бонусов.

Но есть нюанс: с этим протоколом исторически было очень неудобно работать
Когда вы пишете обычный REST-сервер, вам надо как-то объяснить команде одного микросервиса, как работать с микросервисом другой команды. Нужна документация. Если вы когда-нибудь работали с OpenAPI (или Swagger) для REST, то Protobuf (язык описания интерфейсов для gRPC) — это альтернатива OpenAPI, которая просто родилась фактически за 10−15 лет до него.

Protobuf — это строгий контракт. В нём чётко написано: поле номер один — это ID юзера, тип — целое число (int32 user_id = 1;), поле номер два — сумма платежа.

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

Представьте вполне реальную ситуацию на проде: команда сервиса оплаты решает изменить тип поля или удалить поле user_id и молча выкатывает обновление. Или, например, джун в сервисе корзины решает, что сумму заказа лучше передавать не в виде строки «100.50», а в виде целого числа (в копейках — 10050), и меняет это в своём коде. А сервис заказов всё ещё шлёт старый формат. Сервис оплаты получает неожиданный тип данных, не может его прочитать, выкидывает ошибку, и всё падает в рантайме. Платежи не проходят, бизнес теряет миллионы рублей в минуту, а дежурные инженеры в панике ищут, где именно сломалась цепочка из десятков микросервисов.

Чтобы как-то впихнуть эту стихийную разработку в рамки и защититься от таких ошибок, в мире появилось четыре конкурирующих инструмента: один от Uber, один от индусов, один от канадцев и один ещё от кого-то. В итоге в какой-то момент канадский стартап сказал всем остальным троим: «А давайте мы вас всех купим? Давайте вы все станете мной?»

И все стали ими, переложили наработки в единый продукт Buf Build, получили 93 миллиона долларов инвестиций и заняли нишу.

А потом наступает 2023 год
Архитектура российского ИТ-рынка начинает сильно меняться.

У меня это выглядело так: мне надо через пару дней выступать в Сколково на конференции HighLoad с темой работы с gRPC. Доклад о том, насколько этот протокол важен и ценен для бизнеса. Все мои примеры архитектуры и пайплайнов в докладе были построены на Buf Build. Доклад приняли. А потом Buf Build выпускает заявление:

— До свидания. Мы в России блокируем доступ к своим сервисам!

Куратор моего доклада был сотрудником Yadro — это наш гигант, производящий серверное оборудование и железо для ЦОДов. Он был там кластер-лидом, и у него как раз стояла острая рабочая задача в рамках компании: решить проблему того, что инфраструктура Buf перестала собираться в России. Он говорит мне: «Эдгар, а ты сможешь сделать так, чтобы Buf Build заработал в России?»

Ну, потому что невозможно же делать доклад о продукте, который не работает, кому это надо? Я говорю: «Ну, окей, я подумаю».

Я сел и ровно за один месяц просто зареверс-инжинирил их серверную инфраструктуру. Она у них проприетарная, не open source. Я буквально стучался по их API и по крупицам формировал понимание (это было ещё даже до появления мощных нейросетей), как именно это говно у них устроено и почему оно так работает.

Разобравшись в логике, я с нуля создал эмулятор их сервера. В итоге их собственная CLI и кусок клиентской части продукта завелись с моим сервером так, как будто он для них родной.

Всё заработало.

Мы повозились, отладили процессы, показали это решение прямо на конференции, все кайфанули. А потом мы сели и такие: «А зачем нам делать поддержку инструмента, который нас забанил?» Мы по факту сделали костыль. Зачем нам поддерживать чужую экосистему? Давайте сделаем прям свою полноценную замену?

Первыми, кто взял мой сервер, были как раз Yadro и Positive Technologies. В каком-то общем чате инфраструктурщиков ребята написали: «Так и так, кто-то же должен был столкнуться с блокировкой Buf, как решаете?» Им кинули запись моего доклада. Они взяли оттуда продукт, стали активно юзать у себя на больших объёмах, и в итоге столкнулись там с очень специфическими багами.

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

Полноценный dev-tool для разрабов, чтобы им было просто и безопасно работать с Protobuf'ом. Наш продукт — EasyP.

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

Как это работает на практике?
Во-первых, наш инструмент — это строгий контролёр. Он заставляет тебя писать контракты по единым правилам компании, чтобы код никуда не вылез за рамки стайлгайдов.

Во-вторых — это пакетный менеджер. Раньше, чтобы сервис уведомлений на Python узнал о новых ручках сервиса заказов на Go, разрабам приходилось руками копировать .proto-файлы или городить костыли с Git-сабмодулями. Мы же сделали элегантный механизм: ты просто указываешь нужную версию контракта, EasyP сам скачивает зависимости из реджистри и фиксирует их в easyp.lock. Дальше ты пишешь easyp generate, и мы внутри изолированных Docker-контейнеров (или через Wasm) сами компилируем нужный код. Больше никакой боли с фразами «а у меня локально всё собиралось» — у всех разработчиков всё генерируется абсолютно идентично.

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

Ну и наконец — интеграция с IDE. Специально для OpenIDE с поддержкой Go прямо из коробки мы разработали плагин EasyP, который уже сейчас доступен в маркетплейсе для установки. Пишешь в .proto строку import «orders/v1/order.proto» — и IDE сразу знает, откуда эта зависимость тянется по твоему easyp-конфигу. Никаких красных «unresolved import»: работает переход к определению и автокомплит по чужим контрактам, будто они лежат локально. Заодно плагин подтягивает в редактор правила и стандарты EasyP — те самые, по которым потом бьёт линтер на CI.

В 2025 мы выяснили, что стали монополистами в России
Да, продукт нишевый, инфраструктурный, но монопольный. Сервера полностью наши, CLI-ка написана нами. Мы Git-native, то есть никакие корпоративные контракты не улетают на чужие облачные сервера, всё крутится внутри контура компаний. Плюс мы полностью open source под лицензией Apache 2.0.

Долгое время мы специально сохраняли обратную совместимость с CLI-кой от канадского Buf'а, чтобы российским компаниям было легко переезжать. Но этим летом мы выкатим мощную энтерпрайзную версию, зарелизим версию 1.0 (потому что мы всё ещё числимся в бете уже 3 года) и планируем отсечь старое легаси, отказавшись от прямой совместимости с их синтаксисом. Но чтобы никого не бросать, мы сделаем изящную механику: девопсу достаточно будет вызвать одну команду нашей CLI-ки, и она автоматически прочитает старый конфиг Buf'а, переведёт его в наши концепции и бесшовно сгенерирует родной конфиг EasyP.

Что мы делаем в H3LLO
У нас были высокие требования к инфраструктуре. Собственно, пошли смотреть облака по рынку, их там ровно три, подходящих два. В H3LLO написал в поддержку, типа, у меня нет проблем, есть идея. И они связались!

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

Зачем нам облако, если всё можно On-Prem? Ну, надо было разместить реестр схем. Это облачный репозиторий, где хранятся, версионируются и документируются все Protobuf-файлы компании. Туда можно в любой момент загружать новые версии API-контрактов и скачивать актуальные схемы. Обычно это сервер в корпоративной сети, но у нас ещё работает малый бизнес, поэтому это для него.

P.S. А, и кстати, вот ссылка на комьюнити t.me/easyptech

Облако общего доступа / Агент ИИ (Harness) в альфа-версии


Чатбот Консоли V8 основан на Агент ИИ. Пока что мы разрешили только GET-запросы.

Сервис-провайдер M1Cloud (ООО «Стек Групп») и крупнейший независимый провайдер ИT-инфраструктуры в России Selectel закрыли сделку по приобретению 100% доли M1Cloud. Общая сумма сделки составит не более 2,6 млрд рублей.

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

M1Cloud предоставляет приватные облачные решения на базе партнерских дата-центров в Москве. Более 15 лет компания специализируется на высоконадежной виртуальной ИТ-инфраструктуре с высоким уровнем отказоустойчивости. Решения M1Cloud используют более 170 представителей среднего и крупного бизнеса. Прогнозная выручка M1Cloud за 2026 год – 1,5 млрд рублей.

Приобретение облачного провайдера M1Cloud – это последовательный шаг в усилении роли Selectel на облачном рынке. Selectel сочетает органический рост с точечными приобретениями. Решения о покупке принимаются при уверенности, что они создают дополнительную ценность для акционеров и способствуют развитию бизнеса в долгосрочной перспективе. Ключевые компетенции M1Cloud сосредоточены в оказании услуг по созданию и поддержке приватных облачных решений. Сделка усиливает наше присутствие в этом сегменте и дополняет существующую экспертизу компании. Нашим приоритетом остается сохранение высокого качества сервиса и предоставление гарантий надежности для клиентов Selectel и M1Cloud

подчеркнул Олег Любимов, генеральный директор Selectel.

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

отметил Евгений Горохов, исполнительный директор M1Cloud.

Выручка Selectel за 6 месяцев 2026 года достигла 10,2 млрд рублей, показав рост на 14% год к году. Рентабельность по скорр. EBITDA составила 53%. Клиентская база Selectel расширилась до 44,5 тыс. на конец первого полугодия 2026 года.

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

С начала 2026 года регистрации в тематических зонах заметно выросли: .tech прибавила 60%, .space — 54%, .site — 30%, .pro — 24%, .online — 13%. Ключевая причина изменений — в ИИ-алгоритмах поисковых систем: предприниматели стали чаще выбирать доменную зону не по географии, а по смыслу бизнес-проекта.

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

«Для бизнеса важнее узнаваемость зоны, наличие свободного имени и то, насколько адрес соответствует самому проекту. Для технологического проекта естественно выглядит .tech, для профессиональных услуг — .pro, а .online или .site подходят практически любому бизнесу. В итоге выбор становится шире, а сама доменная зона всё чаще работает как часть позиционирования проекта», — отмечает Ася Вартазарьян, линейный руководитель отдела аналитики группы Рунити (объединяет Руцентр, Рег.ру, Рег.облако, SpaceWeb и другие ИТ-компании).

В условиях, когда искусственный интеллект решает, какой сайт включить в ответ пользователю, тематический домен помогает бизнесу сразу обозначить свою нишу и повысить шансы попасть в число рекомендованных. Российский рынок пока находится на стадии формирования спроса. Многие предприниматели пока выбирают классическое SEO, рассматривая GEO (Generative Engine Optimization, продвижение в ответах нейросетей), как следующий шаг.
www.reg.ru/solutions/product/seo
www.reg.ru/solutions/product/geo

«Главная цель предпринимателей — заявки и их рост, а не просто трафик или позиции сайта в поисковой выдаче. Тематический домен становится тем самым первым сигналом для нейросети, который в будущем помогает бизнесу привлечь клиентов. 70% наших пользователей приходят с готовыми сайтами, которые хотят доработать, а 30% — это новые сайты. И тем, и другим мы помогаем выстроить стратегию, где домен работает не просто как адрес, а как часть воронки», — комментирует Владислав Иванов, коммуникационный директор Рег.решений, сервиса для предпринимателей от Рег.ру.

Национальные доменные зоны при этом не сдают позиций: за январь–август 2026 года .ru прибавила 8% — почти до 750 тысяч регистраций,.рф — 20%, до 95 тысяч. Тематические зоны растут вместе с рынком, но опережают его: они забирают регистрации, где бизнесу важно не просто быть в сети, а сразу обозначить сферу деятельности, особенно если подходящее имя в .ru уже занято.