noun_Email_707352 noun_917542_cc noun_Globe_1168332 Map point Play Untitled Retweet

Переход к облачным сервисам

Мы расскажем про особенности перехода на облако, а также о том, какое облачное решение выбрать.

Елизавета Боброва / августа 05, 2021
Задать вопрос

В последнее время компании все чаще становятся перед выбором: перейти на облачные сервисы или остаться on-premise.

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

При on-premise подходе компания содержит свое специально выделенное для этого помещение, а также вынуждена поддерживать сложную инфраструктуру для корректной работы: осуществлять постоянную модернизацию оборудования и оперативно заменять вышедшее из строя «железо». Инфраструктура состоит из: специализированного помещения, оборудованного всем необходимым (системы вентиляции и пожаротушения, системы контроля доступа, видеонаблюдение и т. п.), непосредственно серверное и сетевое оборудование. На серверах установлены операционные системы, на которых установлены компоненты (среды виртуализации, базы данных, web-сервера и т. п.), которые в свою очередь используются приложениями. Как правило, в on-premise используется классическая архитектура с виртуальными машинами, установленными на них инфраструктурными компонентами и приложениями, в то время как микросервисная архитектура практически не реализуется.

Плюсами работы с on-premise можно назвать наличие собственных ресурсов, оборудования, низкая зависимость от ширины и качества Интернет-каналов, а также свой собственный контроль за безопасностью, при условии того, что инфраструктура построена по всем требованиям безопасности, отказоустойчивости и отвечает всем стандартам современного ЦОДа. Но, с другой стороны, при классической архитектуре, которая свойственна on-premise, компания, как правило, расходует ресурсы не оптимально, многие из них остаются незадействованными. Также в том случае, если пользователи потребляют ресурсы нелинейно, компании необходимы дополнительные мощности, чтобы выдержать дополнительную пиковую нагрузку. Для этого потребуется постоянно содержать избыточные мощности, которые редко будут использоваться, или наоборот, ресурсов будет постоянно не хватать, что сильно скажется на бизнес деятельности компании. Еще одним из минусов on-premise является необходимость иметь специальное помещение, в котором потребуется поддерживать особый температурный режим и работающую систему кондиционирования, пожаротушения, контроля доступа, а также иметь варианты альтернативных источников электроснабжения, организовать систему резервного восстановления в случае крупного сбоя.

Говоря о плюсах облачных решений, самым очевидным является отсутствие необходимости содержать помещение и бОльшую часть инфраструктуры. Но самым важным преимуществом облака является быстрая масштабируемость и гибкость в выборе доступных технологических решений, а также наличие PaaS сервисов. Подход Infrastructure-as-a-code поможет описать инфраструктуру кодом и развернуть необходимые ресурсы одномоментно вне зависимости от их количества – это может быть 10 или 1000 инстансов, достаточно лишь будет поменять пару переменных в коде. Это и позволяет добиться масштабируемости. Более того, можно применить инструменты авто-масштабирования (autoscaling) и автовосстановления (autohealing), когда при необходимости инфраструктура будет автоматически подстраиваться под нужды вашего бизнеса, потребляя ресурсов столько, сколько необходимо в конкретное время. В случае сбоев, благодаря процедурам autohealing, инфраструктура будет «чинить сама себя». Помимо удобства и скорости такого подхода, плюсом будет экономия средств: платить приходится только за те услуги, которые по факту используются, благодаря подходу pay as you go.

Очень важно помнить, что чтобы добиться подобных результатов, при переходе в облако часто необходимо изменение архитектуры приложения – переход от классического подхода с виртуальными машинами в сторону cloud native, когда приложение работает на микросервисной архитектуре и поддерживает контейнеризацию . В любом публичном облаке пользователю доступны PaaS сервисы, такие как DBaaS (database-as-a-service), Kubernetes-as-a-service и др., которые позволяют разворачивать приложение, не фокусируясь на классических инфраструктурных компонентах.

Следующей ступенькой развития является переход на multicloud. Такой подход позволяет взять от каждого типа размещения данных самое лучшее. К примеру, для хранения чувствительных бизнес-данных можно использовать своё частное облако, для хранения персональных данных можно использовать облачных провайдеров с ЦОДами на территории РФ, для big data или для хостинга самого приложения – публичные облака (Azure, AWS, Google). Однако, путь к multicloud довольно трудный и долгий.

Говоря о выборе страны происхождения облачных сервисов, у многих компаний возникает вопрос, какое облако выбрать: российское или зарубежное. В первую очередь при выборе важно опираться на наличие персональных данных. Если они есть, то в зарубежное публичное облако вход с ними закрыт из-за закона о персональных данных. Чтобы все же выйти в зарубежное облако, потребуется multicloud: персональные данные хранить в России, а остальное вынести, например, в AWS или Azure, или перейти на гибридный тип хранения: персональные данные хранить в on-premise, а остальное – в облаке. Рассматривая разницу между зарубежными и российскими частными облаками, критичной разницы между ними нет, однако стоит рассматривать каждое облако в частности, поскольку в зависимости от конкретного провайдера ситуация может меняться. А если мы говорим о публичных облаках, то здесь ситуация совершенно другая. Такие облачные сервисы как AWS, Google и Azure пока не имеют конкурентов в России.

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

 

P.S. Огромную благодарность за помощь в написании статьи выражаем директору Cloud&Infra TietoEVRY в России Александру Колесову.

Елизавета Боброва
Офис-менеджер
Поделиться в Facebook Твит Поделиться в LinkedIn