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

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

Пару месяцев назад прошел очередной Enterprise Connect — ключевая конференция года про облачные технологии в бизнес-коммуникациях. Мы осмыслили происходившее и составили краткое резюме по основным трендам 2017. Если интересно, куда развиваются облачные сервисы (как SaaS, так и PaaS) в США и к чему мы с вами в России идем следом — велкам под кат.

Amazon EC2 Container Service – это высокопроизводительный сервис управления контейнерами с высокими возможностями масштабирования.

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

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

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

Привет, Хабр! Я Артём Чаадаев, бэкенд-разработчик в Туту. Я занимаюсь разработкой на языке Go в команде ассортимента размещения. Мы отвечаем за работу с контентом отелей и интеграции с поставщиками.

Периодически мы собираем данные для аналитики, и в таких задачах нужно реализовывать схему отправки данных в ClickHouse. В этой схеме мы преобразовываем данные с помощью Redpanda Connect. В статье покажу простой практический пример работы с этим инструментом, который должен помочь тем, кто только начинает его использовать. А еще расскажу про преимущества и проблемы, с которыми мы столкнулись при работе с Redpanda Connect.

Моя основная деятельность — конфиденциальная обработка данных. Это такая развивающаяся область науки и техники, в которой часто возникает что-то новое, поэтому терминология ещё не устоялась. То, чем я занимаюсь, по-английски называется Secure Multi-Party Computation, а на русский переводят как совместные или многосторонние вычисления. Однажды я видел перевод: «многопартийные вычисления», – но, надеюсь, это единичный случай. Лично мне нравится вариант: «конфиденциальные вычисления», который использует википедия. Его буду использовать и я.

Представьте, вы собрали какие-то ценные данные, зашифровали их и сохранили на диске. Таким образом, вы защищаете данные во время хранения (data-at-rest). Далее, предположим, вам нужно передать данные по сети с одного сервера на другой. Серверы устанавливают защищённое соединение и обмениваются данными – снова зашифрованными. Так серверы защищают данные во время передачи (data-in-transit). Пока всё знакомо и понятно. Далее вы собираетесь делать то, ради чего вы эти данные собирали, хранили и передавали: использовать их. Что-нибудь посчитать, агрегат какой-нибудь, статистику или даже модельку обучить. Анализировать зашифрованные данные —, затруднительно, поэтому вы их расшифровываете и… делате беззащитными.

Во-первых, это странно: вы старательно защищали данные, когда хранили и передавали, и вдруг почему-то перестали. Во-вторых, это опасно: атаки, утечки, несанкционированный доступ, всё, что угодно может случиться, когда данные уязвимы. Ну, и в-третьих, расшифровывать не обязательно: существуют методы, защищающие данные, когда они используются (data-in-use). Совместные конфиденциальные вычисления – один из них.

Привет, Хабр! В этой статье расскажем о гиперконвергенции и как ее можно реализовать разными путями в облаке. А также просто разберемся, чем она отличается от виртуализации с контейнерами. Для начала дадим определение гиперконвергенции, далее поговорим про OpenStack и VMware и затем перейдем к деталям реализации. 

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

Говорить будем о том, как выстраивать отказоустойчивую и катастрофоустойчивую IT-систему, чтобы избежать убытков при сбоях. Сразу заметим, что эти изыскания актуальны на определённом уровне развития компании. То есть ларьку с шаурмой они явно не нужны, а вот для сети шаурмичных из 200 объектов уже актуальны.

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

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

В этом отношении показательны прогнозы Gartner. Исследователи считают: до 2025 года включительно 99% сбоев в облачной безопасности будут происходить по вине заказчика. Некомпетентность здесь не при чем, просто технологии так быстро развиваются, что большинство не успевает приспособиться к ним. Компании с трудом оценивают всю полноту рисков, связанных с использованием облачных вычислений.

Однако разберем вопрос по порядку.