Как стать автором
Обновить

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

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

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

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


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


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


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

а «self hosted» — это где?

Поправлюсь: имел ввиду не 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
Зарегистрируйтесь на Хабре , чтобы оставить комментарий