Комментарии 12

Неужели CloudSQL для этого кейса вам обходится дешевле, чем self hosted PostgreSQL?

Подобные вопросы часто возникают когда речь заходит про облачные решения. Этот кейс некорректно было бы рассматривать и высчитывать в отрыве от основного процесса. На определённых объемах данных, задействованных решениях и используемых инструментах self hosted становится не прагматично и не целесообразно использовать.

Вы можете поделиться цифрами и ответить на вопрос?


Объём данных, нагрузка на базу, какой CloudSQL machine type используете, ha или нет и т.д.?


Уточню, что оценку трудозатрат на настройку и поддержку self hosted PostgresSQL не трогаем, только затраты на CloudSQL vs self hosted PostgresSQL в вашем конкретном кейсе.


Не вижу проблем рассмотреть это "в отрыве от основного процесса".

Поправлюсь: имел ввиду не self hosted, а self managed, конечно. Т.е. машина(ы) на линуксе с PostgresSQL в том же GCP.

А зачем? Мне не очень ясна мотивация — зачем тратить время, силы на строительсто (а главное поддержку и ремонт) чего-то, если уже есть готовый блок для использования.

Меня интересует анализировали ли стоимость решения одно vs другое и что получилось.


CloudSQL это классно, но далеко не всегда экономически целесообразно, а время на строительство, поддержку и т.п. зависит многих факторов, в т.ч. нагрузки на бд, прямоту рук девопса(ов), наличие девопсов в принципе и т.д.


Например, если база совсем не нагруженная и небольшая, то поднять небольшой instance с медленными дисками, которому в принципе не от чего падать, без high availability, настроить бэкапы на s3 и т.п. скорее всего будет дешевле использования CloudSQL.


Если DevOps в ладах с Terraform, Ansible и инфраструктурой как код в принципе, то развернуть и поддерживать такое не сложно и не затратно в человекочасах, но всё зависит от параметров проекта.


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


Так-то по каждому чиху можно rds поднимать, но в тегах к статье же finops.

У нас была похожая проблема, да и есть ещё собственно. Как вы разделяете ресурсы на команды/отделы, точнее говоря, как вы определяете, какая команда/отдел, что и сколько использовала?
У нас(в aws) есть три больших K8s кластера(production, staging, integration) разделённых на разные аккаунты и в них все запускают свои ресурсы или у вас как-то по другому происходит.
Кстати может кому-нибудь пригодится prometheues exporter, который показвает дневную цену в aws, разделённые по регионам, аккам и сервисам. Вот тут лежит
из моего опыта
naming conventions:
— префиксы для имён и идентификаторов проектов и ресурсов
— labels
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Местоположение
Россия
Сайт
opsguru.ru
Численность
31–50 человек
Дата регистрации

Блог на Хабре