Нажмите, чтобы узнать больше об авторе Matt Yonkovit.

Лесной пожар — это проявление могущественной силы природы. Он может все разрушить, а может дать начало новой жизни и способствовать положительному росту.

Облачная база данных как услуга (DataBase-as-a-Service, DBaaS) обладает аналогичной двойственностью.

«Сила» облака трансформировала нашу техническую инфраструктуру. Нигде это не проявляется так ярко, как в росте количества предложений DBaaS на рынке.

Мощные игроки рынка (такие, как Amazon Aurora, Azure SQL, Google Cloud SQL и MongoDB Atlas) быстро стали самым популярным для пользователей способом запуска базы данных в облаке. Но при неправильном развертывании или использовании перед пользователями могут возникать препятствия и проблемы. В своем последнем «Magic Quadrant» компания Gartner сделала стратегические предположения, что 75% всех БД будут развернуты или перемещены на облачные платформы, и только 5% облачных БД когда-либо рассматривались для возвращения в локальную среду. К 2023 году предпочтение к управлению данными в облаке приведет к сокращению количества поставщиков услуг, но в тоже время использование нескольких «облаков» усложнит управление данными и интеграцию.

У разработчиков всегда были прохладные отношения (в лучшем случае) с базами данных. Когда дело доходило до создания приложений, базы данных считались неизбежным злом. Трения между администраторами БД и разработчиками часто возникали из-за того, что каждая группа имела разные цели. Администратор БД должен учитывать долгосрочную устойчивость, безопасность, доступность и масштабируемость. А разработчик думает о фичах, графике выпуска и пользователях.

DBaaS обещает автоматизировать процессы, связанные с устойчивостью, безопасностью и доступностью. В теории, это позволяет разработчикам выбирать и управлять базами данных, позволяя им действовать быстро и пожинать плоды.

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

Например, у вас могут быть инструменты для резервного копирования и шифрования данных, но правильно ли они настроены и учтены ли типичные ошибки?

За последние несколько лет многие компании оказались в заголовках газет из-за того, что их данные оказались в руках хакеров. Однако, вопреки стереотипу о вундеркинде-хакере, строчащего код на маленьком ноутбуке, эти утечки обычно являются результатом того, что компании не следуют best practices или не понимают ограничений применяемой ими технологий. Один из наиболее распространенных источников утечек — это незащищенные S3 бакеты с бэкапами. То, что вы можете нажать кнопку резервного копирования не означает, что ваша резервная копия будет защищена или зашифрована должным образом. В некоторых случаях его даже можно будет восстановить. Поэтому по-прежнему имеется необходимость в специалистах, способных оценить и проконсультировать о потенциальных рисках.

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

Облачные провайдеры предоставляют вам базовые компоненты базы данных для создания безопасного и масштабируемого приложения. Это не означает, что ваше приложение безопасно и масштабируемо. Часто обнаруживается, что менталитет «установил и забыл» по отношению к базам данных (или, скорее, менталитет «это зона ответственности моего провайдера») приводит к большим затратам для пользователей в долгосрочной перспективе.

Недавний отчет от Andressen Horowitz подчеркнул потенциально более высокую стоимость облака. По моему опыту, реальные затраты на базу данных зачастую превышают ожидаемые. Эти повышенные затраты являются результатом того, что компании решают проблемы с БД за счет масштабирования и кредитной карты (переход к следующем инстансу, увеличения хранлища и т.п.). Но это неправильный подход, который может влететь в копеечку. За счет правильного проектирования, менеджмента и поддержки, затраты на БД могут сократиться на 50 процентов.

Помимо цены, есть несколько важных моментов, которые следует учитывать при использовании DBaaS. DBaaS хорошо подходит для разработчиков и пользователей, а ещё лучше для поставщиков БД и облачных вычислений (особенно в индустрии открытого исходного кода).

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

