Дмитрий Карасев: Как правильно подходить к разработке облачных стратегий

01.10.24, Вт, 10:58, Мск,

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

Дмитрий Карасев

1. Разработка облачной стратегии для компании с глобальным присутствием требует учета множества факторов, включая региональные особенности, требования безопасности и локализацию данных. Как вы подходите к разработке таких стратегий и какие аспекты считаете наиболее важными?

В моей карьере одним из наиболее значимых проектов по разработке и внедрению облачных стратегий стало участие в создании государственной единой облачной платформы (ГЕОП) в рамках моей работы в «Ростелеком». Этот проект был инициирован для обеспечения информационной безопасности и надежного функционирования информационных ресурсов органов государственной власти и государственных учреждений.

Проект «ГосОблако» возник как ответ на несколько ключевых проблем, с которыми сталкивались государственные ведомства. Основные из них включали:

  • Непредсказуемость затрат на инфраструктуру: Ранее каждое ведомство реализовывало свою собственную инфраструктуру, что приводило к неконтролируемому росту расходов.
  • Медленное масштабирование: Любое увеличение ресурсов требовало новых проектов, бюджетов и значительных сроков на проектирование и пуско-наладочные работы.
  • Разнородность решений: Индивидуальные проекты без стандартизированного подхода повышали вероятность появления неучтенных недостатков в информационной безопасности.
  • Большие капитальные вложения: Ведомства вынуждены были делать крупные единовременные инвестиции (CAPEX), что создавало дополнительные финансовые нагрузки.

Реализация проекта «ГосОблако» была важной как для «Ростелеком», так и для государства. Для компании это был стабильный источник выручки, а для заказчика — возможность получить стандартизованный набор услуг с прогнозируемой стоимостью и быстрой масштабируемостью, а также перевести капитальные затраты в операционные (CAPEX -> OPEX).Как с помощью EvaProject и EvaWiki построить прозрачную бесшовную среду для успешной работы крупного холдинга 2.2 т

Проект «ГосОблако» стал первопроходцем на рынке облачных решений для государственного сектора. Он позволил перевести модель потребления инфраструктуры с капитальных затрат на операционные, снизив при этом общие расходы на IT. Кроме того, проект принес «Ростелеком» стабильный поток контрактов на общую сумму нескольких миллиардов рублей за период 2020-2022 годов.

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

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

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

Конечно, мультиоблачность обещает свободу от «запертости» на одного провайдера. Однако создание уровня абстракции для работы сразу с несколькими облаками — задача, требующая значительных ресурсов и разработческих усилий. В таких случаях мы стремимся минимизировать сложности путем использования инструментов управления мультиоблачной средой, которые помогают стандартизировать процессы и упрощают администрирование ресурсов.

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

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

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

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

На втором этапе происходит проектирование архитектуры миграции. Здесь часто применяю подход «Lift and Shift» для начальных этапов, чтобы быстрее и с меньшими затратами перенести рабочие нагрузки в облако. Позднее, когда критические компоненты системы уже находятся в облаке, начинается этап рефакторинга приложений, их адаптация под облачные возможности. Примером адаптации можно назвать перевод монолитных приложений в микросервисную архитектуру и контейнеризированные среды, что позволяет воспользоваться автомасштабированием и повысить производительность в облаке.

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

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

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

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

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

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

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

Автор: Николай Бородин