IT-инфраструктура для бизнеса и творчества
Разработка
Yandex.Cloud

Как бизнесу выбрать базу данных под свой проект? Сравниваем on-premise и управляемую БД

Компании, которые создают ИТ-проект с нуля или ищут альтернативное решение, рано или поздно отвечают себе на вопрос: выбрать базы данных on-premise (то есть самостоятельная установка и обслуживание на своей территории) или же управляемая БД в облаке?

Дмитрий Павлов, менеджер по развитию Data Platform в Yandex.Cloud, рассказывает подробно о каждом из вариантов с цифрами и подводными камнями.

Современный бизнес в практически любой индустрии немыслим без обработки больших объёмов данных. Повысить конверсию в интернет-магазине с помощью рекомендаций, отслеживать LTV и MAU/DAU/WAU в интернет-сервисах, обрабатывать транзакции и платежи в финтехе, предсказывать простой оборудования в промышленности — для этих и других задач необходимо хранить и обрабатывать реляционные структурированные данные. Вот уже 60 лет компаниям помогают в этом реляционные системы управления базами данных (СУБД).

В наше время встретившись с задачей, требующей обработки данных, у компании есть два пути:

  • Классический: разместить СУБД на собственном или арендованном оборудовании
  • Появившийся относительно недавно: использовать управляемую СУБД в облачном провайдере

На первый взгляд кажется, что всегда лучше держать свое, что называется, под боком. По моему опыту, практически все компании изначально рассматривают вариант on-premise (то есть аренду серверов в ЦОДе или виртуальных машин) и только потом изучают возможности облака.

У обоих подходов есть плюсы и минусы, и всё же в последнее время всё больше компаний выбирают облачные PaaS-сервисы. Так, по оценке Gartner, к 2022 году более 75% СУБД в мире будут расположены в облаках. Почему? В этой статье попробуем разобраться.

База данных: начало

Итак, нам необходимо развернуть систему управления базами данных (СУБД). Казалось бы, начинается все с установки непосредственно дистрибутива СУБД. Однако, если вы решили опираться на собственные силы, то сначала придется подготовить инфраструктуру: арендовать или разместить в ЦОДе оборудование, раскатать операционную систему, скоммутировать сеть. После развёртывания СУБД — настроить политики безопасности, резервное копирование, организовать мониторинг с алертами. С одной стороны, это разовое действие. С другой — если через месяц для нового проекта понадобится новая БД, то все придется делать заново. Немного помогают средства управления конфигурацией типа ansible или puppet, но даже при их использовании приходится делать много «тюнинга» — например, при изменении конфигурации СУБД или обновления её версии и состава компонент.

Управляемая база данных разворачивается быстрее — в этом случае начинаем сразу с настройки непосредственно сервиса, которая делается в веб-интерфейсе: достаточно выбрать тип СУБД, указать количество ресурсов (CPU, RAM, размер дисков), указать количество хостов, настроить расписание резервного копирования. В принципе, вся работа займет не более получаса. Важно, что это время постоянно для развёртывания любого типа СУБД — не придётся разбираться с новой технологией с нуля, когда придёт её время.

Так что, выбирая один из вариантов, необходимо, как минимум, представлять, как будет развиваться бизнес дальше — планируется ли расширение, запуск новых проектов, сколько будет времени на то, чтобы без спешки разобраться с новой технологией и развернуть её самостоятельно. Часто бизнес не может ждать. Поторопившись, можно словить неприятные последствия уже при продуктовой эксплуатации.

Конечно, возможен вариант, когда, например, оборудование уже есть, закупать его не требуется, только настроить. В этом случае в среднесрочной перспективе развернуть БД on-premise будет экономически обоснованно. Однако надо помнить, что эксплуатация оборудования тоже не бесплатна — его надо обслуживать.

Позовите администратора

После ввода СУБД в эксплуатацию наступает (и не заканчивается) этап поддержки — нужно непрерывно следить как за оборудованием (по мере износа заменять диски, отслеживать потери пакетов и сбои сети, вовремя заказывать и заменять вышедшие из строя компоненты), так и за СУБД (управлять нагрузкой, реагировать на падение производительности). Помнить надо и про безопасность — необходимо регулярно устанавливать обновления ОС и СУБД, чтобы исправлять ошибки и закрывать уязвимости.

