В мире информационных технологий существует два основных способа размещения инфраструктуры - внутри контура предприятия (on-premise) и в облаке (cloud-based). В данной статье мы рассмотрим преимущества on-premise и почему они могут быть выгодными для некоторых организаций.

Контроль над данными

Когда вы размещаете свою инфраструктуру on-premise, вы полностью контролируете свои данные. Данные хранятся на ваших серверах, и вы определяете, кто имеет доступ к ним. Можете просматривать журнал действий и контролировать права пользователей. Это особенно важно для организаций, работающих с чувствительными данными или имеющих строгие требования к безопасности. Облачные решения не могут дать гарантию сохранности информации из-за рисков DDos атак.

Так, например, онлайн-доска sBoard встала в контур нескольких крупных банков, успешно пройдя аудит безопасности.

Гибкость

При использовании on-premise вы можете настроить свою инфраструктуру под свои потребности. Можете выбрать продукты и решения, которые наиболее эффективны для вашего бизнеса, и настроить их под требования безопасности и количество человек. Это достигается за счёт специфического кода, который совместим с интеграторами, которые есть в компании.

On-premise подходит для компаний, у которых есть специфические требования или уникальные бизнес-процессы, которые сложно адаптировать к общим облачным решениям.

Скорость доступа к данным

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

Быстрый доступ к информации важен для финансовых организаций или банков, которые прямо зависят от скорости доступа к данным.

Предсказуемые затраты

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

Соответствие требованиям законодательства РФ

