Статьи, исследования и обучающие материалы

Возможно, у вас была (или есть) потребность развернуть свой IT-проект, будь то простой бот, сайт, приложение или сложный высоконагруженный сервис. И, возможно, вы пользовались для этого AWS, MS Azure или другими провайдерами публичных облаков.

Тогда вы знаете, что для использования таких облачных решений нужно иметь весьма «глубокие карманы». Так, чтобы развернуть обычный сервис распознавания речи на 20 потоков вы заплатите Яндексу за виртуальные машины и за СУБД 43500 руб. в месяц (расчет на основе нашего ASR). И это еще достаточно простой, пусть и требовательный к CPU сервис. Кажется, облачные услуги должны быть более доступны с финансовой точки зрения.

В этой статье мы расскажем, как делали свое облако, с чем столкнулись, и что в итоге получилось.

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

Сегодня мы с вами рассмотрим способ деплоя Telegram-бота, написанного на библиотеке aiogram 3.

Для деплоя мы будем использовать сервис Amvera, так как он позволяет развернуть любое приложение через простой push в Git (а если не хотите работать с Git, можно перетянуть файлы в интерфейсе). Кроме того, этот сервис дает стартовый баланс, которого хватит на все эксперименты и первое время работы вашего приложения.

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

Некоторое время назад к нам пришел клиент – крупный металлургический комбинат. Продукцию комбината перевозят поезда. А во время железнодорожных грузоперевозок машинисты и диспетчеры должны переговариваться согласно регламенту. За переговоры не по регламенту - штраф. Поэтому "боль" клиента была сильной: получить систему автоматического контроля регламента переговоров по рации во избежание финансовых потерь и снижения риска катастроф.

В последнее время я вижу много хайпа вокруг Kubernetes. Кажется, что он везде и всюду, а если кто-то его еще не использует, то он безнадежно отстал. Но странно принимать решение о внедрении технологии только на основе ее популярности в СМИ. Давайте разберемся: а вот лично вам правда нужен K8S?

В статье мы рассмотрим, как развернуть в облаке приложение на Java, на примере Spring Boot приложения с встраиваемой базой данных H2. А именно, мы попробуем развернуть приложение с простым REST API, сборкой Maven и тремя эндпоинтами, позволяющими добавить продукт, получить список всех продуктов и узнать общую стоимость всех продуктов.

Подход требует некоторых усилий во время первого запуска, но в дальнейшем позволяет обновлять приложения простым push в Git.

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

Начну с того, что самым распространенным способом является задание request и limit по CPU и RAM. С оперативной памятью все достаточно просто - при превышении потребления, OMM-Killer остановит процесс. А вот с CPU есть целый ряд нюансов и возможностей наступить на грабли.

Это происходит из-за того, что ресурс процессора делится не долями, а по времени.

Это можно представить так: