private cloud что это
Что такое частные, публичные, гибридные облака
Чтобы построить облачную инфраструктуру, компании могут использовать собственное оборудование, арендовать готовый сервис у провайдера или совмещать оба варианта. В зависимости от этого облака подразделяют на три типа:
Посмотрим, как применяют каждый из этих видов облачной инфраструктуры.
Что такое частное облако
В частном облаке инфраструктура находится в собственности пользователя, и ей можно распоряжаться ей в полной мере.
Преимущества частного облака
Эффективное использование вычислительных ресурсов организации. Облачные технологии позволяют рационально перераспределять нагрузку между физическим оборудованием и рационально использовать собственные мощности.
Автономность. Организация уверена, что все вычислительные ресурсы находятся в её распоряжении. Ошибки провайдера или процессы соседей по облаку не скажутся на инфраструктуре.
Легкий доступ к вычислительным ресурсам: если оборудование располагается на территории компании, это позволяет управлять вычислительными ресурсами без использования интернет-соединения.
Повышенный уровень безопасности: частное облако полностью находится в ведении одной организации. Администраторы могут контролировать инфраструктуру и не допускать к ней посторонних.
Можно использовать в условиях законодательных ограничений. Из-за требований законодательства, у компаний не всегда есть возможность пользоваться услугами публичных облачных провайдеров. Тогда частное облако — единственный выход.
Недостатки частного облака
Сложно спроектировать: на старте тяжело определить, сколько вычислительных ресурсов потребуется и как оптимально организовать инфраструктуру.
Дорого создавать: чтобы создать частное облако, необходимо вложить средства в оборудование и лицензирование, потратить ресурсы на обучение специалистов.
Дорого содержать: необходимо самостоятельно следить за частным облаком, обновлять оборудование, продлевать лицензии на ПО. Для всего этого нужны деньги и труд специалистов.
Сложно масштабировать: объем мощностей ограничен ресурсами оборудования. Если потребности в вычислительных ресурсах со временем вырастут, придется провести большую работу по закупке и настройке оборудования.
Примеры использования частного облака
В крупных организациях. Частными облаками предпочитают пользоваться крупные и средние компании, которые обладают достаточным объёмом собственных вычислительных мощностей. В этом случае облако позволит снизить затраты на аппаратные и программные ресурсы.
В компаниях, которым важно контролировать свои ресурсы. Крупные разработчики ПО, государственные организации, большие промышленные компании. Частные облака выбирают все, кому важно иметь полный доступ к инфраструктуре и гарантированно получать сервис независимо от сторонних организаций и интернет-соединения.
В компаниях, нуждающиеся в поддержке нескольких больших баз данных. В частном облаке оборудование находится в физической близости. Это ускоряет работу с базами данных. Также в частном облаке легче контролировать создание резервных копий.
В организациях с жестким запланированным бюджетом на ИТ-инфраструктуру, например, в государственном секторе. Затратами на частное облако легче управлять, так как стоимость сервиса не зависит от тарифов внешних провайдеров.
Что такое публичное облако
Публичное облако — готовый сервис по моделям IaaS и PaaS. Пользователи подключается к вычислительным ресурсам через интернет. Примеры публичного облака: Amazon, Microsoft Azure, Google Cloud. Основные заботы по обслуживанию физической инфраструктуры берёт на себя провайдер.
Преимущества публичных облаков
Просто использовать. Чтобы пользоваться инфраструктурой, достаточно иметь доступ к интернету: не нужно тратить время на установку оборудования и ПО, выстраивать технологические процессы, обучать сотрудников.
Гибкая тарификация и отсутствие долгосрочных обязательств. Компания может в любой момент увеличить или сократить расходы на публичное облако. Для этого достаточно выбрать подходящий пакет тарификации. А если услуги станут неактуальными, от них можно отказаться.
Сокращение затрат на обслуживание ИТ. Публичное облако обслуживается силами провайдера. Благодаря этому снижаются затраты организации на зарплату специалистов, лицензирование и поддержание оборудования.
Недостатки публичных облаков
Слабая защищенность данных. Клиенты публичного облака не могут контролировать, где находятся их данные, как осуществляется резервное копирование на уровне провайдера и с каким соседями делится физический сервер.
Зависимость от интернет-соединения. Производительность и доступность публичного облака напрямую связана с шириной и стабильностью интернет-канала.
Зависимость от посторонней организации. Провайдер может допустить аварию, утечку данных или вовсе закрыть сервис. Пользователям публичного облака трудно влиять на такие ситуации.
Невыгодно в долговременной перспективе и в масштабных проектах. Для крупных организаций с постоянными потребностями в мощностях зачастую невыгодно публичное облако, так как приходится регулярно оплачивать счета за инфраструктуру, в которые включена прибыль провайдера.
Не приобретаются материальные активы. Компания не получает в собственность физическое оборудование, которое могло бы статью частью основного капитала.
Примеры использования публичного облака
Для тестирования проектов. Вкладываться в покупку оборудования для нового сервиса рискованно: неизвестно, как долго просуществует проект. Выгоднее протестировать идеи в публичном облаке.
При непостоянных потребностях в вычислительных мощностях. В сезонном бизнесе и для других временных работ целесообразно брать мощности в аренду у провайдера. Так можно платить деньги только за время пользования сервисом.
В малом и среднем бизнесе. Публичные облака обычно финансово доступнее для небольших компаний и не требуют рискованных вложений. Их используют, если содержать свою инфраструктуру нерентабельно.
Чтобы перейти с капитальных на операционные расходы. Иногда частное облако предпочтительно с точки зрения управления финансами. Не нужно рассчитывать срок службы оборудования, начислять амортизацию, обновлять парк.
Что такое гибридное облако
В гибридной инфраструктуре используются как собственные вычислительные ресурсы, так и арендованные мощности. Например, компания может развернуть сервис IP-телефонии на своем сервере, а записи звонков хранить у провайдера. В этом решении совмещены преимущества и недостатки частных и публичных облаков.
Преимущества гибридного облака
Возможность оптимально распределять ресурсы. Организация может максимально эффективно использовать мощности. Например, развернуть частное облако для решения ежедневных задач. А публичное облако использовать в качестве резерва на случай высоких нагрузок.
Оптимизация расходов на инфраструктуру. Компании, которые хотят сэкономить, могут вынести часть инфраструктуры в публичное облако, чтобы не закупать оборудование.
Возможность совмещать производительность с высоким уровнем защиты. В публичное облако можно вынести общие приложения или делать бекапы. А данные, требующие высокой защищенности, размещать в частном облаке.
Недостатки гибридного облака
Сложно интегрировать публичное и частное облако, так как часто для них используются разные технологии.
Увеличение угрозы потери данных, например, при миграции приложения из одного облако в другое.
Снижение отказоустойчивости при размещении единого приложения. Даже оборудование с одинаковыми характеристиками может показывать разную производительность в частном и публичном секторе гибридной инфраструктуры. Это приведет к проблемам в работе приложений, распределенных в таком облаке.
Высокий риск аварий: чем сложнее система, тем больше в ней уязвимостей. В гибридной инфраструктуре может сломаться соединение между частным и публичным облаком.
Примеры использования гибридного облака
Разработчики программного обеспечения часто сталкиваются с проблемой высокой нагрузки на сеть, например, в стадии разработки. В таком случае в момента спада нагрузки будет достаточно собственного оборудования, а в пиковый момент можно успешно использовать и публичные облака.
В компаниях, которым быстро нужны дополнительные мощности. Иногда гибридные облака становятся единственным вариантом, когда требуется больше ресурсов: можно оперативно задействовать вычислительные мощности из публичного сектора инфраструктуры.
В компаниях, желающие протестировать облачные технологии: частично расширить свою инфраструктуру облаком, чтобы опробовать новые возможности.
Очередной взгляд на облака. Что такое частное облако?
Рост вычислительных мощностей и развитие технологий виртуализации платформы x86 с одной стороны, и распространение ИТ-аутсорсинга с другой стороны привели к концепции utility computing (ИТ как коммунальная услуга). Почему бы не платить за ИТ так же, как за воду или электричество – ровно столько и ровно тогда, когда это нужно, и не более.
В этот момент и появилась концепция облачных вычислений – потребление ИТ услуг из «облака», т.е. из некоего внешнего пула ресурсов, не заботясь о том, как и откуда берутся эти ресурсы. Так же, как мы не заботимся об инфраструктуре насосных станций водоканала. К этому моменту была проработана и другая сторона концепции – а именно понятие ИТ-услуг и как ими управлять в рамках ITIL / ITSM.
Был разработан целый ряд определений облаков (облачных вычислений), но при этом не следует относиться к ним как к истине в последней инстанции – это лишь способ формализовать способы предоставления utility computing.
Для совсем упрощенного понимания разницы давайте рассмотрим модель Pizza-as-a-Service:
NIST определяет следующие необходимые черты ИТ услуги, позволяющие считаться облачной.
Почему я об этом отдельно говорю? За прошедшие 10 лет с момента появления определения NIST было много споров об «настоящей облачности» согласно определения. В США до сих пор иногда применяется в судебной сфере формулировка «соответствует букве закона, но не духу» — и в случае с облачными вычислениями главное именно дух, ресурсы в аренду в два клика мышью.
Необходимо отметить, что вышеперечисленные 5 характеристик применимы к публичному облаку, но при переходе к частному большинство из них становятся опциональными.
Ответ: частное облако – это переход к новой административной модели взаимодействия ИТ-Бизнес, который на 80% состоит из административных мер и только на 20 из технологий.
Оплата только за потребленные ресурсы и легкий вход, без необходимости закопать несколько сотен миллионов нефти в капитальных затратах, обусловили новый технологический ландшафт и появление компаний-миллиардеров. Например современные гиганты Dropbox и Instagram появились как стартапы на AWS с нулевой собственной инфраструктурой.
Необходимо отдельно подчеркнуть, что инструменты управления облачными услугами становятся значительно более опосредованными, а ключевой обязанностью ИТ директора становится подбор поставщиков и контроль качества. Давайте рассмотрим проблематику этих двух новых обязанностей.
Появившись как альтернатива классической тяжелой инфраструктуре с собственными ЦОДами и железом, облака обманчиво легки. В облако легко войти, но вот вопрос выхода обычно обходится стороной. Как и в любой другой отрасли облачные провайдеры стремятся к защите бизнеса и усложнении конкуренции. Единственный серьезный конкурентный момент возникает лишь при первичном выборе поставщика облачных услуг, а далее поставщик приложит максимум усилий, чтобы заказчик от него не ушел. Причем далеко не все усилия будут направлены на качество услуг или их ассортимент. Прежде всего, это поставка уникальных услуг и использование нестандартного системного ПО, затрудняющего переход к другому провайдеру. Соответственно, при выборе поставщика услуг необходимо одновременно формировать план перехода от этого поставщика (по сути полноценный DRP – disaster recovery plan) и продумывать архитектуру хранения данных и резервных копий.
Второй важный аспект новых обязанностей ИТ директора – контроль качества услуг от поставщика. Практически все облачные провайдеры соблюдают SLA по собственным внутренним метрикам, что можем иметь крайне опосредованное значение к бизнес-процессам заказчика. И соответственно внедрение собственной системы мониторинга и контроля становится одним из ключевых проектов при переносе значимых ИТ систем к облачному провайдеру. Продолжая тему SLA необходимо подчеркнуть, что абсолютное большинство облачных провайдеров ограничивают ответственность за неисполнение SLA в месячный абонентский платеж или в долю от платежа. Например, AWS и Azure при превышении порога в доступности в 95% (36 часов в месяц) сделают 100% скидки к абонентской плате, а Яндекс.Облако – 30%.
Ну и конечно же, не надо забывать, что облака бывают не только в исполнении мастодонтов класса Amazon и слонов класса Яндекса. Облака бывают и поменьше — размером с кошку, или даже мышь. Как показал пример CloudMouse, иногда облако просто берет и заканчивается. Вы не получите ни компенсации, ни скидки — вы не получите ничего, кроме тотальной потери данных.
Ввиду указанных выше проблем с реализацией ИТ систем высокого класса бизнес критичности в облачных инфраструктурах в последние годы наблюдается явление «облачной репатриации».
К 2020 году для облачных вычислений пройден пик раздутых ожиданий и концепция находится на пути к канаве разочарований (согласно хайп циклу Гартнер). Согласно исследованиям IDC и 451 Research до 80% корпоративных заказчиков возвращают и планируют возвращать нагрузки из облаков в собственные ЦОДы по причинам:
Что же делать и как все «на самом деле»?
Нет никаких сомнений, что облака пришли всерьез и надолго. И с каждым годом их роль будет возрастать. Однако мы живем не в далеком будущем, а в 2020 году во вполне определенной ситуации. Что же делать с облаками, если вы не стартап, а классический корпоративный заказчик?
Про частные «облака»: что и как обычно делается в России, ликбез и основные проблемы
Кто заказывает частные «облака»?
Как правило — это крупные компании, которые уже достаточно зрелы по процессам. У них уже внедрен сервисный подход, но нужно все это автоматизировать частным «облаком». Сервисный подход — это когда каждая часть IT-сферы рассматривается как услуга для пользователя. Например, нужна виртуальная машина — просто отдали еще один экземпляр с нужными правами и настройками. Централизованно и унифицированно. И так далее.
Самый первый заказчик — IT-отделы
Как правило, IT-отделы — это первые, кто понимает, что нужно свое «облако». Обычно происходит так: они поднимают виртуальные машины по запросу для себя, коллег, подрядчиков (кстати, дать доступ подрядчику до своей инфраструктуры — одна из самых частых задач). В какой-то момент становится понятно, что нужно делать платформу — PaaS — и потом все это приходит к SaaS, когда нужная операция делается чуть ли не самим пользователем в один клик. Параллельно описываются все эти процессы и прикидывается их стоимость. Зачем? Потому что зная экономию, куда легче доказывать руководству необходимость такого решения. Появляются понятные для бизнеса деньги. Например, почтовый ящик стоит столько-то, в следующем году будет столько-то новых пользователей и так далее. Появляется главный фактор — цена. И, поверьте, многих несказанно радует переход на язык денег вместо языка «шаманов» обычного IT-департамента.
Большая головная боль — это тестовые среды
Один из основных сервисов для крупных компаний — автоматизация предоставления сред под разную разработку. Тестовые среды требуются почти под каждый крупный проект, потому что, например, в нефтегазовой, банковской или телекомовской среде нельзя оттестировать что-то новое на «сухих» данных. Нужно прогонять, например, по вчерашнему слепку базы в контролируемой среде и смотреть, что на выходе. Когда такой проект один, просто выделяется некий парк серверов, и все гоняется на нем.
Но когда проектов уже десяток — нужны виртуальные тестовые среды. Причем нужны позарез. Их надо развертывать, конфигурировать, убивать или морозить, чтобы они не ели ресурсы. Проектов много, на это уходит ручного труда очень много. Встает вопрос безопасности.
Инфраструктура компаний
Когда компания готова перейти на полностью сервисный подход к IT (а так делает большая часть компаний на Западе просто из-за экономической целесообразности), в частном «облаке» настраивается все необходимое обычным пользователям. Как правило, это почта, бекап, место на диске для хранения данных, виртуальные машины.
Отдельный вопрос — мощность для масштабирования. Например, для колл-центра с ярко выраженными сезонными пиками (туристического или, например, имеющего пик под Новый Год) логично не закупать массу железа и лицензий ради двух недель работы в году — они используют виртуальные ресурсы, которые очень легко масштабируются.
Пиковые задачи
В Big Data (вроде биллинга телекомов, расчета тарифов страховых и так далее) есть задачи, которые возникают раз в месяц и полностью убивают даже тяжелые сервера-молотилки. Например, один из известных мне расчетов шел на физическом оборудовании месяцы, после первого цикла виртуализации — недели, а теперь все свободные ресурсы их «облака» занимаются именно этим подсчетом (и при этом не тормозят остальные процессы) — и все проходит за дни.
Потом идут новые проекты
Предположим, банк запускает какой-то проект, про который совершенно непонятно, сколько он будет брать ресурсов. Непонятно потому, что стартап внутри компании новый, и никто не может сказать — будет это 500 человек, 1% от клиентской базы или вообще каждый второй клиент. Соответственно, логично не закупать сначала дорогое железо с одной стороны, но и страховаться от ожидаемого или неожиданного пика — ведь придется задорого менять инфраструктуру, если что. Поэтому здесь тоже логично все крутить в «облаке». Но не в публичном, так как речь о банке и 152-ФЗ.
SaaS для клиентов
Иногда случается, что компания не хочет разворачивать «облако» для миграции со своей архитектуры, но не против отдавать сервисы из него своим подрядчикам или клиентам. В этом случае запускается отдельное от общей инфраструктуры частное «облако», откуда, например, могут раздаваться рабочие места и доступы к важным данным в огромных рекламных агентствах или же откуда могут настраиваться защищенные доступы к банк-клиенту, бухгалтерии и эквайрингу для клиентов банков.
Необычный случай
В одной крупной энергетической компании ситуация была в целом стандартная — сотни дочерних обществ, множество филиалов, очень сложная структура отдельных компаний внутри объединения. Все это обслуживает одна IT-служба. Парни справляются, все настроено по уму, но есть одна проблема. Конкретно — за IT-услуги (например, виртуальные машины или место на серверах) нужно делать расчеты внутри объединения, а для этого нужно как-то выставлять счета. А делать это нереально сложно, потому что, никто не может чётко проверить, сколько ресурсов потрачено на тот или иной запрос. И предсказать тоже. В итоге они развернули и настроили частное «облако», которое позволило просто и прозрачно перейти к подсчетам ресурсов для каждого. Учитывая, что теперь каждый может взять и посмотреть в реальном времени сколько и за что он должен, споры пропали. Биллинг справедливый. Получился такой хороший финансовый арбитр, позволяющий привести все в норму. Ну и плюс они потом стали постепенно прикручивать другие функции к уже готовому «облаку».
У нас внутри компании одной из единиц расчета является процессорное время — например, каждый проект имеет квоту на использование ресурсов «облака», и не переходит ее. Квота определяется по приоритету проекта. Для нас это очень удобно, потому что еще завязано на систему менеджмента, где прямо при решении о важности проекта подцепляется все необходимое.
Вот как такое распределение может выглядеть из интерфейса управления:
А вот пример внутренних расчетов:
Как обычно внедряется частное «облако»?
На практике — с трудом. Основная проблема, с которой я сталкивался — это простое непонимание того, как все работает и чем может быть выгодно. Бывает, мне пишут из IT-отделов, просят сделать расчет, чтобы они его могли показать руководству. Берут свои расчеты, берут мои расчеты — и только две этих бумажки вместе (чтобы было и мнение сотрудника, и внешней компании) убеждают. Когда решение все же принято, шаги внедрения такие:
1. Сначала IT-службы обсуждают, что и как должно быть.
Формируется каталог сервисов, потом смотрим, какие куски уже реализованы, а какие нет. Например, выделение виртуальной машины по запросу — сервис не для конечного пользователя, а для разработчика или для подрядчика. Соответственно, он автоматизируется, детализируется, пишется SLA. Или расширение фермы на 100 пользователей — нужно делать связь с другой частью фермы. И так далее.
2. Каждый сервис детализируется.
3. Затем смотрим, что уже есть и можно использовать в развертывании «облака».
Например, есть сервисдеск-система. Все это прописывается в реалиях частного «облака».
4. Затем стандартные вещи.
Это выбор вендора, подсчет стоимости, точный финансовый план до копейки по железу, работам, лицензии на продукты для создания «облака», интеграции.
5. Ну и потом, непосредственно, работы.
Пример реализации
Расскажу про наш собственный опыт. Нам, как проектной компании, которая занимается разработкой новых решений или донастройкой коробочных решений, необходима среда разработки и среда для тестирования. До 2006-2007 года вся наша лаборатория состояла из железных серверов, то есть фактически под каждый из проектов нужно было сформировать спецификацию, где-то заказать или найти на складе сервера, привезти их, смонтировать, подключить. Если мощности не хватало, то это опять заказ, ожидание и привоз. Почти каменный век.
Потом появились платформы виртуализации VMware (здесь важно пометить, что альтернативы ей на тот момент де факто не было). Мы решили закупить несколько мощных серверов, поставить на них VMware Server, и облегчить всем жизнь. После этого действительно стало полегче с точки зрения скорости развертывания, но не сильно. Потому что все это развертывалось фактически вручную, даже несмотря на наличие механизмов по управлению этими виртуальными серверами, все равно наши админы большую часть работы делали сами: принимали заявки, выделяли вычислительные мощности, вручную отслеживали насколько тот или иной сервер сейчас загружен. Зачастую возникали ситуации, что конкретный железный сервер настолько был загружен виртуалками, что приходилось его вручную оптимизировать, переносить виртуалки с сервера на сервер. Все это жутко мешало работе проектных команд. Они заказывали определенную мощность, но получить ее не могли.
Поэтому конечно, когда появилась возможность поставить платформу управления, мы ее поставили. Выбрали HP, отчасти потому, что у нас был большой опыт работы с их системами, отчасти, потому что из реальных конкурентов HP в плане управления «облаком» на тот момент был только BMC. Но под наши разработческие задачи, чтобы пользователи могли сами выбирать себе параметры стенда, больше подходил HP с точки зрения гибкости управления. Когда мы все это дело автоматизировали, то уже не нужно думать, где крутится виртуалка, она сама переносится с одной вычислительной мощности на другую, для того чтобы поддерживать необходимый уровень производительности. Если какой-то определенный необходимый квант мощности превышен, то она сама добавляет еще и еще. Теперь наши инженеры практически не заказывают железные сервера.
Потом уже мы доработали эту систему управления коннектором к публичному «облаку» (в Amazon и к нашему собственному публичному «облаку» — прикрутили и возможность выбора), чтобы можно было показать заказчику получившееся решение в любом месте, где есть интернет. У CA, например, по умолчанию есть прямой коннектор к публичным «облакам». Поэтому если кто-то не хочет заморачиваться на доработку, в некоторых случаях можно выбрать CA.
Сейчас в нашем частном «облаке» порядка 1000 стендов, понятно, что они не все активированы, но в среднем каждый пятый работает постоянно. Сервера самые разные, с точки зрения «облака» на самом деле не очень важно какие, могут быть IBM Blade или HP Blade. Подключившись к «матрице» он просто становится еще одной каплей в море. Затраты конкретного стенда сейчас автоматически, благодаря внутренней системе биллинга, падают на конкретный проект. С точностью до копейки. Не больше, не меньше. Причем с учетом простоя, то есть если ты останавливаешь виртуалку на какое-то время, то и не платишь. Конечно, небо и земля, по сравнению с тем, как это было раньше, когда все затраты лаборатории каким-то магическим и совершенно непрозрачным образом распределялись по департаментам, направлениям, группам.
Масштабирование
Обычно делается очень просто. Есть предопределенные блоки: автоматизация охватывет инфраструктурный уровень. Все, по большей части, решается установкой дополнительных юнитов в стойки в случае чего. Если задача не очень большая — то скорее всего допоставка серверов, систем хранения, связка воедино. Если крупная — развертывание еще фермы и организация связи между ними. Соответственно, легко строить прогнозы вроде «в следующем году у нас будет на 30% больше пользователей, вот расходы».
Архитектура
На высоком уровне она общая, одинаковая для ряда производителей. Дальше выбираются конкретные решения как из коммерческих так и из опенсорсных реализаций, идет диалог о деталях, железе и так далее. Определяем, какие функции исполняет какой компонент какого производителя.
Вот про управление:
ПРИМЕР АРХИТЕКТУРЫ НА ПЛАТФОРМЕ BMC CLOUD LIFECYCLE MANAGEMENT
ПРИМЕР АРХИТЕКТУРЫ НА ПЛАТФОРМЕ IBM CLOUD SERVICE PROVIDER PLATFORM (CSP2)
ПРИМЕР АРХИТЕКТУРЫ НА ПЛАТФОРМЕ CA AUTOMATION SUITE FOR CLOUD
Схема с общими составляющими инфраструктуры частного «облака»
Переход к гибридам и публичным «облакам»
В своем частном «облаке» заказчики часто оттачивают механизм оказания сервисов. Затем, когда они понимают чувствительность данных, они уже спокойно могут использовать облака партнеров, гибриды или публичные. Например, банки отрабатывают важные данные в своей собственной безопасной среде — у них появляются навыки, новые процедуры безопасности, автоматизация и так далее. Когда становится понятно, что нужны новые ресурсы, и в целом их использование не является угрозой ИБ, используются ресурсы публичных облаков — это просто дешевле, чем разворачивать еще ферму внутри себя.
Вопросы
Все. Я готов ответить на ваши вопросы в комментариях или в почте IShumovskiy@croc.ru. Если это требуется, могу прислать примерные расчеты вариантов внедрений для вашей ситуации.
Если хотите больше практических деталей — завтра с 10:30 до 15:30 у нас в офисе пройдет семинар. Будем рассказывать в подробностях про архитектуру «облака» и «облачный» ITSM, про опыт переноса в частное «облако» услуги «service desk», про пред-биллинг и решения для учета ресурсов, о том, как управлять частными «облаками», какие решения для этого есть и что лучше выбрать в том или ином случае, в целом про аппаратные и системные решения, необходимые для развертывания частного «облака», про защиту «облачных» данных и еще много всяких полезностей. Будет и специальный гость из Forrester — Лорен И. Нельсон, аналитик по работе со специалистами в области ИТ-инфраструктуры и операций. Тоже обещает поделиться некоторыми секретами. В общем, приходите, это полезная ачивка. Зарегистрироваться на бесплатное участие можно здесь.