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

Возможности LLM (large language models) вызывают растущий интерес со стороны разработчиков, исследователей и обывателей. Нейросети имитируют человеческую речь, могут поддержать диалог и написать текст на заданную тему. Однако с расширением спектра возможностей и применений интеллектуальных систем увеличивается и простор для некорректного использования результатов их работы. Становится сложнее понять, когда нейросеть генерирует не совсем точный ответ, и оценить риски для рабочих задач в той или иной отрасли. Поговорим о том, насколько серьезна проблема и что с ней можно сделать.

Пример методики сравнения производительности гипервизоров 1 и 2 типа и неожиданные выводы, которые были получены опытным путем.

Всем привет! Я работаю Dev-Ops инженером в небольшой команде и мы уже 4-ый месяц используем Yandex Cloud для наших сервисов. Так сложилось, что с Kubernetes и облачными вычислениями я столкнулся впервые, поэтому многое приходится изучать на ходу, иногда на "горьком" опыте. На данный момент наши микросервисы развернуты в зональном кластере Kubernetes с одним рабочим узлом, по одной реплике на каждый Deployment. Это означает, что никакой отказоустойчивости и масштабируемости нет и при малейшей нагрузке приложения упадут.

Поэтому, пока нагрузка идет только от команды разработчиков, я решил заранее побеспокоиться об отказоустойчивости наших сервисов, развернутых в Yandex Managed Service for Kubernetes. Сегодня я разверну на своем облаке Kubernetes кластер и покажу как будет вести себя автомасштабируемое приложение под нагрузкой. Для управления инфраструктурой воспользуемся Terraform, для имитирования нагрузки сервисом Yandex Load Testing (в стадии Preview) от Yandex Cloud.

• Заливка проекта на GitHub.
• Аренда и настройка облачного сервера по SSH.
• Настройка nginx для раздачи статических файлов.
• Сжатие бандла.
• Подключение домена.
• Настройка HTTPS.
• Настройка Docker.

Статьи про YDB публиковались на Хабре ещё до выхода в open source, а отдельным блогом мы обзавелись всего несколько недель назад. В связи с этим проведём небольшую ретроспективу — что пишут про YDB в других хабах.

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

Закупать серверы или использовать «облако»? Какие риски есть в каждом из этих подходов? Как помирить тех, кто платит по счетам в компании и тех, кто может запустить дорогой ИИ-сервис на десять минут, забыть про него и обеспечить к концу месяца непредвиденные расходы организации? 

Облако даёт компаниям гибкость и мощность, но может легко выйти из-под контроля. Как приручить этого опасного зверя? 

В статье разберём:

• Как взять облако под контроль и сделать расходы предсказуемыми.

• Как FinOps помогает оптимизировать использование облачных сервисов.

• Как избежать типичных ошибок и рисков при внедрении этой практики.

Привет! Меня зовут Иван Мартинович, я заместитель руководителя департамента поддержки прикладных систем и сервисов — вице-президент в ВТБ. В теперь уже далёком 2019 году мы запустили одну из ключевых программ цифровой трансформации банка, нацеленную на обеспечение надёжности целевых систем. О том, как мы проводили её в разгар пандемии коронавируса и что из этого всего вышло, мне бы и хотелось сегодня рассказать. Добро пожаловать под кат.

Это история о том, как мы сократили расходы на AWS на 80% всего за две недели.

Для разработчиков AWS — это Клондайк возможностей

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

Привет, Хабр, на связи 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.