Почему компании отказываются от использования облаков

Андрей Ардашев, ИТ-аналитик, разработчик решений DirectumRX

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

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

Почему компании отказываются от использования облаков?

Высокая стоимость и регулярные платежи

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

Изменение инфраструктуры компании

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

Работа с облаком через третьих лиц

Зачастую облачные провайдеры распространяют свои услуги (облачные приложения) через партнерскую сеть. Бывают случаи, когда партнеры берут поддержку заказчика на себя, выступая первой линией поддержки. В этом случае решение любого сложного вопроса растягивается по времени, поскольку у партнера и провайдера есть собственный SLA (Service Level Agreement), и для конечного заказчика время на решение вопроса суммируется.

А мы создадим своё облако!

Некоторые заказчики поддаются искушению реализовать собственное облако с необходимыми сервисами на базе частного облака уровня PaaS или IaaS. Однако все бизнес-приложения требуют регулярного администрирования и мониторинга. И получить выгоду от «облачности», которая как раз заключается в снижении расходов на администрирование, не удается.

Чтобы реализовать продуктивную поддержку облачного сервиса необходимо выделить команду по крайней мере из четырёх специалистов:

● два системных инженера, которые будут обслуживать облачную платформу и сервисные службы бизнес-приложения;

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

При большом количестве пользователей (от 200 и выше) потребуется пропорциональное увеличение числа специалистов второй линии.

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

Задачи, которые решает частное и гибридное облако

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

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

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

● интеграция в инфраструктуру: интеграция в домен, технология единого входа (Single Sign-On, SSO);

● интеграция с информационными системами заказчика;

● работа с большим объемом данных;

● особые требования к безопасности (хранение персональных данных, реализация классов защищенности в соответствии с законом);

● необходимость реализации гибридного облака.

Варианты инфраструктуры частного и гибридного облака

Ниже представлены варианты инфраструктур частого и гибридного облака, которые чаще всего рассматриваются заказчиками, при анализе использования «гибрида».

Частное облако для территориально распределенной компании с разными доменами

Довольно часто встречается ситуация, когда крупные подразделения компании территориально распределены и используют различные домены для обеспечения аутентификации. Вторым частым условием таких организаций является соответствие облачного сервера стандартам безопасности компании. В таком случае наиболее удобным является вариант, схема которого представлена выше. Облачный сервер на частном облаке может быть включён в сеть и в домен организации через VPN-соединение (для облака на платформе VMWare Cloud поддерживается технология VPN IPSec). Для того чтобы пользователи остальных доменов могли получать доступ к облачному серверу со своей доменной учетной записью, необходимо, чтобы между доменами пользователей и доменом, в котором включён облачный сервер, было настроено доверие (Active Directory Trust).

Гибридное облако для компании с объединенной аутентификацией с использованием службы федерации Active Directory и интеграцией с какой-либо внешней облачной учетной системой.

При работе с частным и публичным облаком заказчики предпочитают использовать объединенной аутентификацию, с помощью которой можно получать доступ ко всем сервисам предприятия (SSO). На рисунке выше продемонстрирована такая аутентификация с использованием сервиса ADFS, к которому подключён второй фактор для усиления защиты. При выполнении аутентификации пользователь аутентифицируется на сервисе ADFS, проходит проверку по второму фактору (sms- или email-сообщение, специальные вопросы и пр.), только после этих проверок пользователь сможет получить доступ к информационным ресурсам компании, в том числе к ресурсам частного облака.

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

На что нужно обратить внимание

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

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

1. Необходимо определить, по каким причинам не может быть использовано публичное облако.

Основные причины:

● специфические требования к безопасности (способ аутентификации);

● интеграция с внешними информационными системами;

● специфические условия хранения данных (способ хранения, место хранения, объём хранилища);

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

2. Необходимо четко понимать реализуемую задачу.

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

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

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

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

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

● партиционирование таблиц баз данных (вынесение части базы данных на скоростные носители, распараллеливание нагрузки по разным носителям);

● распараллеливание нагрузки на сервисные службы приложения;

● перенос части нагрузки на внешние сервисы (внешние бизнес-приложения, сервисы хранилищ и пр.);

● Разработка сервисов интеграции между частным и публичным облаком.

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

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

Заключение

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

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

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