Если вы попросите своего знакомого назвать самые инновационные компании, то он наверняка упомянет Apple и вряд ли включит в свой список Porsche. Хотя этот производитель автомобилей взял на вооружение ту же стратегию, что и Apple: инвестирует прибыль от традиционных продуктов в инновации и трансформирует бизнес.

Apple направил доходы от продаж своих популярных компьютеров Mac в разработку новых продуктов и в результате на рынок вышел iPhone, который сейчас приносит компании больше всего прибыли. Porsche, у которого многие годы основной бизнес был связан с дорогими спортивными автомобилями, решил инвестировать свои доходы в создание собственных кроссоверов когда они стали входить в моду. Выпущенный в 2002 году Cayenne вместе с более компактным Macan стали бестселлерами компании, и в 2015 году Porsche продала кроссоверов в два раза больше, чем спортивных машин знаменитой серии 911. Как отмечают Мадхаван Рамануям и Джордж Так, Porsche использовала выручку от традиционных продуктов для продуманных инноваций и за счет этого из производителя, специализирующегося на спортивных автомобилях, компания трансформировалась в поставщика мощных роскошных кроссоверов.

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

Нужные процессы и неоправданные расходы


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

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

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

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

Решение: гибкое лицензирование


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

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

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

Гибкая модель лицензирования очень выгодна для многих компаний, в том числе для:

  • Предприятий, чей бизнес связан с интенсивной обработкой данных, особенно из сектора финансовых сервисов, розничной торговли, здравоохранения, платежных систем и промышленного производства;
  • Предприятий, которые хотят мигрировать свою реляционную СУБД (РСУБД) в облако и отказаться от текущей инфраструктуры, требующей больших затрат;
  • Предприятий, которые хотят уменьшить совокупные расходы на обеспечение работы бизнес-критичных приложений, внедрить эластичное расширение емкости и гарантировать целостность кода и алгоритмов этих приложений;
  • Предприятий, которые хотят существенно сэкономить на CapEx и OpEx и значительно уменьшить совокупную стоимость владения (TCO);
  • Предприятия с приложениями для хранения данных и хранилища данных
  • Предприятия, требующие высокодоступных кластерных приложений
  • Предприятия, требующие шифрования базы данных с высокой степенью защиты
  • Предприятий, которым нужно использовать надежное шифрование баз данных
  • Предприятий, которым требуется база данных с поддержкой функции резервирования active standby или passive standby

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

Опции оплаты DBMS – резюме для руководителя


У разных СУБД схема лицензирования может сильно отличаться. При анализе опций следует учитывать три рекомендации:

1) Внимательно изучите модель лицензирования и потенциальные скрытые расходы (например, необходимость приобрести дополнительное оборудование для обслуживания рабочих нагрузок базы данных). Хотя некоторые решения рекламируются как открытые, но на самом деле у них есть серьезные ограничения при лицензировании, которые невыгодны для покупателя.

2) Open source – это не то решение, которое подойдет для любой компании. Решения такого типа могут хорошо работать на вертикальных рынках, но для обычных компаний они могут стать источником новых проблем. Для любой базы данных важно учитывать, какая для нее предоставляется поддержка, поскольку обслуживание баз данных требует значительных расходов рабочего времени и ресурсов. Кроме того, у баз данных open-source нет четких планов развития, они слабо структурированы, что может создать проблемы на определенном уровне.

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

Новая модель


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

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