У ОС и СУБД регулярно происходят так называемые мажорные обновления.Часто компании откладывают переезд на новую версию на последний момент или продолжают работать с неподдерживаемыми версиями. Потому что самостоятельное обновление и миграция — это долго и сложно: нужно учесть много нюансов, провести тестирование новой версии с приложением и решить возникающие проблемы.

В небольших компаниях, как правило, за БД следят администраторы общей специализации. Но они обслуживают и другую инфраструктуру, с БД работают не каждый день и поэтому профильных компетенций может быть недостаточно. Как следствие — администраторы не всегда выбирают оптимальные настройки и устраняют проблемы намного дольше профессионалов. В крупных компаниях есть администраторы, которые занимаются только БД. Это опытные специалисты, и у них достаточно знаний и умений, чтобы решать проблемы в заданные сроки.

В управляемом сервисе поддержкой занимается облачный провайдер, а клиенту нужно только управлять пользователями. То есть оборудование, ОС и СУБД под присмотром: обновления устанавливаются автоматически, системы мониторинга, резервное копирование и сетевые настройки контролируются самим сервисом управляемой СУБД. В управляемой облачной СУБД намного легче мигрировать на новые мажорные версии — достаточно по клику создать копию хоста БД с новой версией, проверить, что все работает как надо, и просто перевести нагрузку на новый хост. Откатиться можно в любой момент.

Также нельзя забывать и про интеграции с СУБД — ни одна система не существует в вакууме. Конкретно СУБД чаще всего интегрируется с BI-системами, с ПО загрузки и трансформации данных (ETL), с шинами данных (Kafka, Rabbit), с кэшами (Redis). В случае размещения своими силами администратору придётся разрабатывать механику интеграций самостоятельно. В случае использования управляемой СУБД большинство интеграций уже имплементированы, их можно использовать без написания кода.

Таким образом, при подсчете совокупной стоимости владения (total cost of ownership, TCO) СУБД следует учитывать не только сами ресурсы, но и сопутствующие факторы.

Факторы, играющие в пользу on-premise размещения:

  • Наличие большого пула ресурсов (своих серверов и ВМ) в капитальных расходах, за которые уже уплачены средства
  • Наличие опытных узкоспециализированных администраторов по каждой из СУБД в нужном количестве
  • Нетребовательность бизнеса к скорости запуска новых проектов (time-to-market) — если бизнес может подождать несколько месяцев, как это было лет десять назад, часто можно обойтись и своими силами

Факторы, играющие в пользу облачных управляемых СУБД:

  • Требования бизнеса к скорости развёртывания новых проектов — «надо запуститься сейчас, потом будет уже поздно, так как рынок будет упущен»
  • Отсутствие глубокой экспертизы в конкретных технологиях хранения данных
  • Необходимость интегрировать СУБД с другими системами компании

Есть два частых вопроса к облачным СУБД, с которыми связаны опасения и заблуждения: безопасность хранения персональных данных в облаке и ширина сетевого канала, соединяющего облачную СУБД с другими системами компании. Так вот:

  • Большинство современных облачных провайдеров имеют развитые средства защиты данных и все необходимые сертификаты для хранения любых данных — персональных, финансовых, и т.д
  • В большинстве случаев трафик между облачной СУБД и ЦОДом компании идёт не через интернет, а через специальный выделенный канал до ЦОДа — интерконнект. Такой канал имеет пропускную способность около 20 Гбит/с и минимальную latency. Фактически доступ к облачной СУБД не отличается от доступа к СУБД, развёрнутой в своём ЦОДе.

Один упал, остальные работают

СУБД должна сохранять работоспособность даже в случае отказа одного или нескольких элементов. Поэтому отказоустойчивость — одна из важнейших характеристик, которую нужно обеспечить.

Отказоустойчивость СУБД достигается за счет создания кластера: если из строя выйдет один из хостов, остальные продолжат работу. В идеале хосты лучше расположить в разных ЦОДах, чтобы обезопасить свой проект от сбоев целого дата-центра.