Вы, наверное, слышали термин «lock-in»(прим. Привязка к поставщику), используемый в опенсорс сообществе. Привязка к поставщику подразумевает ситуацию, когда вы начали использовать поставщика и «завязли» с ним, пока не пройдете долгий и затратный путь перестройки вашего приложения (как в песне «Hotel California»: «you can check in but you can never leave» — «вы можете зарегистрироваться, но не сможете уйти»). Oracle в 90-х обладал плохой репутацией из-за того, что привязывал к себе пользователей, а затем игрался с их лицензиями и затратами. Фактически, этот негативный опыт побудил людей начать изучать БД с открытым исходным кодом. При неосторожности, DBaaS может привести к самому высокому уровню «lock-in» за последние 20 лет.

Открытый исходный код — это один из самых мощных инструментов в арсенале пользователей против махинаций в индустрии высоких технологий. Особенно хорошо это проявляется с базами данных.

Например, если вы хотите запустить MySQL или PostgreSQL, вы обладаете перечнем опций. Вы можете выбрать, как вы их запускаете, где вы их запускаете и с каким стеком вы их запускаете. Вы можете развернуть MySQL в Azure Compute сегодня, а через неделю развернуть его на AWS EC2 и получить аналогичный опыт.

Такой уровень переносимости особенно полезен для тех приложений, которые разработаны как «облачные», при этом сами приложения получают большую переносимость за счет проектирования. Рост числа облачных приложений, работающих в контейнерах через Kubernetes, позволяет четко сепарировать приложение и поставщика инфраструктуры. Переносимость и возможность работать где угодно становятся ожидаемыми качествами от облачных приложений.

Однако некоторая ценность этой переносимости, обеспечиваемой как открытым исходным кодом, так и дизайном приложений, может быть нивелирована ростом DBaaS. Многие поставщики облачных услуг предлагают схожие, но не совсем одинаковые DBaaS, что снижает и ограничивает переносимость. Amazon Aurora имеет различия в функциях и проблемы совместимости с разными версиями MySQL. Они близки, но не на 100%… следовательно, Aurora утверждает, что она «совместима с открытым кодом». Каждый шаг вперед от поставщика MySQL или PostgreSQL DBaaS усложняет переход к другому поставщику или даже к вашей собственной БД. Это может стать проблемой, а может и не стать: всё зависит от уровня переносимости, необходимого вашему приложению. Если вам удобно работать с одним провайдером, то многие предложения DBaaS на рынке могут быть полезны.

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

Публичная лицензия на стороне сервера (SSPL) является наглядным примером. MongoDB создала эту лицензию, чтобы их конкуренты (в частности конкуренты Atlas) не создавали «as a service» продукты. И MongoDB не единственный пример. Компания Elastic недавно изменила своё лицензирование по той же причине. Эти действия ограничивает выбор пользователя. В конечном счете, вместо оперсорс ПО, пользователи получают отдельных поставщиков, предлагающих автоматизированные управляемые БД за плату.

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

Как уже упоминалось, это пример «легкой» торговли для будущей переносимости и контроля.

Компании/приложения могут сделать что-то подобное, создав процедуры архивирования или процессы для обработки чего-то подобного, но в настоящее время не существует такого же опенсорс эквивалента. И если вы решите прекратить платить за MongoDB Atlas, то вы потеряете доступ и вам придется переписывать приложения, чтобы нивелировать отсутствующую функциональность. Это похоже на другое проприетарное ПО (тот же Oracle 90-х годов).

Огромное преимущество опенсорса в том, что если ценность в услугах поставщика или подписки падает, то имеется возможность перенести бизнес в другое место. Если вы недовольны вашим поставщиком PostgreSQL, то у вас есть дюжина других вариантов на выбор.

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

Является ли DBaaS плохим продуктом?

Нет, вовсе нет. DBaaS обладает большими преимуществами как для пользователя, так и поставщика.

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

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

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

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

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩

DBaaS: друг или враг?