У большинства компаний адаптация к облачным сервисам и платформам происходит поэтапно. Команда Linx Cloud благодаря совмещению в компании функций и ЦОД, и облачного провайдера годами наблюдает за трансформацией ИТ-ландшафта клиентов и нашла закономерности в этом процессе, рассказывает руководитель направления облачных продуктов и решений Linx Cloud Олег Федоров.
С одной стороны, облака играют важнейшую роль для крупного бизнеса. Потребности компаний растут, а практически все современные сервисы связаны с облачными вычислениями. Санкции и ограничение технической поддержки со стороны западных вендоров создали дополнительный стимул для поиска альтернативных решений.
С другой стороны, использование облачной инфраструктуры еще не стало общепринятой практикой. В марте 2023 г. Cloud.ru опубликовал исследование «Облачная зрелость», для которого опросили более 650 компаний из разных отраслей.
По его результатам:
При этом доля российских компаний, использующих облачные сервисы, должна вырасти до 6% к 2025 г., а около 37% компаний, уже использующих облака, планируют увеличивать потребление ресурсов. Оба тренда следуют общемировой практике постепенного, но неуклонного отказа от on-premise инфраструктуры в пользу облачных решений.
В психологии традиционно выделяют пять стадий принятия неизбежного: отрицание, гнев, торг, депрессия, принятие. По аналогии можно также выделить три стадии принятия компанией облаков в своей инфраструктуре.
На старте процесс обычно идет в два этапа.
1.1 Вся инфраструктура on-premise, часть сервиса — в облако
Вся ИТ-инфраструктура бизнеса располагается локально, но возникает необходимость в ее реструктуризации. Обычно это связано со следующими задачами:
На помощь приходят облака. Компания совершает первое прикосновение к облачной инфраструктуре, перенося часть сервиса в облако. Проиллюстрируем на примере.
Клиент: крупная аудиторская компания. Вся ИТ-инфраструктура — on-premise, включая портал самообслуживания для клиентов компании, использующий корпоративные базы данных. Поддержка портала осуществлялась сторонней организацией, которой для этой цели требовался постоянный доступ во внутренний периметр инфраструктуры, что противоречило политике ИБ компании.
Задача: компании необходимо вывести портал самообслуживания из внутреннего периметра, чтобы обеспечить соблюдение требований ИБ.
Решение: мы предоставили облачные ресурсы и помогли организовать миграцию портала. Обеспечили связность удаленного сервера с остальной инфраструктурой без доступа сторонних лиц во внутренний периметр компании.
Второй этап — перенос в облако целого сервиса и передача управления им на аутсорсинг облачному провайдеру. Для клиента очень важна фиксация основных параметров услуг в договоре: их ключевых характеристик и гарантий доступности.
Клиент: один из крупнейших ритейлеров на российском рынке.
Задачи: заказчику требовалось наладить систему резервного копирования данных.
В ходе поиска решения на рынке и составления TCO-калькулятора компания пришла к выводу, что ей выгоднее получить данную услугу по модели «как сервис».
Решение: мы разработали регламент резервного копирования и построили выделенную инфраструктуру с учетом требований к RTO и RPO, обеспечив при этом срок хранения данных до 5 лет.
Центр управления резервным копированием (сервер с одним из репозиториев с подключенным неизменяемым S3-хранилищем), находящийся в нашей зоне ответственности, был размещен на площадке Linxdatacenter. Это позволило защитить данные от угроз, связанных с проникновением вирусов-вымогателей Ransomware. Для соблюдения RTO и RPO для критически важных систем на двух площадках заказчика были размещены локальные all-flash репозитории.
Заказчик на первой стадии получает хороший эффект от использования облачных сервисов, экономит на капитальных затратах, на времени, а также выигрывает в скорости масштабирования инфраструктуры.
Степень облачной зрелости компании растет. Мышление руководителей меняется от «Давай попробуем» до «А так можно было? Если один сервис успешно работает в облаке, значит, и остальные тоже могут?». На этой волне всю инфраструктуру или большинство сервисов переносят в частное облако.
Компания приходит к такой схеме: железо + виртуализация на аутсорс = частное облако.
Клиент: крупный интернет-магазин. Основная инфраструктура находилась on-premise на серверах заказчика. Частично за нее отвечали штатные сотрудники, частично — сторонняя компания на аутсорсе. Дополнительно ряд сервисов размещались в облаке. В итоге получался неконтролируемый «инфраструктурный винегрет» с размытыми границами ответственности.
Задачи: заказчику нужна была более прозрачная организация инфраструктура и гарантированная надежность ее работы.
Решение: мы предложили полную реорганизацию инфраструктуры компании на базе частного облака. В таких проектах важно заранее продумать топологию облачной инфраструктуры. Нужно обратить внимание не только на расчет необходимого количества вычислительных ресурсов, но и крайне ответственно подойти к вопросу построения сети. В вышеописанном кейсе топология сети проектировалась и настраивалась фактически с нуля, так как в исходной реализации было много изъянов.
При переходе к третьей стадии компания отдает большую часть инфраструктуры на аутсорс облачному провайдеру, к примеру, чтобы сфокусироваться на развитии внутренних сервисов.
Заказчик уже «попробовал облака на вкус». В какой-то момент он осознает, что это возможность неограниченного масштабирования при сокращении капитальных затрат.
Технологически частные и публичные облака похожи. Но в первом случае возможности масштабирования ограничены инсталляцией и на расширение может потребоваться несколько месяцев в связи с длительными сроками поставки оборудования. Если облако публичное, провайдер может по запросу выделить практически неограниченный объем ресурсов.
Поэтому последней стадией на пути принятия облачной инфраструктуры зачастую становится полный переход в публичное облако. В некоторых случаях это настоящее спасение и оптимальный способ обеспечить стремительный рост бизнеса за счет практически моментального удовлетворения потребностей в ИТ-сервисах.
Клиент: крупный производитель стройматериалов. Головная компания ушла с российского рынка и бросила «дочку», закрыв доступ к инфраструктуре в Европе.
Задача: заказчику было необходимо быстро развернуть инфраструктуру в России, при минимальной вовлеченности ИТ-персонала в проект.
Решение: так как клиент был заинтересован в том, чтобы полностью отдать инфраструктуру на аутсорс, оптимальным решением для него стало публичное облако. Мы перенесли инфраструктурные службы и ERP-систему на платформу Linx Cloud, взяв весь ИТ-ландшафт на техническую поддержку.
Таким образом, мы выделяем три стадии принятия облаков:
Наша концепция поэтапного перехода исключает стадии гнева и отрицания. Чтобы этап торга с облачным провайдером вызывал только приятные эмоции, нужно с самого начала проекта по адаптации облаков ориентироваться на провайдеров, готовых предоставлять кастомизированные решения под клиентские задачи.
Закажите консультацию специалиста