Такую отказоустойчивую систему можно создать собственными силами, но для этого потребуется много ресурсов и навыки экспертов. Это непростая задача: нужно наладить связь между хостами, настроить репликацию данных и автоматический перенос нагрузки с одного узла на другой. Размещение хостов в разных дата-центрах требует дополнительных усилий: нужно разбираться, где физически находятся серверы, и арендовать их в разных зонах доступности.

Вот схема построения отказоустойчивого кластера:

Управляемые БД — это отказоустойчивость и легкое изменение топологии. Для любой из кластерных баз данных можно создать реплики в трех зонах доступности.

Например, вы разворачиваете стенд для нового проекта, который еще разрабатывается. Поначалу проекту не нужны реплики, так как к нему не предъявляются требования продуктивных систем. Но когда проект готов к запуску в production, вы можете из этой БД сразу же сделать боевую отказоустойчивую систему: добавляете реплики к установке и получаете отказоустойчивую БД без переноса данных и миграции.

Ничего не теряем

Резервное копирование позволяет восстановить данные в случае сбоя. Но чтобы оно правильно работало, нужно выбрать тип — когда лучше сделать полную копию, а когда инкремент, определиться с расписанием, найти место для хранения и организовать процесс так, чтобы копию можно было быстро восстановить.

В управляемой БД все задачи, кроме расписания, решает облачный провайдер. Восстановить копию можно самостоятельно несколькими кликами мыши — не придется писать в поддержку и ждать ответа.

Кроме привычных всем бекапов, в некоторых СУБД есть механизм point-in-time recovery (PITR). Эта полезная функция позволяет восстановить данные на любой момент, а не только на момент создания копии. Например, бекап создается в 00:00. Утром в БД появляются новые данные, а в обед junior-разработчик случайно удаляет одну таблицу. Если восстановить предыдущую копию — то потеряются утренние данные. Механизм PITR позволяет указать точное время, на которое нужно восстановить данные: он сам восстановит последнюю копию и применит все транзакции, которые прошли после ее создания.

PITR работает и при локальной установке БД. Но придется сначала настроить этот механизм, а потом просить системного администратора восстанавливать данные. В управляемой БД PITR уже настроен, а воспользоваться им можно без посторонней помощи.

У каждого своя роль

В управляемой БД вы получаете доступ как пользователь — создаете схемы и таблицы, работаете с данными, анализируете производительность запросов. Но у вас нет root-доступа, то есть вы не можете менять системные настройки и управлять виртуальной машиной, на которой запущена СУБД. Этот вариант подходит тем, кому нужна готовая и стабильная база данных, а не конструктор, который легко сломать. Да, минус гибкость, так как нельзя управлять абсолютно всеми настройками. С другой стороны, даже самая глубокая оптимизация настроек СУБД под конкретный кейс обычно дает лишь несколько процентов производительности относительно управляемой СУБД.

Есть и другой вариант: пользователи получают полный доступ к СУБД и ВМ, на которой она работает. Это нельзя назвать полностью управляемым сервисом, это скорее ВМ с готовым шаблоном для быстрого развертывания. Такой вариант упрощает установку и настройку (то есть вычитаем из затрат первый этап). Но раз вы имеете доступ ко всем внутренним настройкам и функциям — провайдеру сложнее гарантировать стабильную работу. Если из-за вмешательства система сломается, разбираться придется самостоятельно.

Соответственно, в БД on-premise у вас (или администраторов) в руках все карты — все системы управления.

И о доступности

Еще одна особенность управляемых БД — соглашение об уровне сервиса (SLA). Оно гарантирует, что БД будет доступна определенное количество времени. В противном случае провайдер компенсирует стоимость сервиса. Но подобные условия предоставляются только для кластера.

При аренде БД на ВМ провайдер также гарантирует доступность по SLA. Но, как правило, в этом случае она ниже, чем для управляемой БД. Например, в Yandex.Cloud SLA для ВМ — 99,95%. Когда ВМ простаивает, это означает, что БД недоступна на чтение и на запись. А в управляемой БД эти операции разделены, и если она недоступна на запись, то вполне вероятно, что доступна хотя бы на чтение.

