Привет, я Виталий Ранн, занимаюсь в Cloud.ru всем, что связано с брокерами и кешами. Сегодня я хочу закопаться в вопрос о том, в каких случаях self-hosted Redis — это нужно, правильно и неизбежно, а в каких — это победа мастерства над здравым смыслом. Те, с кем мы виделись на конференции GoCloud, уже знают, о чем пойдет речь, а если вы пропустили, знакомьтесь. Вас ждет история DevOps’a Алексея, который столкнулся с проблемой падения Redis в своей компании. Наш герой виртуозно использовал StatefulSet, Redis Sentinel, Helm-чарты Bitnami и другие инструменты, что позволило ему сократить время деплоя и снизить количество сбоев на 70%. Но захочется ли повторить его путь другим — большой вопрос. 

Статья будет особенно полезна тем, кто только пробует Redis на вкус и еще не определился, в каком формате с ним стоит взаимодействовать: self-hosted или managed PaaS.

В изданиях уровня Forbes хорошим тоном считается предрекать забвение привычных облачных платформ. Якобы на их место придут отраслевые решения, и вот тогда все заживут счастливо. Поделюсь мнением, почему это не так, как минимум в России.

Database by Julian-Faylona

Многие облачные платформы предлагают базы данных как сервис (Database as a Service, DBaaS). Базу можно создать в облаке в несколько кликов, не тратя время на настройку и поддержку. Но не всем приложениям облачные базы данных подходят.

Мы расскажем, как на старте проекта не ошибиться с выбором облачной СУБД. Эта статья — вольная переработка нашего вебинара (видео тут).

Мы разберем, когда стоит и не стоит использовать DBaaS, какие особенности нужно учесть при работе с ними и как выбрать подходящую базу данных с учетом особенностей ИТ-инфраструктуры, объема и специфики задач. В конце посмотрим, как устроено создание базы данных в облаке и какие операции с ней доступны, на примере DBaaS Mail.ru Cloud Solutions.