Облачный вопрос, часть 1-я

Добрый день, коллеги.
Наверное, данную статью не совсем технического толка, меня сподвигло написать количество одинаковых вопросов, поступающих от Заказчиков на тему: "Облака - как быть и что делать? И главное: как делать?".

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


ПРИМЕЧАНИЕ! Данная статья не есть руководство к действию и явно не основывается на Best Practice какого-либо производителя, а составляет квинтэссенцию моих знаний и опыта в данной теме. Я не даю конкретных методик технической миграции, а представляю некий концептуальный взгляд на проблему.


Разобьём данный трек на несколько разделов, а в самом конце рассмотрим пример.
Разделы будут следующими:

• Основные цели и Сценарии использования облака (общие архитектурные и не рассматривающие какие-либо конкретные технологии, такие как Windows Azure RemoteApp или SaaS, или PaaS решения);
• Принципы или варианты выбора порядка переноса сервисов в облако;
• Видение вопроса со стороны ИТ и бизнеса, задача постановки цели, Немного о SLA.

Начнём-с, постановка конечной цели и её параметров

 

Всё достаточно тривиально:

• Мы хотим сократить затраты ИТ;
• Мы хотим увеличить  или сохранить уровень доступности сервисов;
• Мы хотим снять с себя "ответственность" за некоторые технологические, природные риски или человеческий фактор.

Не стоит удивляться последнему пункту - это действительно так. 99,9% ИТ заинтересованы именно в последнем пункте. Включая вопрос: как избежать рисков, связанных с неуспешной миграцией;

Итак, что ж нам предложит облако, чтобы решить наши проблемы, и как выбрать что, и в каком порядке мигрировать?

Сценарии использования облака

Сценариев, по большому счёту, всего три:

• Полная централизация в облаке и отказ от инфраструктуры на локальных площадках;
• Гибридный сценарий с централизацией большинства сервисов в облаке;
• Гибридный сценарий в виде back-end с облаком (сюда же входят динамически масштабируемые сценарии  для периодически требующих высокой производительности сервисов).

Полная централизация в облаке и отказ от инфраструктуры на локальных площадках

Данный вариант подразумевает полный перенос сервисов из On-Prem в облако.

Подключение подразделений происходит по топологии Звезда с организацией дублирующих VPN каналов. Маршрутизация между Branch подразделениями через облако не предусматривается. 

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

Гибридный сценарий с централизацией большинства сервисов в облаке

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

 

 

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







Гибридный сценарий в виде back-end с облаком  

Данный вариант рассматривается в случае необходимости оставить большинство сервисов с общим пользованием всеми подразделениями в локальной инфраструктуре Компании.

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

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

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

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

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





 

Приоритезация переноса сервисов в облачную инфраструктуру
 

Существует несколько подходов по выбору приоритета переноса сервисов On-premises в облачную инфраструктуру, основанных на оценке:

• Неравенства Total Cost Ownership сервиса (TCO) в On-premises и в облаке (критерий: сокращение TCO сервиса);
• Обратно пропорциональном отношении соглашения об уровне обслуживания доступности сервиса и приоритета миграции (бизнес приоритет на доступность сервисов: вперёд мигрируют сервисы с более низким SLA);
• Соответствия технического решения облака требованиям к переносимым сервисам;
• Соответствие данных переносимых сервисов требованиям внутренней безопасности.



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

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

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

В обоих случаях, если рассматривается вариант не только о переносе сервиса AS IS, а о миграции в новую инфраструктуру (включая новую инфраструктуру службы каталогов – другой лес/домен), необходимо понимать, что несмотря на сокращение TCO к проекту добавляются существенные накладные расходы на осуществление процедуры миграции в новую среду службы каталогов, что может сильно утяжелить стоимость проекта. Естественно, всю разумность данных затрат мы должны понять, рассчитав ROI на приемлемый срок и увидеть в этом некий профит для себя.

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

 

Следует отметить, что любая централизация сервисов в облаке (Public, Private, Hybrid) налагает на Заказчика дополнительные расходы по организации бесперебойного доступа к облачной инфраструктуре посредством каналов сети Internet. Как следствие, предъявление высокого SLA к надёжности каналов влечёт за собой существенные капиталовложения в сетевую инфраструктуру сред On-Premises площадок Заказчика, так и каналы, предоставляемые ISP Заказчика.

Надеюсь данная информация позволила Вам получить некое видение процесса и сформировать концептуальный Road Map.

Спасибо и задавайте вопросы :D буду рад активному участию в дискуссии.