На что уходит больше всего рабочего времени

Все, что связано с управлением БД, можно делать самостоятельно: устанавливать и настраивать, поддерживать и обновлять, настраивать резервное копирование и отказоустойчивость. Но, как уже было сказано выше, это требует большого количества времени и ресурсов, так как в большинстве своем это непрофильные задачи.

Компания MongoDB описала все действия, на которые расходуется время в различных моделях развертывания БД — на своем оборудовании, на облачной ВМ и полностью управляемой БД. На схеме видно, что в управляемых БД практически все время уходит на разработку и инновации, то есть на решение конкретных задач бизнеса, а не на настройку и обслуживание БД.

Стоимость

Мы рассчитали стоимость владения и управления тремя видами ресурсов — on-premise, ВМ на базе Yandex Compute Cloud и сервисом по управлению базами данных. Мы выбрали эквивалентное по мощности оборудование и сравнили, сколько это стоит в каждом из вариантов.

Расчеты приведем на горизонте трех лет, то есть амортизацию оборудования в on-premise-решении посчитаем за три года.

Это упрощенный расчет — мы не учли несколько моментов. Например, что в on-premise решении оборудование можно продать после использования, а отсутствие капитальных затрат в управляемой БД можно инвестировать в другие направления бизнеса.

Вот сравнение стоимости управления и владения различными вариантами БД:

Давайте рассмотрим расчеты более подробно.

В случае on-premise придется самостоятельно покупать оборудование и следить за ним, поддерживать бесперебойную работу и периодически менять, когда оно устареет или сломается. Если проект развивается, то со временем мощности станет недостаточно и потребуется новое оборудование. Если же сразу взять мощность с запасом — оборудование будет простаивать.Пример: сервер HP с 12 ядрами стоимостью ≈ 800 000 ₽. С учетом амортизации за три года получается ≈ 22 000 ₽ в месяц.

Согласно исследованию некоммерческой организации NRDC, утилизация on-premise оборудования от трех до четырех раз ниже, чем облачного. С учетом данной поправки стоимость владения оборудованием составит как минимум ≈ 22 000 × 3 ≈ 66 000 ₽ в месяц.

Также необходимо будет искать сотрудников, платить зарплату и социальные взносы. При этом потребуется как минимум два специалиста, чтобы они могли подменять друг друга во время отпуска и болезни. Скорее всего, кроме БД, эти сотрудники будут заниматься и другими задачами, поэтому предположим, что на администрирование БД они тратят только 50% времени.Зарплата специалиста ≈ 100 000 ₽, социальные взносы — 30 000 ₽. Потребуется два специалиста, каждый из которых администрирует БД 50% времени. В итоге получаем ≈ 130 000 ₽ в месяц.Итого ≈ 196 000 ₽ в месяц.

При выборе ВМ на базе Compute Cloud не нужно заниматься оборудованием. Так, например, стоимость развертывания ВМ в Yandex.Cloud ≈ 27 500 ₽ в месяц.

Но все еще нужно искать сотрудников, платить зарплату и социальные взносы. Затраты по этой статье будут такими же, как и при on-premise ≈ 130 000 ₽ в месяц.

Итого ≈ 157 500 ₽ в месяц.

Меньше всего ресурсов потребует управляемая БД, так как уходят затраты на оборудование и администраторов.

Пример: управляемая БД (24 vCPU, 96 RAM, 240 ГБ SSD) стоит ≈ 42 000 ₽ в месяц.

Конечно, помимо выбора между on-premise и облачной управляемой СУБД предстоит определиться и с самой технологией СУБД. Здесь необходимо учитывать сразу несколько параметров, в том числе тип данных, характер нагрузки или необходимость в горизонтальном масштабировании. Недавно мы с командой подготовили специальный тест, который помогает учесть все параметры.

Вместо вывода

Безусловно, оба варианта размещения СУБД имеют свои плюсы и минусы.

