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

По мере того как компании стремятся использовать возможности искусственного интеллекта, резко возрос спрос на специализированные вычислительные ресурсы, в частности, на графические процессоры (GPU). Графические процессоры раньше ассоциировались в основном с играми и графикой, но теперь стали основой многих операций машинного обучения. 

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

Привет, Хабр!

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

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

В прошлой первой части мы рассмотрели само понятие Cloud native и модели облачных вычислений. А так же выделили концепцию облачных приложений. В этой части рассмотрим их принципы.

Вряд ли можно поспорить сегодня с аргументом, что скорость и эффективность обработки информации стали ключевыми факторами успеха любого цифрового проекта. При этом традиционные подходы к хранению и обработке данных уже не могут удовлетворить растущие потребности бизнеса и пользователей. Именно в этот момент на сцену выходит Apache Ignite — высокопроизводительная, распределенная платформа для вычислений в памяти. Рассказывает Александр Столяров, ведущий программист компании Comindware.

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

Возможности 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, избегая при этом крупных капиталовложений.