Концепция общего доступа к ресурсам
После ухода с российского рынка известных платформ виртуализации мы стали активно искать альтернативные варианты, и особый интерес у нас вызвали азиатские решения. До этого мы уже успели протестировать несколько сервисов, как отечественных, так и зарубежных, и вот нам попался совершенно новый для нашего рынка продукт — HCl от Sangfor. В этом посте рассказываем про наш опыт по установке Hyper Converged Infrastructure.
Кроме очевидной комплиментарности 5G и IoT, можно заметить общий архитектурный подход при создании платформ для этих технологий – Cloud Native. Это создает условия для более глубокой их интеграции. Видится привлекательным решением сделать часть функций платформы IoT стандартными функциями архитектуры 5G.
Давайте посмотрим, как это можно сделать с помощью Device Twins.
Всем привет. Меня зовут Путилин Дмитрий (Добрый Кот) Telegram.
От коллектива FR-Solutions : Продолжаем серию статей о K8S.
Наша команда получила запрос на оценку менеджера K8S от МТС Облака и составление объективного обзора проделанной работы инженеров МТС. Хочу отметить, что данная статья не является заказной, поэтому мы сосредоточимся на объективном анализе плюсов и минусов этого решения.
В данной статье мы хотим осветить особенности организации безопасности в облаках и рассказать, как CSPM продукты помогают автоматизировать процесс обеспечения безопасности в рамках методологии DevSecOps. Также расскажем о продукте собственной разработки, который как раз решает эту задачу.
Сейчас все облачные платформы, построенные по принципу Cloud Native, используют виртуализацию и контейнеризацию для реализации микросервисной архитектуры. Поэтому здесь и далее мы будем говорить о безопасности виртуальных машин (VM), понимания под ними как полную виртуализацию, так и паравиртуализацию и контейнеры (Docker и т.п.). Идеалом для пользователя облака было бы получить безопасность своих удаленных виртуальных машин такую же (или почти такую же), как при локальной работе. Как этого достичь?
Речь пойдет о технологиях, доступных уже сейчас, но применение которых еще должно найти свою нишу.
Эта заметка является переводом поста в блоге Дэвида Ханссона под заголовком «Even Amazon can't make sense of serverless or microservices». Здесь минимум редактуры для сохранения оригинальной авторской подачи.
Команда Prime Video из Amazon опубликовала довольно примечательное тематическое исследование, посвящённое их решению отказаться от своей микросервисной serverless-архитектуры и заменить её монолитом. Этот шаг сэкономил им ошеломляющие 90% (!!) эксплуатационных расходов, а также упростил систему. Какая победа!
Но помимо восхваления их здравого смысла, я думаю, что здесь есть более важный момент, который применим ко всей нашей отрасли...
В Prime Video мы предлагаем нашим клиентам тысячи прямых трансляций. Чтобы гарантировать, что клиенты беспрепятственно получают контент, Prime Video создала инструмент для мониторинга каждого потока, просматриваемого клиентами. Этот инструмент позволяет нам автоматически выявлять проблемы с качеством воспринимаемого контента (например, повреждение блока или проблемы с синхронизацией аудио / видео) и запускать процесс их устранения.
У нашей команды анализа качества видео (VQA) в Prime Video уже был инструмент для проверки качества аудио / видео, но мы никогда не планировали и не проектировали его для масштабной работы (нашей целью было отслеживать тысячи одновременных потоков и увеличивать это число со временем). Подключая к сервису больше потоков, мы заметили, что масштабная эксплуатация инфраструктуры обходится очень дорого. Мы также заметили узкие места в масштабировании, которые мешали нам отслеживать тысячи потоков. Итак, мы сделали шаг назад и пересмотрели архитектуру существующего сервиса, сосредоточив внимание на стоимости и узких местах масштабирования...
Не имеет значения, по каким причинам вы решили мигрировать. Главное, чтобы все прошло по плану. А для этого нужно не только обзавестись актуальными бэкапами, но и, собственно, спланировать весь процесс. Ниже — несколько инструментов, которые могут быть полезны при миграции ВМ между различными платформами виртуализации.
Привет!
На связи Ваня Гулаков, DevOps из CloudMTS. Сегодня хочу рассказать про контейнерные ОС и как мы искали для сервиса Managed Kubernetes ту самую.
До недавнего времени мы использовали дедушку CentOS 7, который уже давно отжил свое. Основные причины переезда, соответственно, старое ядро и отсутствие поддержки.
Раз уж переезд был неизбежен, появилась мысль присмотреться к так называемым Linux For Containers или Container Optimized OS дистрибутивам.