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

Привет, Хабр, на связи product owner компании Modus Александр Чебанов. Сегодня поговорим про работу и анализ данных в облаке, а еще об архитектуре нашего нового облачного BI для малого и среднего бизнеса.

Облачные сервисы — это отлично, но, если ими начинают пользоваться разные команды в компании, вопрос управления затратами превращается в «черный ящик». Когда мы только начинали нашу историю с FinOps, то даже не представляли, насколько эффективнее можно раскрутить историю с арендой облачных мощностей. Но оказалось, что расширение практик управления затратами помогает получить от облаков еще больше отдачи и не допустить необдуманных трат (а то один стартап решил как-то вечером расшифровывать ДНК на арендованных мощностях, а утром закрыл компанию, потому что потратил все деньги). О том, как это было, какие грабли мы собрали по пути, как нам помогла команда ИБ и за счет чего мы теперь экономим до 20% на облачных счетах, читайте под катом.

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

Наша статья основана на материале Mitigating the Performance Impact of Network Failures in Public Clouds, авторами которого выступают ученые из Microsoft Research и Университета Южной Калифорнии. Здесь мы разберемся в тонкостях SWARM и ее роли в снижении влияния сетевых сбоев на производительность в публичных облаках.

Производные Stable Diffusion набрали огромную популярность, что не могло обойти стороной нагрузку серверов Google Colab, которые они на бесплатной основе предоставляли энтузиастам в сфере ML.

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

В общем, пару месяцев назад таки появился в правилах использования Colab пунктик об Webui`ях разных. Но мы пользователи опытные, знаем что не пойман - не вор. Однако, всевышние силы посылают всплывающие окна, тем самым даже думать нам запрещают об нарушении правил!

Казалось бы, что может быть общего между такими разными вещами: рычагами, подшипниками и ступицами и виртуальной сущностью в облаке? Давайте искать.

Колесо автомобиля - это главное, что связывает его с физической реальностью вокруг (ДТП и сотрудников ГИБДД рассматривать не будем). Так же и устройства Интернета вещей (IoT) связывают его с физической реальностью, поэтому такие системы иногда называют кибер-физическими. Как кантилевер атомного силового микроскопа сканирует наномир, так колесо автомобиля сканирует дорожный ландшафт. Что при этом делает подвеска? Она помогает колесу делать свою работу максимально эффективно.

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

Меня зовут Денис Филиппов, я руководитель отдела разработки стриминговой платформы EdgeЦентр. Сегодня расскажу вам, как нам удалось сократить задержки в трансляциях до 4–6 секунд, и как нам в этом, в частности, помог свой JIT (Just in time) packager.

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

В последние несколько лет в контексте Интернета вещей (IoT) можно все чаще встретить термины Digital Twins (Цифровые двойники) и Device Twins (Двойники устройств), которые описывают создание виртуальных моделей физических объектов или процессов, но они имеют различные сферы применения. В силу их внешней схожести часто происходит путаница. Давайте попробуем разобраться, чем являются эти понятия в индустрии IoT.

После ухода с российского рынка известных платформ виртуализации мы стали активно искать альтернативные варианты, и особый интерес у нас вызвали азиатские решения. До этого мы уже успели протестировать несколько сервисов, как отечественных, так и зарубежных, и вот нам попался совершенно новый для нашего рынка продукт — 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 уже был инструмент для проверки качества аудио / видео, но мы никогда не планировали и не проектировали его для масштабной работы (нашей целью было отслеживать тысячи одновременных потоков и увеличивать это число со временем). Подключая к сервису больше потоков, мы заметили, что масштабная эксплуатация инфраструктуры обходится очень дорого. Мы также заметили узкие места в масштабировании, которые мешали нам отслеживать тысячи потоков. Итак, мы сделали шаг назад и пересмотрели архитектуру существующего сервиса, сосредоточив внимание на стоимости и узких местах масштабирования...