On-premise даёт полный контроль над СУБД, возможность выжать несколько дополнительных процентов производительности за счёт более тонкой настройки «под себя», а также возможность утилизировать уже имеющееся оборудование. Также on-premise размещение часто выбирают высокочастотные финансовые сервисы: например, базы размещают в ЦОДах в центре города, чтобы быть ближе к биржам — источникам котировок, таким образом снизив латентность. Однако надо быть готовым к тому, что такое размещение будет очень дорогим.

Управляемые СУБД выбирают по двум причинам: скорость развёртывания и расширения, и совокупная стоимость, причем, как мне кажется, именно в таком порядке приоритетов. Возможность поддержать бизнес-инициативу, помочь бизнесу стартовать и занять рынок здесь и сейчас, а не через три месяца, быть быстрее конкурентов — вот почему всё больше компаний выбирают управляемые СУБД.

На мой взгляд, именно скорость изменений бизнеса в будущем будет основным преимуществом в высококонкурентных отраслях (онлайн-сервисы, ритейл, финансы, аналитика), и управляемые СУБД ещё сыграют здесь свою немалую роль.

Подписывайтесь на блог Yandex.Cloud, чтобы узнавать еще больше новостей и историй об IT и бизнесе.

Другие истории, которые активно читают наши подписчики:

