Castle in the sky by PiotrDura

Публичное и частное облако одного провайдера — два разных продукта или одна и та же платформа, просто развернутая на разном оборудовании? На примере решения для Х5 Retail Group я, Илья Болучевский, технический директор Mail.ru Private Cloud, расскажу, в чем отличия и как построен процесс внедрения облака вендора в корпоративную инфраструктуру.

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

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

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

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

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

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

И это несмотря на то, что множество моих коллег в нынешней и прошлых компаниях (Facebook, Toptal, Klarna, Яндекс) — прекрасные профессионалы с огромным опытом, которым явно есть чем поделиться. Тем не менее, большинство из них неактивны публично. Почему?

Хабр, привет! Меня зовут Николай Бутенко, я руководитель Private Cloud в Mail.ru Cloud Solutions, и сегодня хочу обсудить с вами одно из самых больших заблуждений, с которыми я встречаюсь каждый день. Если вы когда-либо работали с облачными сервисами, то наверняка знаете о распространенном мнении, что перенос приложения в облако является панацеей от всех возможных с ним проблем. Я регулярно сталкиваюсь с такой позицией на встречах с самыми разнообразными заказчиками.

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

Поэтому если перед вами стоит задача построить на 100% отказоустойчивую и высокодоступную (High Availability, HA) систему, я рекомендую придерживаться подхода Multicloud Native Service, сочетающего лучшее в подходах Multicloud и Cloud Native. Такой подход не сводится только к использованию контейнеров: чтобы приложение могло пережить любой отказ, нужно подумать и об инфраструктуре, в частности использовать не одну, а минимум две независимые площадки, например провайдера публичного облака и частную инфраструктуру.

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

Это продолжение практикума по развертыванию Kubernetes-кластера на базе облака Mail.ru Cloud Solutions и созданию MVP для реального приложения, выполняющего транскрибацию видеофайлов из YouTube. 

Я Василий Озеров, основатель агентства Fevlake и действующий DevOps-инженер (опыт в DevOps — 8 лет), покажу все этапы разработки Cloud-Native приложений на K8s: от запуска кластера до построения CI/CD и разработки собственного Helm-чарта.

Напомню, что в первой части статьи мы выбрали архитектуру приложения, написали API-сервер, запустили Kubernetes c балансировщиком и облачными базами, развернули кластер RabbitMQ через Helm в Kubernetes. Сейчас во второй части мы настроим и запустим приложение для преобразования аудио в текст, сохраним результат и настроим автомасштабирование нод в кластере.

О Kubernetes и его роли в построении микросервисных приложений известно, пожалуй, большинству современных IT-компаний. Однако при его внедрении часто возникает вопрос — какой вариант установки выбрать: Self-Hosted или Managed-решение от одного из облачных провайдеров. О недостатках первого варианта, думаю, известно всем, кто проходил через ручное конфигурирование K8s: сложно и трудоемко. Но в чем лучше Cloud-Native подход?

Я Василий Озеров, основатель агентства Fevlake и действующий DevOps-инженер (опыт в DevOps — 8 лет), покажу развертывание Kubernetes-кластера на базе облака Mail.ru Cloud Solutions. В этом цикле статей мы создадим MVP для реального приложения, выполняющего транскрибацию видеофайлов из YouTube. 

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

Но порог входа в Kubernetes для Data Scientists все еще остается высоким. Мы хотим помочь в работе с непростой технологией, поэтому покажем, как можно быстро развернуть Spark внутри Kubernetes и запустить в нем свое приложение.

Команда Kubernetes as a Service в Mail.ru Cloud Solutions перевела контрольный список для запуска Redis внутри кластера Kubernetes. С ним стоит ознакомиться до того, как перейти к использованию Redis под рабочей нагрузкой.

