7 типичных ошибок при сравнении своих серверов с облаком

    Многие сомневаются, что облака обходятся дешевле собственного железа — такую точку зрения мы в ActiveCloud встречаем довольно часто. Одни пользуются облаками из-за гибкости, вторые хотят уйти от рутины, третьим нужна централизация, четвёртым — безопасность. Однако облака не только удобны, но и выгодны, и мы попробуем объяснить почему.

    При оценке эффективности перехода в облака Заказчики зачастую склонны сравнивать стоимость владения облаками и железом в лоб. Например, если покупаем 5 серверов с 40 процессорными ядрами и 256 ГБ RAM, то и у облачного провайдера запрашиваем аналогичные ресурсы (40*5=200 vCPU + 256*5=1280 ГБ vRAM), а потом сравниваем затраты за 3 года или даже 5 лет.
    К сожалению, в большинстве случаев такой подход не будет объективным, поскольку не учитывает ряд важных нюансов, напрямую влияющих на стоимость владения.

    1. Не учитываются ресурсы, требуемые для обеспечения отказоустойчивости


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



    В случае своего железа потери на резервирование придётся вычесть из потенциально доступного на оборудовании пула ресурсов. В нашем примере с 5 серверами Заказчик при сохранении отказоустойчивости не сможет загрузить серверы по процессору и памяти более чем на 80%, иначе в случае отказа одного из хостов часть серверов физически не смогут быть перезапущены из-за нехватки ресурсов.

    Конечно, можно рассчитывать, что в случае аварии вы сможете временно остановить ряд некритичных сервисов, но такой подход в реальных условиях как правило не работает.

    То же самое справедливо и для облачного хранилища данных — в цену виртуального дискового пространства уже заложены устойчивые к множественным отказам типы рейдов и резервные диски горячей подмены, а в случае собственной СХД будут доступны для использования 45-65% от сырого дискового объема в зависимости от выбранного типа RAID-массива.

    2. Не учитывается предел загрузки серверов и систем хранения данных


    Практика показывает, что серверы архитектуры x86 не стоит постоянно нагружать более чем на 70-80% по процессору и 80-90% по памяти, иначе возможны просадки производительности, особенно заметные во время запуска обслуживающих задач (например, во время резервного копирования). При этом кратковременные всплески нагрузки железо, как правило, переживает нормально, а вот при долговременной работе в таком режиме деградация производительности размещённых на этом железе ИТ систем очень вероятна.

    По этой причине многие сервисные провайдеры не только соблюдают правила допустимой предельной утилизации своего оборудования*, но и фиксируют такие обязательства в договоре с Заказчиком.

    Выдержка из договора SLA для нашего облака VMware




    На системе хранения данных утилизировать весь доступный объем, получившийся после сборки RAID-массивов, также не всегда получается, поскольку требуется резерв для работы различного функционала стораджа (например, аппаратных снапшотов или тиринга). Размер такого резерва может составлять 10% и более от доступного для адресации места.

    При использовании СХД на механических дисках (HDD) размеченные луны не рекомендуется заполнять более чем на 70-80% при интенсивной дисковой нагрузке, чтобы избежать деградации производительности хранилища. SSD диски такой проблемы лишены, однако all-flash стораджи сегодня все еще достаточно дороги, и не для каждой компании их покупка рентабельна.

    3. Не учитываются издержки, связанные с ограниченным масштабированием


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

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

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

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

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

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

    4. Не учитываются издержки на неточный сайзинг ключевых бизнес-систем


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

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

    5. Не принимается в расчет стоимость обслуживания своей инфраструктуры


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


    На основе статистических данных, в том числе HH.RU(https://stats.hh.ru).

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

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

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

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

    6. Не всегда учитывается стоимость вендорской поддержки используемого ПО и оборудования


    Каким бы именитым не был производитель, от производственного брака и ошибок в работе софта все равно не застрахован никто. Особенно бывает обидно, когда из-за этого не просто некорректно работает часть функционала, а невозможна эксплуатация приобретенных ИТ активов в целом, и оперативно решить вопрос с производителем не получается, даже если приобретена дорогая next business day поддержка.

    Происходит такое по разным причинам: иногда у вендора ещё не выстроены процессы, и поддержка оказывается в ограниченном режиме, иногда нужных деталей нет в ЗИП, иногда требуются кастомные прошивки, на написание которых уходит не одна неделя, а то и не один месяц, — однако результат всегда один — потраченное время, нервы, сорванные сроки проекта и вызов на ковер к бизнесу. Думаю, многие согласятся, что переложить подобные риски на плечи провайдера намного приятнее.

    7. Не учитывается стоимость постройки и содержания своей серверной


    Облачные провайдеры обслуживают большое количество Заказчиков, и недоступность облака по любым причинам сильно бьет по деловой репутации поставщика услуг, даже если отказ произошел не по его вине. Клиентам все равно, какого размера дерево упало на датацентр, и какого цвета был экскаватор, повредивший оптику. Поэтому вопрос выбора и оснащения площадки как правило не стоит — арендуем Tier3 ЦОД и подключаем несколько Интернет-каналов с защитой от DDoS.

    Чтобы обеспечить похожий уровень надежности и безопасности в локальной серверной, придется инвестировать в нее порядка 100 000 $ на стойку, но и в этом случае по ряду параметров коммерческий дата-центр будет выигрывать.

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

    И конечно же все вышеперечисленное придется обслуживать, что вряд ли обойдётся дешевле четверти миллиона в год на каждую полную стойку.

    Можно облегчить себе жизнь и разместить свое оборудование в коммерческом ЦОД. Однако преимущества аутсорсинга непрофильных ИТ операций достаточно быстро становятся очевидны, и от аренды стоек Заказчики переходят к гибриду своего железа и постепенно его заменяющих облачных сервисов.

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



    Быстро рассчитать стоимость ресурсов облака поможет калькулятор на сайте ActiveCloud — есть возможность сразу учесть в расчете резервное копирование, техническую поддержку, лицензии на операционную систему и другие опции. Если у вас есть потребность сравнить стоимость владения облачной и собственной инфраструктурой в деталях – напишите на dmitriy.yashin@activecloud.ru.
    ActiveCloud
    0.00
    Международный облачный провайдер
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 47

      0
      Это всё хорошо, когда ничего нет. А когда всё уже есть — резервы, серверная и т.д.?
        0
        Докупают ещё десяток серверов в свободные юниты и сами становятся «облачным провайдером»
          0
          Сильно зависит от ситуации — как давно построена серверная, сколько лет оборудованию и пр. Если свое железо покупалось сравнительно недавно, то отказываться от него не нужно — лучше перевезти его в тот же датацентр, где находится облако выбранного провайдера, и организовать гибрид с облаком. В этом случае вы получите и гибкость облака, и ваше оборудование сможет отработать положенное, после чего также заменится на ресурсы провайдера.
          С недавно построенной серверной несколько сложнее, но как вариант — использовать ее в качестве резервной площадки, либо арендовать оптику до облака и также организовать гибрид.
            +1
            Перевести своё к провайдеру!? o_O
            Я в Сочи, провайдер, к примеру, в Москве, какое ещё «перевезти»?
            Недавняя серверная уже с резервом, зачем мне резерв резерва?
          +2

          А что вообще переносят в облака? Я имею в в виду какие сервисы? Вряд ли в облака отдают контроллеры домена и прочую инфраструктуру?

            0
            Вполне можно и контроллеры домена. В принципе тебя никто не ограничивает. Например у тебя пара офисов — поднимаешь в облаке домен контроллер, поднимаешь до него туннели и все офисы у тебя оказываются в домене. Для резерва можешь поднять еще один домен контроллер в другом облаке и сделать перекрестные туннели.
              0
              Будет неприятно, когда он свалится в DSRM. В Azure хоть сделали текстовую консоль через последовательный порт, а в AWS и того нет.
                0
                Конкретно в облаках ActiveCloud такой проблемы нет — везде доступна консоль VM. Для VmWare и KVM — через браузер. Для Azure Pack — через RDP клиент.
              0
              Видеонаблюдение, например, типа Ivideon, IPeye, Macrosop и т.п (VSaaS). Хранение архивов в облаке, плюс аналитика на облачных серверах. Не требуются ни локальные сервера, ни видеорегистраторы, ни мутки с VPN и т.п. Очень удобно иметь доступ ко всем камерам через один ЛК или мобильное приложение. Особенно для территориально распределенных организаций, торговых сетей и т.п. Очень динамично растет пока этот сегмент.
                +1
                Как только размер камеры превосходить 640 пикселей по одной стороне, так сразу маркетологи не гарантируют доставку видео до облака.
                А камеры по-прежнему шлют потоки по udp и поэтому очень сильно все зависит от качества интерне-соединения между камерами и «облаками».
                0
                На самом деле размещают практически все — как инфраструктурные системы, так и бизнес-приложения. Многие оставляют у себя на земле только небольшой базовый набор из дополнительного контроллера домена и принт-сервера, а то и просто VPN-шлюзом ограничиваются. У нас как-то был подобный проект — Заказчику нужно было переехать в новый офис, где не было места для серверов вообще — только небольшой шкаф для коммутаторов и пограничного шлюза.
                • UFO just landed and posted this here
                +2
                Практика показывает, что серверы архитектуры x86 не стоит постоянно нагружать более чем на 70-80% по процессору и 80-90% по памяти


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

                На тему капитальных затрат на оборудование — никто не мешает брать сервера в аренду, прямо в цодах. И это дешевле IaaS.

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

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

                Если у вас неравномерная нагрузка, тогда возможно вас спасут железные сервера на чуть выше минимальной нагрузки + для пиков нагрузки можно автоматически брать в аренду виртуалки.

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

                И не надо считать, что вам не придется периодически искать и решать нетривиальные проблемы — почему у вас так странно ведет себя приложение или трафик у облачного провайдера (у нас например диски от сервера с базой отваливались), кто виноват и что делать.
                  0
                  CPU Steal time. Отслеживание оверселлинга. У меня на AWS до 80% доходило на американском сегменте в конфигурациях, доступных для free tier.
                    0
                    По поводу оверселлинга:

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

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

                    «Честные» ядра нужны в облаках, рассчитанных на корпоративные приложения. В этом случае «честность» обеспечивается контролем предельной утилизации CPU на хосте, мониторингом доступность физического процессора для ВМ (CPU ready), а также, как верно написал Spline, периодическими замерами CPU steal time.

                    Заказчик вполне может контролировать оверселлинг — либо делая собственные замеры, либо запрашивая графики мониторинга у провайдера.
                    +2
                    1. Не учитываются ресурсы, требуемые для обеспечения отказоустойчивости…
                    А в облаке как они учтены? В облаке что все машины сразу в фул толеранс? Или облако автоматом для каждой первой машины по две реплики на разных сайтах держит?
                    Опять взяли за основу кейс аномально быстрорастущего стартапа и пытаются натянуть его на все что движется…
                      0
                      Нет, машины не в фулл толеранс, к сожалению, т.к. эта технология пока слабо применима в облаках — такое делаем пока только в рамках частной инсталляции. С репликами на разных сайтах проще, но это все-таки уже катастрофоустойчивость, поэтому предлагается в виде платной опции.
                      Под ресурсами для отказоустойчивости понимаем гарантию наличия ресурсов для работы виртуальных машин при любой поломке. Это достигается резервными свободными хостами в кластерах виртуализации и регламентами по предельной загрузке продуктивного оборудования.
                        0
                        А можно узнать какой лимит резервных свободных хостов и какие нормативы по предельной загрузке в вашем облаке?
                          0

                          Загрузка физических процессоров на конкретном хосте — не более 80%, физической памяти на конкретном хосте — не более 90%. По количеству свободных хостов требования разнятся в зависимости от облака (у нас их несколько) и конфигурации оборудования в конкретном кластере виртуализации. Стараемся держать свободными не менее четверти ресурсов конкретного кластера.

                            +1
                            Например 6 серверов
                            www.ovh.ie/dedicated_servers/enterprise/1801sp94.xml
                            1000+ евро

                            И ваш калькулятор на 2000+ евро image

                            девопс/сисадмин мне будет нужен в любом случае.
                            Резерв мощностей в OVH (в сравнении с ресурсами в облаке) у меня х6 по процессору и примерно х3 по памяти

                            Вы можете это как-то прокомментировать?
                              0
                              IaaS и выделенные серверы — это все-таки разные услуги. Если не сравнивать конфигурацию именно железа, то основное различие — в зоне ответственности провайдера. OVH в рамках данной услуги следит только за работоспособностью самого железного сервера и доступности его сетевых интерфейсов по сети, а его настройка, защита периметра, организация нужной архитектуры сети и пр. уже ложится на ваши плечи. В то время как в IaaS вам не нужно думать о слое железа вовсе, и вместе с пулом облачных ресурсов вы получаете полноценную виртуализацию сетей, где можно любым образом нарезать подсети, есть кластеризованный виртуальный роутер на периметре с полным набором сервисов (FW, NAT, site-to-site VPN, client-to-site VPN и пр.), продвинутый балансировщик внешних и внутренних запросов, система мониторинга, широкий функционал подготовки шаблонов, гибкое управление через API и другие сервисы, доступные по умолчанию и включенные в стоимость.

                              Услуги сильно отличаются и по отказоустойчивости. Я допускаю, что в OVH хорошая система бекапирования, и при отказе арендованного железного сервера они выделят другой и накатят на него бекап — вопрос, сколько времени это займет, и будет ли, к примеру, дневной бекап актуален для вашего сервиса? В облаке при жестком отказе хоста размещенные на нем ВМ будут лишь перезагружены, а если хост просто деградировал, то машинки будут мигрированы без ребута.

                              Если же говорить именно о железе, то в облаке VMware, которое на скриншоте, используются процессоры Xeon E5-2697A v4, которые быстрее работают с памятью, обладают более высокой производительностью из расчета на ядро, чем Xeon E5-1660 v3, а также позволяют выдать вашему серверу значительно большее кол-во ядер, т.к. многим нагруженным аппликейшенам, серверам баз данных, OLAP-кубам или процессинговым молотилкам просто не хватит 8 ядер Xeon E5-1660 v3.

                              Что же касается стоимости, то в случае с OVH цена указана без НДС, а в калькуляторе — с НДС, что делает реальную разницу меньше. Плюс, с объемом более 100 т.р. вы уже можете рассчитывать на скидку, и также сможете снизить объем платежа за счет предоплаты.

                              P.S. Лучше ответить поздно, чем никогда )
                      +1
                      Например, если покупаем 5 серверов с 40 процессорными ядрами и 256 ГБ RAM, то и у облачного провайдера запрашиваем аналогичные ресурсы (40*5=200 vCPU + 256*5=1280 ГБ vRAM)

                      это как у вас вышло 5*40 полновесных ядер = 200 vCPU !? vCPU у амазона и гугла это hardware thread, а не то что вы подумали.
                        0
                        А трафик у вас, как в Амазоне, в 3-4 раза дороже?
                          0
                          Нет, мы не берем дополнительную плату за траффик. Каких-то лимитов по объему месячного траффика также не устанавливаем. У нас, конечно, есть механизмы защиты от DDoS для внешних и внутренних атак, направленных на переполнение каналов, но если траффик валидный, то не лимитируем. И в целом избегаем каких-то скрытых платежей.
                            0
                            Можно тор-ноду поставить?
                              –1

                              Для наших Заказчиков это лишние риски блокировки со стороны РКН, поэтому нет, тор-ноду поставить нельзя.

                                0
                                Можно поинтересоваться, каким пунктом договоров/дополнений/правил это запрещено? В частности, интересует не выходной узел TOR, а промежуточный.
                          +1
                          Насчёт бюджетов в корпорациях: если покупка или аренда серверов требует тендеров и много месячных согласований, то и выбор облачного провайдера их потребует, причём тендер проводить каждый раз при увеличении ресурсов, а не так что один раз согласовал на 1000 в месяц, а потом молча оплачивают счёта на миллион.
                            0
                            Сильно зависит от конкретной компании, но в целом да — тенденция ужесточения внутреннего контроля в корпорациях прослеживается, и тендер при выборе облачного провайдера как правило приходится играть. Другое дело, что компании в облако чаще заезжают сразу большим количеством ресурсов. Т.е. сначала берут, условно, на 200 тысяч, а потом по мере необходимости периодически расширяют по 20 уже без тендера.
                            Тендерную же процедуру просто повторяют периодически — кто-то раз в год, кто-то раз в 3 года, но при этом используют уже готовые тендерные документы с небольшими правками.
                            0
                            Есть Azure Stack?
                              0
                              Нет, Azure Stack пока опасаемся. Нужно понять динамику и вектор развития платформы — как быстро и в каком объеме сервисы большого Azure будут переноситься в Stack, не останутся ли через год-два обладатели Stack-инсталляций без полноценной поддержки с обновлением функционала и т.п.
                                0
                                Да, мы еще помним про Azure Pack, последнее обновления для которого вышло года полтора назад, хотя обещали поддержку аж до 2027 года. Еще про Azure Stack надо помнить, что там довольно высокие CAPEX и OPEX. Ценник для конечного клиента, вероятно, будет просто огромный, дороже чем в Microsoft Azure. Вот тут можно посмотреть стоимость лицензий.
                              0
                              А как обстоят дела с ИБ. Любая служба корпоративной защиты завернет все облака на свои сервера.
                                +1
                                1. Не любая.
                                2. Есть облака, сертифицированные по всяким разным стандартам типа PCI DSS, БиоПД, ФСТЭК и т.д. Причем свой ДЦ еще тоже надо сертифицировать, что непросто и небыстро.
                                3. Для параноид-режима, типа крупных банков, возможно физическое огораживание стоек в ДЦ с автоматчиками по периметру. Хотя это уже не облака, а колок/аренда.
                                +2
                                Прямо сейчас я участвую в планировании миграции из собственного датацентра в aws. По самым оптимистичным прикидкам за aws придется платить минимум в 2.5 раза больше, чем за собственный датацентр. Опытные люди говорят, что финальная разница будет еще больше. При этом единственный весомый плюс от миграции будет мгновенная доступность новых машин когда они понадобятся.
                                  +1

                                  С трудом верится, что прямо-таки единственным. А как же широкий выбор уже реализованных в AWS инфраструктурных сервисов, как же большое количество встроенных инструментов для разработчиков? И управлять инфраструктурой, вероятно, станет проще, а обслуживать ее — дешевле. Опять же — если стоимость AWS кажется высокой, а бизнес находится в России, рассмотрите отечественных провайдеров. Наверняка получится дешевле, и с колебаниями курсов валют как-то проще.

                                    +1
                                    Бизнес не в России, так что отечественные провайдеры не вариант. Широкий выбор сервисов aws, как я уже писал выше, надо использовать осторожно, чтобы не попасть в ситуацию с vendor locking. Предварительный опыт использования инфраструктуры aws продемонстрировал, что там хватает своих нюансов, не все так замечательно, как в рекламных проспектах.
                                      +1
                                      Большинство инфраструктурных сервисов AWS требуют заточки кода приложения под них. А без этого, использование aws в режиме «хост для виртуалок/контейнеров» реально дорого.
                                    +1

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


                                    Для получения экономической выгоды от облаков необходимо часто в корень перерабатывать архитектуру всей инфраструктуры. Тут речь не о корпоративном портале или веб сайте компании, а о кейсах когда у компании 20+ различных решений используется. Переработка архитектуры будет стоить дороже чем выгода от экономии серверов или своей новой серверной. Окупится, может быть, через пять лет. Инвестиции на такой период с такими высокими рисками внедрения бизнес не любит.
                                    Staff OpEx уже занимает серьезную долю бюджета и, не редко, даже людей быстро нанять сложнее чем купить сервера :)

                                      0
                                      Подпишусь под каждым словом. И добавлю, что надо менять менталитет разработчиков на тему экономии ресурсов. Нужно сделать эксперимент — поднял сервер, проверил, что надо, отдал сервер. Потому как я сейчас наблюдаю картину, когда на собственной инфраструктуре вирртуализации заброшенный тестовый сервер может крутиться годами. Ну и еще надо думать о vendor locking, хотя возможно это больше относится к провайдерам типа гугла и амазона.
                                        0
                                        На мой взгляд, размещение виртуальных машин у провайдера — это вполне облачная услуга, которой чаще пользуются как раз-таки корпоративные Заказчики. А вот быстро растущие стартапы, как показывает практика, предпочитают покупать свое железо, размещать его в коммерческих датацентрах и развертывать разрабатываемые системы bare-metal. От таких ребят я неоднократно слышал, что для них обеспечивать стабильность и скорость работы своих систем поверх виртуальной инфраструктуры дороже, нежели держать пару свободных хостов на случай отказа.
                                        Впрочем — допускаю, что это только мой избирательный опыт.

                                        Что же касается коренной переработки архитектуры в компаниях, где по 20 (а иногда и по 80) различных ИТ систем используется, то такая дорогостоящая и сложная работа даст большой эффект при размещении как в облаке, так и «на земле».
                                        0
                                        Давать Storage SLA по средней latency — дурной тон. На Хабре было значительное количество статей, почему.
                                          0
                                          Ну… на текущий момент указываем таким образом. А как, на ваш взгляд, правильнее указывать? По максимально допустимому пиковому значению?
                                            0
                                            Service Level Indicator — величина latency, а Target — попадание в этот определенную границу не менее определенного процента случаев. Обычно проблемы создает длинный хвост в распределении IO latency. То есть пример хорошего SLT — latency менее 5 мс для 99% запросов.

                                            У вас среднее может быть 3 мс, но если в хвосте хотя бы 1-2% влетают из 200-300 мс это может стать причиной разрыва сессий для некоторых приложений.
                                          0
                                          Я считаю, что плохой тон для компании увольнять хорошего специалиста, по случаю миграции в облако серверов компании. Но если его не увольнять, то экономия сомнительная получается. Обычно такой сотрудник начинает выполнять другую работу без увольнения. Поэтому ФОТ лучше не считать. Ну, а если ФОТ не считать, то и экономический профит облака теряется.
                                            +2
                                            Если человек начинает делать новую полезную работу, не связанную с администрированием инфры и виртуализации, то почему же считать его ФОТ? Ну или тогда уж добавлять новую штатку в обоих случаях…
                                              0
                                              Если человек начинает делать новую работу, то его ФОТ вычитается из расходов на администрирование серверов и прибавляется к расходам на что-то другое, пускай даже на «поддержание лояльности более ненужных сотрудников».

                                            Only users with full accounts can post comments. Log in, please.