Облачные вычисления *

В Istio всё начинается с маленькой «удобной» идеи — прокси рядом с каждым подом. А заканчивается тем, что XDS разносит по кластеру тонны Listener’ов, Route’ов и Cluster’ов, дублируя конфиги для сервисов, которые вы даже не трогаете. Память тает, GC злится, а апдейты сервисов превращаются в шторм.

В статье пойдет речь о том, как мы в проде с 20K+ подов «урезали аппетит» сайдкаров на гигабайты. Обсудим, где работает жёсткое ограничение видимости, когда спасает Ambient Mesh, зачем нужен ленивый XDS и почему «волшебной кнопки» нет — но есть комбинации, дающие двузначную экономию. Эта статья написана по мотивам моего доклада для конференции Saint HighLoad++.

Как ускорить серверную часть мобильной MMO-игры в 2,5 раза и при этом сократить инфраструктурные расходы в 5 раз? В этом кейсе рассказал опыт проекта The Firstborn: почему виртуальная машина перестала справляться с нагрузкой ещё до релиза, зачем мы отказались от геораспределённой базы данных, как выбор точки размещения повлиял на пинг по всему миру и почему переход на выделенный сервер с NVMe кардинально изменил стабильность, деплой и скорость серверного просчёта боёв.

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

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

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

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

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

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

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

Передовые модели, такие как Gemini 3 от Google и Claude 4.5 Opus от Anthropic, были обучены не на оборудовании Nvidia, а на новейших Tensor Processing Units компании Google — TPUv7 на базе архитектуры Ironwood. Это показывает: жизнеспособная альтернатива GPU-центричному стеку ИИ уже существует — и она способна заметно изменить экономику и архитектуру обучения моделей предельного масштаба.

Эта статья — для владельцев малого и среднего бизнеса, а также для IT-директоров, которые впервые сталкиваются с задачей переноса инфраструктуры. Мы не будем углубляться в настройки Kubernetes или тонкости сетевой маршрутизации. Наша цель — дать понятную «дорожную карту» переезда с точки зрения бизнеса: зачем это нужно, сколько это стоит и как не остановить работу компании в процессе.

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

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

Привет, я Павел Мохляков. Вообще я Data Science-инженер в Cloud.ru, но сегодня решил, почему бы не рассказать как с помощью LLM-шлюза можно использовать несколько LLM через один API и при этом снизить риск утечки данных, контролировать расходы и соблюдать требования №152-ФЗ. Кроме того, покажу пример тестового подключения и объясню, что делать на каждом этапе.

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

Еще лет 10 назад iPhone в корпоративной среде воспринимали примерно как электрокары Тесла. Да, красиво, да, статусно, но как с этим жить – решительно непонятно. Особенно людям, которые дальше Windows и Outlook вообще никогда не выглядывали. Но мир поменялся, айтишники забыли, как патчить KDE2 под FreeBSD, а iPhone научились нормально работать с MDM. Однако остался вопрос: насколько все это применимо к реальной жизни, особенно в наших широтах, где к эппловским девайсам отношение стало, мягко говоря, настороженным?

Представьте ситуацию: ваше приложение в Kubernetes работает стабильно, но внезапно начинается пиковая нагрузка. Поды пытаются масштабироваться, HPA увеличивает их количество, но... они висят в статусе Pending. Почему? Потому что в кластере недостаточно ресурсов на нодах. Cluster Autoscaler должен добавить новые ноды, но процесс занимает много времени, иногда нода не создается из-за проблем с облаком. За это время пользователи уже получают ошибки 503, а вы теряете деньги. Знакомо?

А теперь обратная ситуация: нагрузка спала, поды удалились, но ноды продолжают работать вхолостую. Вы платите за простаивающие ресурсы, потому что Cluster Autoscaler слишком консервативен в удалении нод или не может оптимально «упаковать» workloads.