Redis — популярное in-memory хранилище данных и кэш с открытым исходным кодом. Этот продукт стал важным компонентом построения масштабируемых микросервисных систем. Многие облачные провайдеры предлагают полностью управляемые сервисы Redis: Amazon ElastiCache, Azure Cache for Redis, GCP Memorystore (и на платформе MCS тоже есть такой управляемый сервис — прим. переводчика). Однако Redis также можно легко развернуть в Kubernetes, если вам нужно полнее контролировать его конфигурации. Прямо из коробки у него уже достойная производительность, но если вы собираетесь использовать Redis с рабочей нагрузкой, то сначала проверьте, выполняются ли все пункты этого чек-листа.

Команда Mail.ru Cloud Solutions перевела полное пошаговое руководство для создания образа Docker (GPU или CPU) вместе с объяснением всех передовых методов, которые следует использовать для обслуживания любого программного обеспечения на основе машинного обучения. Далее текст от лица автора.

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

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

• об общей работе Docker;
• о том, как собирать и запускать Docker;
• о создании и синтаксисе Dockerfile.

Новые экспериментальные модели машинного обучения важно быстро разворачивать в продакшене, иначе данные устареют и появятся проблемы воспроизводимости экспериментов. Но не всегда это можно сделать быстро, так как часто процесс передачи модели от Data Scientist к Data Engineer плохо налажен. Эту проблему решает подход MLOps, но, чтобы его реализовать, нужны специальные инструменты, например Kubeflow.

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

Я Александр Волынский, архитектор облачной платформы Mail.ru Cloud Solutions. В этой статье познакомлю вас с Kubeflow на базовом уровне и покажу, как его разворачивать. Мы не будем подробно знакомиться со всеми компонентами Kubeflow, потому что это выходит за рамки базового ознакомления.

Приветствую, братцы!

Задача получения актуальной информации и совета опытных коллег сегодня актуальна как никогда. С одной стороны, сложно превзойти крупнейшие ИТ-сообщества в Slack. С другой стороны, важно иметь контакт с коллегами в нашей стране, в своем городе. Телеграм за последние годы стал крупнейшей площадкой для русскоязычного ИТ-сообщества, присоединяйтесь, не отставайте :)

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

Я, Хамзет Шогенов, архитектор облачной платформы Mail.ru Cloud Solutions, расскажу о системах хранения данных, доступных на нашей платформе, подробно остановлюсь на их технических характеристиках и оптимальных вариантах использования.

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

Глеб Корсунов, CBDO Holyweb, обсудил с Михаилом Кебичем, руководителем разработки публичного облака Mail.ru Cloud Solutions, какие существуют опасения относительно аутстафф-подрядчиков, как безболезненно подключить внешних специалистов к инхаус-команде и как влиять на их мотивацию. 

Kubernetes сейчас называют стандартом для оркестрации контейнеров. Он лежит в основе многих облачных платформ контейнеризации: например, мы давно развиваем наш Kubernetes aaS на платформе Mail.ru Cloud Solutions.

Однако Kubernetes далеко не первый подобный инструмент на рынке: некоторые из систем-предшественников продолжают активно использовать и вроде бы даже успешно.

Почему так происходит, несмотря на то, что Kubernetes, можно сказать, одержал победу в своем классе и мы видим много примеров, когда он приходит на смену другим решениям? Например, не так давно разработчики Mesosphere DC/OS, в основе которой лежал Apache Mesos, прекратили ее развитие и сфокусировались на другой своей платформе — D2iQ Kubernetes (DKP). Думаю, что стоит разобраться, всегда ли хорош Kubernetes, когда оправдано использовать другие оркестраторы и о каких подводных камнях стоит знать.

Я Дмитрий Лазаренко, директор по продуктам облачной платформы Mail.ru Cloud Solutions (MCS). В этой статье расскажу об устройстве ряда оркестраторов-предшественников, сравню их с Kubernetes, посмотрю на его преимущества и недостатки по сравнению с ними.

Я, Дмитрий Лазаренко, руковожу командой, создающей и внедряющей собственный Kubernetes aaS на платформе Mail.ru Cloud Solutions. Давно работая с внедрением Kubernetes, мы часто сталкиваемся с недопониманием нюансов этой технологии. Хочу рассказать о типичных стратегических просчетах при внедрении Kubernetes в крупных проектах.