(function () { let cdnUrl = `https://specialsf378ef5-a.akamaihd.net/SelectelBranding/images/` let previousArticleNumber = null let currentArticleNumber = 0 let platform = 'Desktop' let articles = [ { name: 'camera', url: `${cdnUrl}CameraCat`, text: 'умную камеру для\u00A0наблюдения за\u00A0котиками', link: 'https://vc.ru/selectel/306690', num: 3 }, { name: 'chill', url: `${cdnUrl}ChillCat`, text: 'трекер, который подскажет, когда пора отдохнуть', link: 'https://vc.ru/promo/288561-eye-tracker', num: 1 }, { name: 'cloud', url: `${cdnUrl}CloudCat`, text: 'котика: даёшь ему «пять», а\u00A0он делает бэкап в облако', link: 'https://vc.ru/dev/294799-maneki-neko', num: 2 } ] let buttonCycle = document.querySelector('.button--cycle') let buttonChoose = document.querySelector('.button--choose') let buttonMobile = document.querySelector('.button--mobile') let textField = document.querySelector('.selectel-footer-subtitle') let imageAgent = document.querySelector('.image--agent') let banner = document.querySelector('.selectel-footer') buttonCycle.addEventListener('click', cycleClick) buttonChoose.addEventListener('click', () => sendEvent(`Promo ${articles[currentArticleNumber].num} Left`, 'Click')) buttonMobile.addEventListener('click', () => sendEvent(`Promo ${articles[currentArticleNumber].num} Left`, 'Click')) let media = window.matchMedia("(max-width: 570px)") media.addEventListener('change', matchMedia) function matchMedia() { if (media.matches) { platform = 'Mobile' } else { platform = 'Desktop' } update() } matchMedia() function cycleClick(event) { sendEvent(`Promo ${articles[currentArticleNumber].num} Right`, 'Click') if (event) { event.preventDefault() event.stopPropagation() } window.open('https://vc.ru/tag/selectelDIY', '_blank') //cycle(event) } function cycle(event) { // incrementArticleNumber() textField.innerHTML = generatedText() imageAgent.src = articles[currentArticleNumber].url + platform + '.svg?3' imageAgent.setAttribute("class", "") imageAgent.classList.add('image--agent', articles[currentArticleNumber].name) banner.href = articles[currentArticleNumber].link } function update() { banner.href = articles[currentArticleNumber].link imageAgent.src = articles[currentArticleNumber].url + platform + '.svg' textField.innerHTML = generatedText() } function incrementArticleNumber() { previousArticleNumber = currentArticleNumber if (currentArticleNumber >= articles.length - 1) { currentArticleNumber = 0 } else { currentArticleNumber++ } } const sendEvent = (label, action = 'Click') => { const value = `SelectelDIY — loc: Footer — ${label} — ${action}`; if (window.dataLayer !== undefined) { window.dataLayer.push({ event: 'data_event', data_description: value, }); } }; function generatedText() { let defaultText if (platform === 'Desktop') { defaultText = `Мы тут собрали %text%. Хотите научим?` } else { defaultText = `Мы тут собрали %text%.` } return defaultText.replace('%text%', articles[currentArticleNumber].text) } function getRandom(min, max) { min = Math.ceil(min) max = Math.floor(max) return Math.floor(Math.random() * (max - min + 1)) + min } (function create() { currentArticleNumber = getRandom(0, articles.length - 1) cycle() let page = document.querySelector('.page--entry') if (page) { function insertAfter() { let parents = page.querySelectorAll('[data-id="7"]') let referenceNode = parents[0] referenceNode.parentNode.insertBefore(banner, referenceNode.nextSibling); loaded() } setTimeout(() => insertAfter(), 0) } }()) function loaded() { banner.classList.add('loaded') } loadImages([ `${cdnUrl}CameraCatDesktop.svg`, `${cdnUrl}ChillCatDesktop.svg`, `${cdnUrl}CloudCatDesktop.svg`, `${cdnUrl}CameraCatMobile.svg`, `${cdnUrl}ChillCatMobile.svg`, `${cdnUrl}CloudCatMobile.svg?3`, ]) function loadImages(urls) { return Promise.all(urls.map(function (url) { return new Promise(function (resolve) { var img = document.createElement('img'); img.onload = resolve; img.onerror = resolve; img.src = url; }); })); } }())
0
24 комментария
Популярные
По порядку
Написать комментарий...

"Приходите в Yandex.Cloud - это дешевле и надежней"
И можно было не катать такую простыню.

0

Аналогичная реклама у амазона. Глава отдела разработки, где я работаю, начитавшись medium дот комов и прочих хайпов, написал классную презентацию, где сказал, что обслуживающая IT компания хочет 10к USD в год за сервер on-premise, а в амазон мы впишемся за 12к ну и прочие рекламные моменты, которые имеются и в этой статье. Через два года мы платим 60-70к в год.

2

Если не секрет, где он ошибся, где оказались скрыты дополнительные косты?

1

1. Объём данных, которые гуляет между производством и облаком не был просчитан правильно (я сделал on premise архитектуру).
2. Товарищ этот из веб дизайна пришёл и задался тупой идеей "low code/no code". Вначале он решил, что может on premise перенести без проблем, но оказалось (для него), что там в этих ETL есть ещё и куча статистики, вот и пришли всякие lamda, ecs и прочее и к тому же хотелось low code/no code.
3. Далее когда cost of failure стал повышаться, естественно были готовы выделять больше денег, он заодно и DevOps повесил параллельно с Athena.
4. Он помешан амазоном, так что когда мы сенсоры начали пихать на производстве, он их хотел покупать сразу, чтобы они на амазон могли закидывать, опять-таки зачем писать код, если он написан — вот ещё и оттуда что-то прилетело.

Суммарно:
Те кто пишет прайсы для облачных сервисов всё делают правильно: с одной стороны вроде платишь мизер за каждую песчинку на пути на море, но с другой стороны не всегда дано просчитать сколько раз наступишь на песок. Облачные сервисы действительно написаны очень хорошо, что даёт возможность даже полному junior сделать хоть что-то адекватное и оно может затянуть. И, увы, всё больше низкокачественных программистов появляется, которые готовы схавать красивую рекламу.

В моём представлении, на облако я бы только кидал S3, DB (причём только то, что может быть и без облака), а вычисления распределять между стационарными компами внутри офиса. При таком раскладе миграция вообще безболезненно проходит. 

1

Всё так, но, как говорится, есть нюанс :) В статье постарался и on-premise уделить внимание. Всё-таки ещё остались кейсы, когда он выгоднее.

2

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

0

А что вы имеете ввиду под полноценным хостингом? У нас можно разворачивать "голые" ВМ, на которых можно хостить своё приложение. Также, как я описал в статье, можно прокинуть выделенный закрытый канал в свой ЦОД

2

Где об этом подробнее почитать, натыкался только на yandex cloud functions где PHP Может работать.

0

Вот тут можно посмотреть классические ВМ: https://cloud.yandex.ru/services/compute

А вот тут - управляемые базы данных: https://cloud.yandex.ru/services#data-platform

2

Правильно ли я понимаю, что загрузив один раз приложение, я смогу менять доступные ресурсы (cpu, память) как в этом калькуляторе: https://cloud.yandex.ru/prices без всяких проблем, на лету?
Есть там какой-то аналог ispmanager-а ?
Кто администрирует сервер?

0

Если мы говорим про "голую" ВМ, то ресурсы можно менять (CPU, RAM, ROM), однако для этого ВМ придётся перезапустить.

Если говорить про управляемые СУБД, то там всё происходит на лету благодаря Rolling Upgrades: https://habr.com/ru/company/yandex/blog/433814/

1

Вот поэтому, и ссыкотно пользоваться сервисами яндекса, тех поддержка может неделями отвечать, даже вы тут на vc.ru не можете на простые вопросы ответить.

1

Благодарю, с перезапуском устраивает, что по администрированию скажете, все как с обычным VPS надо делать, или у вы там за администрирование отвечаете? 
Аналог ispmanager-а есть или только через консоль все?

0

Денис, давно не пользовался услугами хостинг-провайдера, не могу сейчас полноценно сравнить с "обычным" VPS, но очень условно можно IaaS Yandex Cloud описать как "голый, но очень и очень продвинутый VPS". Другими словами Облако дает вам в аренду продвинутый катастрофоустойчивый дата центр, а вы уже самостоятельно разворачиваете в нем необходимую вам инфраструктуру и занимаетесь управлением ею. 
При этом, наряду с платформой облачной инфраструкты мы также активно развиваем платформу управляемых баз данных, о которой пишет Дмитрий, но пользоваться в своем веб-приложении ими или разворачивать отдельные сервера под СУБД в своем арендованном облаке решает клиент. 
Запрос на системы управления веб-приложениями/панелями веб-хостинга понятен, мы стремимся решить его через размещение таких продуктов в Маркетплейсе https://cloud.yandex.ru/marketplace/. Ряд продуктов этой категории вы там уже сможете найти, но тут очень много нюансов лицензирования, короче, работаем. Но опять же продукты из Маркетплейса клиент сам разворачивает в своем арендованном облаке и сам занимается их настройкой, т.е. это не managed-решения.
Если отвечать, кому подойдет такой "хостинг", то в первую очередь е-кому, который перерос классические хостинговые услуги по требованиям к нагрузке, отказоустойчивости и масштабированию, обладает средствами для администрирования своей веб-витрины, но не готов нести серьезные единовременные  затраты на покупку железа и арендовать физические стойки в ДЦ.

PS: Как же лампово, что вы не меняете аватар еще со времен заруб в комментах на Роеме )))
Всегда рад вас видеть в обсуждениях.