Например, существует 152-ФЗ «О персональных данных», который обязывает не раскрывать персональные личные данные третьим лицам. Из‑за того, что on‑premise решение располагается на ваших серверах, и внутри корпораций существует строгая система сдержек и противовесов к доступу к данным, риск их потери становится минимальным.

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

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

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


  1. K0styan
    06.09.2023 08:21
    +3

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

    Но прежде чем повернуть рубильник, надо подбить баланс. И этой проблеме заметка никак не помогает.


  1. Batalmv
    06.09.2023 08:21
    +3

    Вообще первое, на что стоит смотреть - это регуляторные требования. Просто чтобы не тратить время дальше.

    Что касается остального:

    1. Контроль данных - на самом деле, "вы" - это не единое целое, и внутренний "фрод" никто не отменял. В целом, вы просто строите безопасность исходя из ваших требований, и клауд обычно помогает в реализации части из них. Но без конкретных требований дальше смотреть смысла нет

    2. Как влияют DDoS атаки на сохранность данных я не понял, ну да ладно. Наверное я не так прочитал

    3. Скорость - зависит от того, где находятся получатели инфы. Подсказка - они не в серверной. Поэтому чуда нет от слова совсем. Дальше читать пункт смысла нет :)

    4. Про затраты - это даже сложно комментировать. В случае on-premises вы ВСЕГДА закупаете наперед и НИКОГДА не знаете (кроме варианта когда вы купили овердофига), хватит вам или нет. Преимущество клауда именно в возможности платить по факту, но никто не запрещает покупать наперед и получать существенные скидки


    1. KivApple
      06.09.2023 08:21
      -2

      Облака дороже своих серверов, если нагрузка +- постоянная.

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

      А если это какая нибудь джира, то вряд ли у вас внезапно станет в 10 раз больше разработчиков, а когда вы закупите сервера, они все уволятся. Количество сотрудников обычно меняется плавно и предсказуемо.

      Плюс свои сервера могут работать с НЕКОТОРОЙ перегрузкой по вычислительным ресурсам (главное чтобы дисков хватало), просто сервисы больше будут тупить, но до каких-то пределов юзабельно. А облака за +N юзеров выставляют новую цену.


      1. Batalmv
        06.09.2023 08:21
        +2

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

        Нагрузка в большой огранизации никогда не бывает постоянной. Причин 100500, я назову некоторые:

        • регламентные расчетные процедуры раз в месяц/раз в день (банки, телеком, страховые). Это требует много ресурсов,а критичность задачи высока. Остальное время они гуляют, так как часто их банально некому отдать (просто нет таких потребителей). Итого юзаем редко, платим все время

        • Многие не работают 24/7, даже в стране с несколькими часовыми поясами. Банально люди спят. Поэтому ночью обычно все это дело гуляет

        • Многие приложения имеют пики загрузки, которые не пересекаются, или пересекаются. Условно отделения работатют з 9 до 18, а канал самообслуживания имеет пик в обед и вечером.

        • Бывают пиковые дни, когда словить нагрузку в два-три раза больше как не фиг делать.

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

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

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

        Ну и то о чем я писал, организация себе покупает наперед, а с точки зрения финансов это тоже расходы, так как миллион сейчас, и миллион через год - это разные миллионы :)

        "Плюс свои сервера могут работать с НЕКОТОРОЙ перегрузкой по вычислительным ресурсам (главное чтобы дисков хватало) " - эту фразу я комментировать не буду, я надеюсь это просто описка, большая :)


        1. Areso
          06.09.2023 08:21

          Типа в облаках оверселлинга не бывает?

          Зато если брать наши широты, то за полку процессора провайдер возьмёт за текстикулы, а на своём никто и слова не скажет.


          1. Batalmv
            06.09.2023 08:21

            Я не совсем понял .что такое "оверселлинг"? Правда

            Смотри, "облако" - это возможность. Если у кого-то нет мозга, он переплатит в любом месте.

            Про широты - я имею практический опыт з AWS + базовый сертификат, и немного Гугль и IBM. Там такого понятия, как кто-то кого-то берет за "полку" нет от слова совсем :) Ты купил "ядра чистый изумруд" - они твои.

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

            Если о "полке" в целом (я так понимаю речь идет о ситуации, когда CPU утилизирован на 100%), то для "расчетного" приложения это хорошо, правильно и единственно правильный способ утилизации ресурсов. Иначе вопрос к програмистам. Для "пользовательского" приложения ситуация с точностью до наоборот - скорее всего оно уже близко к клинической смерти и пользователи разрывают кол центр. Но так как расчетные приложения редко когда работают 24/7 (но я могу предложить, что такого рода бизнес задачи есть), то это не должно быть критично.

            Ниже тоже хороший комментарий, так как никто из фанатов on-premises не берет во внимание стоимость компетенций, а это очень круглая сумма


            1. Rsa97
              06.09.2023 08:21

              Я не совсем понял.что такое «оверселлинг»
              Это элементарно. У нас есть N ресурсов, а продаём мы 2N (3, 4,… 10N), рассчитывая, что среднее потребление не превысит 50% от проданного и пики от разных клиентов не наложатся друг на друга.
              Скажем, 100-квартирный дом. Каждому клиенту предлагается 100Mbit интернет. Вы думаете, что на дом действительно заходит 10Gbit? А на микрорайон из 10 домов 100Gbit?


              1. Batalmv
                06.09.2023 08:21

                Ну так все делают, тоже самое в on-premises дата центре. Либо вы переплачиваете, а ваши ресурсы ничего не делают.

                Но опять же, никто не мешает купить в could сервак и он весь твой :) Если вот прям так важно.

                Но в реале это голая теория, так как на самом деле, если мы говорим о обычной "пользовательской молотилке", вы настроите порог, когда поключится новый сервер намного раньше, чем наступит 100%. Но в клауде вы, если к примеру говорить об AWS, имеет минимум три AZ в регионе и в целом можно не сильно заморачиваться отказом серверной, поставив порог утилизации, после которого наращивать ресурсы на уровне 60-70%. И получится, что я плачу ровно за утилизацию того, что мне надо с коэфициентом 60% (очень грубо). Условно имею минимум на машинки, могу расти до 6, при пороге в 65% на CPU.

                А в своей серверной, дай бог чтобы их было две, я должен держать утилизацию на уровне 40%, иначе после ее превышения у меня реально нет защиты от отказа серверной/сети между дата центрами. Плюс самому заморочиться на тему active-active, что не всегда легко сделать при большом расстоянии. Итого я покупаю и всегда плачу за ресурсы под пик, при этом утилизация выше 50% означает, что при отказе одной площадке я потерял все.

                И получается, если мой пик - 24 ядер чистый изумруд, в клауде я плачу за текущую утилизацию поделить на .6, и минимум за 6 всегда. А в своем ДЦ, если их два - я плачу за 48 всегда.

                В сухом остатке то что? Cloud провайдер прямо это и говорит, декларируя, что цена будет меньге за счем economy of scale. И все это знают. Просто я с таким термином не сталкивался, хотя в реале это просто те же яйца, только с позиции "критика"


  1. AlexKMK
    06.09.2023 08:21

    Премис дешевле если есть серьезные компетенции. Причем, компетенции нужны во всём, что касается, иначе железо будет так и дальше работать на уровне прошлого десятилетия (как в эффективности разработки так и по безопасности/надёжности)

    Вот вам примеров.

    Anycast.

    Хотите вы например гео-кластер. В облаке это легко делается с помощью BYOIP. Любой админ в два клика.

    Расскажите, какой процент админов может настроить эникаст на cisco и с куберовским ингрессом его связать? А сколько ДЦ вам дадут эникаст или циску/аристу в управление?

    Централизованный IAM.

    Во всех облаках есть IAM и он вшит сразу - его не обойти. Кто будет в орге интегрировать по кругу KK/FreeIPA/AD?

    Лямбды.

    Катастрофически снижают стоимость разработки - всякие ТТМ и ТСО. Кто будет FaaS ставить ради одной функции (хотя потом их будет десяток)? Никто. Так и будем на контейнерах в лучшем случае, а то и монолит городить.

    Управление инфраструктурой.

    Я уверен, что в 99% случаев, премис будет катиться накликиванием и башами. В оставшемся 1% случае - ансиблом. Никакого управления и воспроизводимости, никакого терраформа.

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

    П.с. у нас сервис гетерогенный, крутится в Яндексе, Гугле и премисе. Ещё есть часть в Амазоне и облако собственного железа на несколько тысяч машин (но я туда благо не лезу). Мы ведём работу на то, чтоб уехать на железо с сохранением уровня качества/надёжности/управляемости. Это ой как не просто, хотя, по нашим подсчётам, на премисе мы получаем экономию процентов 60 от стоимости облака и на круг такой переезд за год-полтора выходит в плюс.

    Но в большинстве случаев переезд на премис выглядит так : поменяли теслу на мотоблок. А чо, тоже 40км/ч едет и дешевле!


  1. olga_ryabukhina
    06.09.2023 08:21

    Так это же не только в России, получается