Итак, нам необходимо развернуть систему управления базами данных (СУБД). Казалось бы, начинается все с установки непосредственно дистрибутива СУБД. Однако, если вы решили опираться на собственные силы, то сначала придется подготовить инфраструктуру: арендовать или разместить в ЦОДе оборудование, раскатать операционную систему, скоммутировать сеть. После развёртывания СУБД — настроить политики безопасности, резервное копирование, организовать мониторинг с алертами. С одной стороны, это разовое действие. С другой — если через месяц для нового проекта понадобится новая БД, то все придется делать заново. Немного помогают средства управления конфигурацией типа ansible или puppet, но даже при их использовании приходится делать много «тюнинга» — например, при изменении конфигурации СУБД или обновления её версии и состава компонент.
"Приходите в Yandex.Cloud - это дешевле и надежней"
И можно было не катать такую простыню.
Аналогичная реклама у амазона. Глава отдела разработки, где я работаю, начитавшись medium дот комов и прочих хайпов, написал классную презентацию, где сказал, что обслуживающая IT компания хочет 10к USD в год за сервер on-premise, а в амазон мы впишемся за 12к ну и прочие рекламные моменты, которые имеются и в этой статье. Через два года мы платим 60-70к в год.
Всё так, но, как говорится, есть нюанс :) В статье постарался и on-premise уделить внимание. Всё-таки ещё остались кейсы, когда он выгоднее.
Когда у вас появится полноценный хостинг?
Подключаться к базе с внутренней сети как-то сподручнее, чем с наружи, как минимум по скорости.
А что вы имеете ввиду под полноценным хостингом? У нас можно разворачивать "голые" ВМ, на которых можно хостить своё приложение. Также, как я описал в статье, можно прокинуть выделенный закрытый канал в свой ЦОД
В статье обещанных автором «подводных камней» для управляемой в облаке БД не обнаружил, зато «все русло» для управляемой своими силами БД густо устлано булыжниками. Да и все цифры почему то говорят в пользу облака. Наверное я был не внимателен или автор, имеющий непосредственное отношение к облачным хранилищам, позабыл рассказать о «подводных камнях» своего бизнеса. В результате получась осанна облачным хранилищам, что, некоторым образом, мешает воспринимать мнение автора в качестве объективного и беспристрастного.
Сожалею, что сложилось такое впечатление. Постарался показать минусы и того, и другого решения. Упомянул про главный, на мой взгляд, минус управляемых СУБД - недостаточные возможности по кастомизации и созданию сложных конфигов, ввиду чего управляемая СУБД проиграет в производительности на единицу ресурсов идеально настроенной опытным DBA СУБД в он-преме.
Я нисколько не скрываю, что симпатизирую именно управляемым СУБД. В конце статьи постарался объяснить свою точку зрения на этот счёт.