Второй пост из серии авторских текстов Михаила Михеева "Как приручить облака: примеры практического использования".
В первом посте я упоминал об основных плюсах облачной инфраструктуры, и обещал рассказать про минусы.
Сначала повторим плюсы:
Проблема 1: зависимость от канала связи.
Упал интернет между нами и ЦОДом облака – все. Тушите свет.
Почему эта проблема не очень страшна:
Проблема 2: зависимость доступности нашей инфраструктуры от персонала хостера. Вдруг они наняли студентов, которые ничего не зная и не умея убьют наши виртуалки?!
Нестрашность этой проблемы обосновать, наверное, легче всего. Бизнес сервис-провайдера корпоративного облака это доступность и еще раз доступность, любой простой — это потеря репутации и денег в виде штрафов, поэтому уровень мотивации в организации качества услуг существенно выше чем у внутренней службы ИТ.
Проблема 3: зависимость от глобальных проблем хостера. А что если, например, к ним придут и унесут все железо?
Тут нужно смотреть на конкретного сервис провайдера облачных услуг. Где он разместил свое оборудование, какой уровень физической безопасности дата-центра, есть например площадки куда и с решением суда не просто попасть. В частности облака ИТ-ГРАДа находятся именно в такой ЦОДе.
Проблема 4: не любое ПО заработает в виртуальной машине.
Если программа требует только процессор, память, диски, сеть, простейшую видеокарту и usb для периферии – все ок. Иначе – иначе. Грустно, но это так. С другой стороны, с этим легко можно не согласиться. «С этим» в смысле что это проблема. Серверных приложений, которым недостаточно того, что дают современные виртуальные сервера – мало. А старых приложений, которые сегодня не заработают нигде, кроме виртуальных серверов – как раз можно найти. К примеру, из опыта наших заказчиков — на данный момент, только благодаря средствам виртуализации VMware можно продолжать эксплуатировать ПО, которое работает, например, только по Windows 3.1.
Проблема 5: конфиденциальность данных – их админы могут получить доступ к нашей информации.
По уму, эту проблему стоит переформулировать: «Мы не хотим, чтобы конфиденциальность стала хуже после переноса сервисов из нашей серверной во внешний ЦОД».Далее ситуация разветвляется:а) или мы говорим о чувствительных данных, и говорим о конфиденциальности профессиональноб) или мы говорим в общем, и не профессионально.Первый случай – предмет отдельного обсуждения, итог которого можно втиснуть в рамки твита: «Действительно критичные с точки зрения конфиденциальности сервисы наружу не выносятся».А вот во втором случае – актуальном для большинства сервисов большинства компаний – остановимся чуть подробнее. Вопрос: "А сейчас у вас как с конфиденциальностью?" Ответ: "Как-то так?"Или вы можете дать более внятный ответ? Назначены ли ответственные люди? Приняты ли правовые, технические, организационные и психологические меры? Если ответ «нет», это значит что от администраторов внутренних компания не защищена никак, а вот с юрлицом – облакопровайдером – эта область может быть регламентирована намного, намного лучше.
Вопрос: «После переноса сервисов в облако, станет ли хуже ситуация с конфиденциальностью наших данных?»
Ответ: «Нет. Мы бы сказали, что станет лучше»Помните, в начале я написал фразу «Действительно критичные с точки зрения конфиденциальности сервисы наружу не выносятся»? Она не совсем корректна. Сегодня уже появляются специализированные для vSphere средства обеспечения безопасности, и под конкретные проекты они могут применяться, и применяться успешно. На текущий момент речь идет, преимущественно, о продуктах компании «Код Безопасности». Я к тому, что при экономических и\или прочих плюсах задействования внешнего облака под проект от идеи ни в коем случае не нужно отказываться из за наличия чувствительных данных – стоит поднять этот вопрос, изучить возможности и, часто, увидеть что с помощью специальных инструментов достаточный уровень конфиденциальности реализуем.Первый пост был посвящен введению в вопрос, были описаны плюсы в общем виде, и была поставлена задача – для иллюстрации возможностей. Сейчас мы поговорили о проблемах – и об их решении. Дальше мы вернемся к поставленной задаче – ведь надо ее решить...
В первом посте я упоминал об основных плюсах облачной инфраструктуры, и обещал рассказать про минусы.
Сначала повторим плюсы:
- Нет необходимости вкладываться в приобретение железа, софта, внедрение всего этого.
- Кардинальное сокращение затрат времени до начала работы.
Хорошая цитата:
Облака и ERPпродолжение в первоисточнике
Какие преимущества можно получить от использования “облаков” в процессе внедрения ERP системы. Команда внедрения приезжала и приблизительно оценивала потребности в железе – очень грубо оценивала. Дальше ИТ отдел заказчика начинал поиск под эту систему сервера (выбирали производителя, марку, договаривались о поставке). Чаще всего сервер приезжал не быстрее, чем через 2-4 недели, но нередко можно было ждать и пару месяцев. Параллельно решались вопросы с работой удаленных подразделений – или централизованный сервер и каналы связи, или варианты с распределенными базами (которые тоже требуют каналов связи). В то время, пока ждали сервер, система настраивалась или на некоем временном сервере (который уже старый, но еще жаль выбрасывать) или на компьютерах внедренцев (NAV и 1С живут на ноутбуке легко, Axapta с трудом, но тоже может работать – речь про OEBS или SAP не идет – рассматриваем внедрение в мелких или средних фирмах). Дальше два варианта – сервер есть к моменту запуска системы или его еще нет. Если есть, то после приезда сервера начинается процедура установки ОС и ERP, и выполняется настройка и перенос настроек (почти всегда требуется приезд ИТ-специалиста фирмы-внедренца). И дальше уже все настраивается на будущем рабочем сервере. Если еще нет, то система запускается на старом сервере, и через некоторое время, когда приезжает сервер, выполняется перенос (перенос работающей системы – удовольствие ниже среднего). До этого времени есть тормоза и прочие прелести старого железа. Также при начале работы у фирм, где есть удаленные подразделения, начинались различные проблемы, связанные с работой удаленных подразделений. Например, самая распространенная проблема – настройка принтеров при терминальном доступе к серверу. Кроме этого, различные глюки при настройке VPN и т.д. и т.п. – проблемы есть почти всегда. Разумеется, через некоторое время они решаются, но нервы помотают. Ну и в самом конце, примерно через полгода промышленной эксплуатации, выясняется фактическая нагрузка на железо. И в 99,9% случаев обнаруживается одно из трех – или сервер излишне мощный и не используется и на 25% (в пиковых нагрузках до 50%), или сервер в целом слабый и нужна более мощная модель, или не оптимальное соотношение процессор / память / дисковая подсистема (что-то мощнее, чем нужно, а чего то не хватает). Каким может быть аналогичный проект сейчас при использовании облаков (сloud computing)? (Как пишется в титрах некоторых фильмов, сюжет основан на реальных событиях )) …
- Сокращение (не увеличение) затрат на обслуживание (зп админов). Обслуживать не надо инфраструктуру нижнего уровня (серверное железо, системы хранения данных, сетевую инфраструктуру, ПО, которое можно назвать низкоуровневым – vSphere, брандмауэры, NAT и некоторые другие системы.
- Отсутствие проблем с выбором конфигурации – уменьшить или увеличить выделенные приложению (ВМ) ресурсы тривиально.
- Задешево обеспечение высокой доступности – банальные неприятности типа отказа железки (будь то железка серверной инфраструктуры, сети или системы хранения) не приводит к длительному простою (в каких-то случаях даже минимального простоя нет). Этот плюс, на самом деле, входит в однерку лидеров хит-парада причин выбрать облачную инфраструктуру.
- Зависимость от канала связи.
- Зависимость от чужих студентов, админящих инфраструктуру.
- Зависимость от глобальных сбоев хостера (маски шоу, как самый популярный по некоторым данным disaster в наших широтах).
- Не любое ПО заработает в виртуальной машине.
- Конфиденциальность данных – лидер хит-парада страшилок.
Проблема 1: зависимость от канала связи.
Упал интернет между нами и ЦОДом облака – все. Тушите свет.
Почему эта проблема не очень страшна:
- канал падает, обычно, не часто. Впрочем, вероятность этого события для своей компании вы можете оценить и сами;
- канал поддается резервированию, обычно;
- если канал упал на нашей стороне (обычно падает не в ЦОДе облака и не у его провайдеров) – нормальная работа современной компании не возможна так и так. От вынесения части сервисов в облако хуже не будет, если это предположение верно для вашей компании. Более того, если к части сервисов обращаются извне (например, веб или почтовые сервера), вынос их во внешнее облако позволит получить большую доступность для внешних клиентов этих сервисов.
Проблема 2: зависимость доступности нашей инфраструктуры от персонала хостера. Вдруг они наняли студентов, которые ничего не зная и не умея убьют наши виртуалки?!
Нестрашность этой проблемы обосновать, наверное, легче всего. Бизнес сервис-провайдера корпоративного облака это доступность и еще раз доступность, любой простой — это потеря репутации и денег в виде штрафов, поэтому уровень мотивации в организации качества услуг существенно выше чем у внутренней службы ИТ.
Проблема 3: зависимость от глобальных проблем хостера. А что если, например, к ним придут и унесут все железо?
Тут нужно смотреть на конкретного сервис провайдера облачных услуг. Где он разместил свое оборудование, какой уровень физической безопасности дата-центра, есть например площадки куда и с решением суда не просто попасть. В частности облака ИТ-ГРАДа находятся именно в такой ЦОДе.
Проблема 4: не любое ПО заработает в виртуальной машине.
Если программа требует только процессор, память, диски, сеть, простейшую видеокарту и usb для периферии – все ок. Иначе – иначе. Грустно, но это так. С другой стороны, с этим легко можно не согласиться. «С этим» в смысле что это проблема. Серверных приложений, которым недостаточно того, что дают современные виртуальные сервера – мало. А старых приложений, которые сегодня не заработают нигде, кроме виртуальных серверов – как раз можно найти. К примеру, из опыта наших заказчиков — на данный момент, только благодаря средствам виртуализации VMware можно продолжать эксплуатировать ПО, которое работает, например, только по Windows 3.1.
Проблема 5: конфиденциальность данных – их админы могут получить доступ к нашей информации.
По уму, эту проблему стоит переформулировать: «Мы не хотим, чтобы конфиденциальность стала хуже после переноса сервисов из нашей серверной во внешний ЦОД».Далее ситуация разветвляется:а) или мы говорим о чувствительных данных, и говорим о конфиденциальности профессиональноб) или мы говорим в общем, и не профессионально.Первый случай – предмет отдельного обсуждения, итог которого можно втиснуть в рамки твита: «Действительно критичные с точки зрения конфиденциальности сервисы наружу не выносятся».А вот во втором случае – актуальном для большинства сервисов большинства компаний – остановимся чуть подробнее. Вопрос: "А сейчас у вас как с конфиденциальностью?" Ответ: "Как-то так?"Или вы можете дать более внятный ответ? Назначены ли ответственные люди? Приняты ли правовые, технические, организационные и психологические меры? Если ответ «нет», это значит что от администраторов внутренних компания не защищена никак, а вот с юрлицом – облакопровайдером – эта область может быть регламентирована намного, намного лучше.
Резюмируем
Вопрос: «После переноса сервисов в облако, станет ли хуже ситуация с конфиденциальностью наших данных?»
Ответ: «Нет. Мы бы сказали, что станет лучше»Помните, в начале я написал фразу «Действительно критичные с точки зрения конфиденциальности сервисы наружу не выносятся»? Она не совсем корректна. Сегодня уже появляются специализированные для vSphere средства обеспечения безопасности, и под конкретные проекты они могут применяться, и применяться успешно. На текущий момент речь идет, преимущественно, о продуктах компании «Код Безопасности». Я к тому, что при экономических и\или прочих плюсах задействования внешнего облака под проект от идеи ни в коем случае не нужно отказываться из за наличия чувствительных данных – стоит поднять этот вопрос, изучить возможности и, часто, увидеть что с помощью специальных инструментов достаточный уровень конфиденциальности реализуем.Первый пост был посвящен введению в вопрос, были описаны плюсы в общем виде, и была поставлена задача – для иллюстрации возможностей. Сейчас мы поговорили о проблемах – и об их решении. Дальше мы вернемся к поставленной задаче – ведь надо ее решить...
