Для клиентов ЦОД / Полезные советы / Что можно и что нельзя переносить в облако

Что можно и что нельзя переносить в облако

Лучшее время для миграции в облако – это миграция приложений. Вам не нужно перепрограммировать какое-либо из приложений или рабочую нагрузку, чтобы «поместиться» в облако. Если оно работает, зачем же мигрировать? Давайте предположим, что Ваша компания находится в стадии смены платформ для некоторого количества приложений и Вы сейчас раздумываете над тем, стоит ли перенести их в облако. Далее мы приведем несколько основных моментов, которые стоит учесть в подобной ситуации и которые помогут Вам принять это решение.

Что остается, а что мигрирует в облако

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

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

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

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

Когда мигрировать не стоит

Естественно, если некоторые приложения или рабочие нагрузки не подходят для миграции в облако – или же наоборот, то это не значит, что Вы не сможете вернуться к этому вопросу в дальнейшей перспективе. К примеру, Вашему бизнесу необходимы значительные объемы памяти, и в какой-то момент облачный провайдер (допустим, Amazon Web Services) объявляет о новой и более дешевой услуге хранения данных, которая сделает переход в облако для Вас более доступным и будет отвечать Вашим требованиям по безопасности и длительности хранения данных.

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

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