1

Благодарю за подробный ответ. Вот об этом я в первом комменте и писал, хочется готовый сервис, чтобы не заморачиваться с администрированием и настройкой сервера, чтобы вы предоставляли полноценный хостинг со своим администрированием. 
PS Да были времена дискуссий на Роем, сейчас там полное согласие, гробовая тишина, Синодов с Ашмановым все зачистили в ноль, включая меня.

PS2 Как запущу новый проект - MasterPult.ru, так аватар придется поменять))))
Собственно в связи с ним и интересуюсь вашим продуктом, не хочется заморачиваться с выделенными серверами и переезжать с сервера на сервер по мере необходимости (так как не знаю какая будет потребность у этого SaaS сервиса), а так увеличил cpu и память и вперед, но необходимость администрирования отталкивает, сам не хочу этим заниматься, людей со стороны пускать тоже. Хочется под ключ как на reg.ru или мастерхост, чтобы заниматься только своим php приложением. ред.

0

Ну в Облаке просто в другом фишка - масштабирование, отказоустойчивость, снятие пиков нагрузки, time-to-market по выгодной цене и без тяжелых долговременных инвестиций в железо. Запулили акцию, набежал траф, вы добавили машинок и всех обслужили, ничего не упало. Трафик ушел, убрали машинки. И не надо думать есть ли свободное место в стойке и как туда привезти сервак. 
Но работать с этим придется самому или звать партнеров )  

