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

Российский бизнес активно инвестирует в облака, но по сравнению с развитыми странами этот сегмент у нас в стране пока занимает довольно скромное место. В США, к примеру, облачные сервисы уже составляют до половины корпоративных ИТ-расходов, тогда как в России их доля в разы ниже. Однако это лишь значит, что у нас в стране есть огромный потенциал для роста в данной сфере. Только за прошлый год облачный рынок в РФ вырос более чем на 36%, и это определило не только позитивный, но и негативный тренд, который заключается в неэффективном расходовании средств. Стало ясно, что техническим специалистам уже недостаточно просто разрабатывать и поддерживать системы. Теперь нужно понимать экономику каждого виртуального сервера, каждой базы данных, каждого терабайта трафика. Но как? Помогут, как всегда, метрики.

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

Начиная с 2009–2010 годов в мире идет стремительное развитие интернета вещей (internet of things, IoT). Устройства IoT собирают данные и передают их для обработки и анализа в централизованные облачные системы. Однако по мере роста числа таких устройств стали появляться серьезные проблемы.

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

Как подключиться к облаку надёжно и гибко.

Привет, Хабр! Меня зовут Влад Одинцов, я техлид и product owner сетевых сервисов в K2 Cloud. Мы строим облачную платформу, где стабильное и безопасное подключение клиентов к инфраструктуре — ключевой элемент.

В этой статье расскажу про шесть способов подключения к инфраструктуре клиента в К2 Облаке: от Elastic IP до Direct Connect. Каждый из способов решает разные задачи — от простого доступа по публичным адресам до построения отказоустойчивых архитектур гибридного облака. Расскажу о плюсах, ограничениях и подводных камнях.

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

«- Внимание! Нагрузка растёт неравномерно! О нет, ручное управление не помогает…
- Сбой! Повторяю: сбой! Инфраструктура падает!
- Нужно больше ресурсов!»

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

Роль технического директора (Chief Technology Officer, CTO) быстро меняется, поскольку новые технологии постоянно меняют отрасль ИТ. Чтобы оставаться на шаг впереди, в 2025 году каждый технический директор должен знать о последних тенденциях в области искусственного интеллекта, облачных вычислений и кибербезопасности. В этой статье мы рассмотрим эти важнейшие из этих направлений.

Начнем с искусственного интеллекта.

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

Во 2 части этой серии мы рассмотрели практическое развертывание кластера Ceph на двух площадках с отдельной tie-breaker локацией, с использованием пользовательского файла спецификации для компонентов Ceph, CRUSH-правил и мест размещения компонентов.

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

Привет! Меня зовут Евгения Тарашкевич. Я инженер из группы эксплуатации К2 Cloud, и моя специализация — системы хранения данных. Сегодня хочу поделиться с вами опытом и знаниями о работе с объектным хранилищем S3.

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

Привет, Хабр! Изначально Ubuntu Server создавался как легкая и производительная операционная система для работы с задачами на серверах. Именно поэтому на них по умолчанию не устанавливается графический интерфейс (GUI) — это позволяет экономить ресурсы, ускорять работу системы и повышать ее безопасность.

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

Современный бизнес стремительно внедряет технологии искусственного интеллекта — от автоматизации процессов и анализа данных до создания инновационных продуктов на базе генеративного ИИ. Однако для эффективной работы AI/ML алгоритмов требуются специализированные вычислительные системы, способные обрабатывать колоссальные объемы данных с использованием параллельных вычислений.

В условиях растущего спроса на высокопроизводительные решения и необходимости технологической независимости российские компании все чаще обращаются к отечественным производителям. ITPOD, входящий в корпорацию ITG, представляет флагманский сервер ITPOD-SY4108G-D12R-G4 — мощную вычислительную платформу, специально разработанную для самых требовательных задач искусственного интеллекта и машинного обучения.

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

RabbitMQ — это популярный брокер сообщений, который реализует стандарт AMQP и который позволяет эффективно управлять коммуникацией между сервисами через очереди. И в этой статье мы разберем основные типы обменников (exchange): Direct, Topic, Headers и Fanout, которые напрямую участвуют в процессе маршрутизации, а также приведем примеры их настройки в Spring Boot.

За 10 лет, что существует Serverless‑подход, бессерверные функции стали для многих разработчиков чем‑то привычным и удобным. С их помощью можно быстро написать несколько строк кода для реализации конкретной бизнес‑логики и задеплоить, не думая о развёртывании, настройке и обслуживании инфраструктуры. Нужный код запустится автоматически при срабатывании триггера, как это принято в событийно‑ориентированной архитектуре. Но если таких функций в приложении потребуется очень много — что поможет сохранить нужную скорость работы и другие преимущества Serverless?

Меня зовут Сергей Ненашев, последний год я разрабатываю в Yandex Cloud сервис бессерверных функций Cloud Functions. В нашем облаке с ним можно запускать код в виде функции без создания и обслуживания виртуальных машин.

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

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

Как мы построили DevOps в локальном облаке без AWS и managed-сервисов: GitLab CI, Kubernetes, PostgreSQL, мониторинг на Prometheus и Grafana. 10 000 TPS в пике, 12 минут на деплой, 2 минуты на восстановление — и всё это в проде.

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

Привет! Я Андрей Квапил (или kvaps) и в этой статье я опишу наш путь организации доставки приложений в Kubernetes, объясню недостатки классического GitOps в локальной разработке и покажу, как новая утилита cozypkg решает эти проблемы. Материал рассчитан на разработчиков, знакомых с Helm и Flux.

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

Привет! На связи Михаил Шпаков, руководитель разработки в Timeweb Cloud.

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

Когда вы работаете в облаке, всё выглядит структурировано: список серверов, IP-адресов, баз данных, кластеров. Но в какой-то момент возникает вопрос: а как всё это связано между собой?

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

Мы в Timeweb Cloud решили это изменить. Инфраструктура — это карта, а не таблица. Её нужно рисовать, а не запоминать.

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

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

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

Вот здесь и появляется первый важный вопрос: Что происходит с твоими данными?