Есть ли способ сделать это быстрее, умнее и экономичнее? Меня зовут Даниил Кондрашов, я разработчик Managed Kubernetes в Selectel. В этой статье познакомлю вас с Karpenter — современным решением для автоматического управления нодами в Kubernetes, которое решает эти проблемы принципиально иначе. Подробности под катом!

Осенью 2025-го многие, как и я, открыли любимый магазин железа, чтобы «по-быстрому взять ещё 32–64 ГБ DDR5 под игры, IDE и пару Docker-контейнеров» — и закрыли вкладку с лёгким культурным шоком. Память, которая летом стоила «адекватных» денег, внезапно стала стоить почти как видеокарта среднего уровня.

Если коротко, это не «жадность магазинов», а последствия довольно сложной перестройки всего рынка DRAM под ИИ-серверы и HBM-память. В статье разберёмся, что происходит на фабриках памяти, почему страдают именно ПК-модули, чего ждать в 2026-м и как принимать решения об апгрейде, если вы геймер, разработчик или просто любитель собирать железо.

Привет, Хабр!

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

Привет, Хабр! Меня зовут Иван Дюков. Последние несколько лет я занимался разработкой и оптимизацией сетевых компонентов для облачной инфраструктуры. Среди моих проектов — участие в разработке сетевого процессора для компании Google в составе российского подразделения Intel, а также оптимизация программных сетевых функций для облака Samsung в команде Samsung R&D Institute Russia. В настоящее время работаю над сетевыми сервисами для платформы Cloud.ru Evolution в R&D-команде Cloud.ru.

Основное направление моей работы — это исследования программных сетей, сетевых сервисов и их производительности. В этой статье хочу рассказать, как я искал точку отказа прокси-балансировщика. Расскажу и про метрики, и про инструменты, и как я автоматизировал измерения. Путь оказался весьма извилист, наполнен граблями и шишками, зато результат был познавательными. Статья будет интересна разработчикам сетевых сервисов, DevOps-инженерам и тестировщикам, исследующим проблемы производительности сети и сетевых сервисов.

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

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

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

Я вижу двух кандидатов: очки AR и складные смартфоны. И если о «раскладушках» можно дискутировать и спорить, что это не нечто новое, а улучшение смартфона (но про это мы поговорим в другой раз), то очки — принципиально новое устройство для взаимодействия с интернетом и реальностью.

В этой статье разберём, во сколько обходится LLM-сервис при нагрузке в 100 000 диалогов в день и где проходит граница окупаемости разных вариантов. Посмотрим на стоимость облачных API, аренды GPU и собственного железа, а заодно прикинем, какая инфраструктура нужна, чтобы всё это выдержало боевой трафик.

Казалось бы, облака давно разобрали по косточкам. Уже даже финдирам понятно, что и как там устроено. Но стоит только кому-то запустить новую платформу или свернуть проект, как начинается: а почему не в паблике? А почему не в приватке? А оно нам вообще надо? И пошло-поехало. Хотя на деле-то выбор часто донельзя очевиден, если знать пару нюансов.

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

Еще 3-5 лет назад у многих было полное ощущение, что облака победили. Казалось, что теперь только тарифы, all-in cloud и все такое. Но нет. В какой-то момент некоторые компании вновь начали думать о том, чтобы не выгружать все в облако, а держать у себя под боком и даже возвращать их облака на землю. В результате сложилось два противоположных лагеря, где одни вкладывают миллиарды в строительство ЦОД, а другие продолжают арендовать ресурсы и не парятся. Разница в подходах, понятное дело, не случайна.

Есть три вида писем, которые могут испортить блаженную субботу: уведомление безопасности, предупреждение об отключении электричества и, очевидно, повторное напоминание о том, что вы задолжали облачному провайдеру один цент — да, именно $0,01. Услугами DigitalOcean я пользуюсь с 2013 года, хотя для личных задач я этот сервис использую редко, просто авторизуюсь несколько раз в неделю для обеспечения поддержки моих клиентов на этой платформе.