1

Так именно этих фишек и хочется, потому и смотрю в эту сторону, но еще и услугу администрирования, как это делает рег.ру или мастерхост с простыми дедиками.

0

В статье обещанных автором «подводных камней» для управляемой в облаке БД не обнаружил, зато «все русло» для управляемой своими силами БД густо устлано булыжниками. Да и все цифры почему то говорят в пользу облака. Наверное я был не внимателен или автор, имеющий непосредственное отношение к облачным хранилищам, позабыл рассказать о «подводных камнях» своего бизнеса. В результате получась осанна облачным хранилищам, что, некоторым образом, мешает воспринимать мнение автора в качестве объективного и беспристрастного.

0

Сожалею, что сложилось такое впечатление. Постарался показать минусы и того, и другого решения. Упомянул про главный, на мой взгляд, минус управляемых СУБД - недостаточные возможности по кастомизации и созданию сложных конфигов, ввиду чего управляемая СУБД проиграет в производительности на единицу ресурсов идеально настроенной опытным DBA СУБД в он-преме.

Я нисколько не скрываю, что симпатизирую именно управляемым СУБД. В конце статьи постарался объяснить свою точку зрения на этот счёт.

1

Почему в статье так лихо синонимизируются понятия «база данных» и «субд»? Что за некорректный заголовок? Базу данных не выбирают, выбирают субд.

–1
Террористический месяц

Комментарий удален по просьбе пользователя

1

Нет, конечно.

0

Вы правы, в некоторых местах (например, в названии) используем термин БД вместо СУБД. Однако иначе заголовок был бы слишком длинным для статьи.

В статье речь идёт именно про СУБД.

0

Такое некорректное использование терминов, которые являются принципиальными, понижают доверие к автору на порядок. Я глазам не поверила, что от имени яндекса такое пишут. Речь о репутации. Там и в тексте такая же дичь есть. Это тетя Маша из бухгалтерии может путать бд с субд, но не в профильной же статье.

–3
Читать все 24 комментария
Маркировка молочной продукции

В 2021 году в России начала действовать маркировка молочной продукции. У нее есть особенности: в процессе участвуют типографии и предприятия общепита. Разбираемся, что нужно знать о работе по новым правилам и кого они затронут.

Яндекс Маркет не возвращает деньги за потерянный товар

Яндекс маркет уже месяц не может принять решение о возврате денег за товар, который Почта России потеряла в процессе возврата на склад яндекса.

Питч-дейтинг выпуск третий: комбайнеры

Рассказываем историю продакта «Яндекса», который решил помочь фермерам, а также составляем свой словарик стартапера.

Запустить игру и не прогореть: зачем нужны маркетинговые исследования в гейминге и как их проводить

Маркетинговое исследование помогает экономить сотни тысяч долларов и выпускать продукты, которые приносят миллионы.

AWS анонсировала платформу Amplify Studio для разработки приложений с минимальным написанием кода Статьи редакции

Платформа подключена к онлайн-сервису Figma.

Наводим порядок и изучаем rocket sience. Доклады Go meetup

На прошедшем Go meetup спикеры из Evrone, «Ситимобил» и «Авито» учили правильной организации кода микросервиса, рассказывали, как вырастить MVP в полноценную масштабируемую архитектуру, и разобраться с мусором и алгоритмами управления памятью. Все доклады записаны в студии и доступны для просмотра.

Как я всё бросил и стал Тиктокером

От учёбы в топовом вузе и сеньорской позиции в IT до кривляния на камеру и заработка на рекламе.

Удаленное трудоустройство - плюсы и минусы. Юридический взгляд
«Альфа-банк» доставляет карту, самостоятельно вскрывая конверт, в котором видно все данные

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

Такие дела: жалоба на «Яндекс.Такси» за отказ перевозить собаку-поводыря

Девушка с нарушением зрения подала жалобу в прокуратуру из-за того, что водители популярного сервиса такси «Яндекс Go» слишком часто отказываются возить ее с собакой-поводырем.

null