Комментарии (8)


  1. Gasaraki
    30.01.2018 20:01

    2) Open source – это не то решение, которое подойдет для любой компании.


    В 99% случаев как раз для любой компании. Вспоминая стоимость коммерческих гигантов (оракл например), вам хватит денег на DBA который в любом случае нужен если проект крупный и даже на внезапную правку базы под ваши нужды если припрет. А сэкономленные деньги можно вложить в бизнес или в обвязку под базу — бэкапы и т.п.

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

    Современные open source решения баз данных уже давно созрели, надежны и используются в крупных коммерческих проектах (тот же яндекс сьехал с оракла с большим счастьем).
    А интеграторы выкатывают красивые графики стоимости владения для финансистов, которые на самом деле является рисованием вилами на воде.

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

    И маркетологи того же оракла и майкрософта понимают момент с их не особой нужностью и рисками распространения и поэтому не закручивают гайки на установку баз данных. Если закрутят — народ живо ломанется на opensource, а так многие пользуются в обход лицензий, привыкают, делают обвязку и потом возможно когда-нибудь уже ее купят.


  1. svilgelm
    30.01.2018 20:04

    PostgreSQL, MySQL, MariaDB, MongoDB, SQLite… На рынке очень много вполне готовых и зрелых бесплатных решений, о каких вообще лицензиях на СУБД может идти речь? Могу понять покупку тех. поддержки, но лицензии ни как не вписываются в мое мировозрение.


    1. alexmay
      30.01.2018 20:39

      СУБД не только движок хранения данных. В коммерческих иногда присутствует еще и достаточно мощная IDE/формошлепалка для этой БД (но не всегда)


      1. svilgelm
        30.01.2018 23:21

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


    1. DSolodukhin
      30.01.2018 22:07

      При всей моей любви и уважению к PostgreSQL и Open Source в целом, PostgreSQL уступает Oracle DB по ряду параметров. Если ваш случай — это хранение пары сотен тысяч строк преимущественно плоских данных, то конечно вы особой разницы не увидите.
      У Oracle DB гораздо лучше ситуация с кластеризацией и горизонтальным масштабированием вообще. Если вы используете оракловый стек ПО, то интеграция всего этого добра с базой легче, плюс вы можете получить дополнительные плюшки.


      1. maxzh83
        30.01.2018 22:58

        Если бы при своей цене, Oracle была бы еще и хуже… Хотя, для простых сценариев использование Postgres зачастую оказывается приятнее. Просто потому, что создавалась она гораздо позже и не тащит с собой «исторически сложившееся» наследие из прошлого века.


      1. svilgelm
        30.01.2018 23:44

        Вполне возможно, что в каких-то особенных случаях тот же Oracle будет превосходить PostgreSQL, но и Postgres не стоит на месте. А на счет плоских данных, можно же выбрать не только Postgres, хотя и в нем существует поддержка JSON/GIS данных на очень приличном уровне. Да и не одним Posgtres'ом живет мир Open Source.
        Из моего опыта, на Oracle пишут полностью бизнес логику приложений, хотя я и приверженец того, чтобы база данных была в основном хранилищем данных, а обрабатывать их стоит на чем-нибудь более специализированным, но вполне понимаю и такой путь. Но как-то не готов платить за лицензию Oracle.
        У меня уже был печальный опыт поддержки продукта, основанного на Orcale и с истекшей лицензией на продукт. Поверьте, это очень неприятно, когда нужно исправить продукт под изменившееся законодательство или добавить небольшую фичу, а ты не можешь вообще ничего изменить ни в структуре данных, ни в самом продукте. Приходилось писать костыли, которые могли работать с продуктом только в режиме чтения данных, а если нужно было что-то сохранить, то для этого использовалась уже сторонняя база. Очень часто получалось так, что моя программа что-то вычисляла, о операторы уже вручную вносили необходимы правки через интерфейс продукта, либо мое приложение генерировало готовый отчет.
        Второй случай работы с Oracle, когда приходилось часами ожидать отчета от приложения, в котором бизнес логика была написана полностью внутри Oracle, так вот, приложение, написанное на Delphi, считало этот же отчет за минуты, считывая тоже самы данные из Oracle. Я конечно понимаю, что тут дело скорей всего было не в Oracle, а в гениальном умении программиста, криво написавшего процедуры, но осадок все-равно остался.
        Так же был и опыт оптимизации кривых процедур написанных для Postgres, но там уже обошелся просто переписываниям самих процедур и все осталось в рамках Postgres.


  1. a-l-e-x
    31.01.2018 00:40

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

    Если речь идёт о небольших объёмах данных — таблицы в сотни тысяч или несколько миллионов записей (и их, грубо говоря, не очень много, хотя на самом деле критерий значительно сложнее), то я бы стал смотреть в сторону MySQL или Postgres, причем не отдельно на сервере или кластере, а в облаке — AWS, GCP… — как управляемая услуга.

    Если данных действительно много — Redshift AWS, BigQuery GCP.

    Если нужно для операционной работы, а не отчётов — Spanner. Но тут нужно иметь много денег.

    Еще есть много всяких разных GCP — BigTable, DataStore — но это несколько другая история…

    И как бы не остаётся широкой ниши для Oracle. Хотя работать с ним, разрабатывать под него очень приятно. А может просто более привычно. В итоге появляется ниша для продуктов типа DBVisit, Attunity Replicate и так далее — которые позволяют сползти с Oracle с минимальными осложнениями, и не очень торопясь…