Дмитрий Карасев: Как правильно подходить к разработке облачных стратегий
01.10.24, Вт, 10:58, Мск,
Сегодня в интервью мы погружаемся в одну из самых динамично развивающихся областей современной IT-инфраструктуры — облачные технологии. Дмитрий Карасев, эксперт в продуктовой разработке с многолетним опытом в построении облачных решений, расскажет о том, как правильно подходить к разработке облачных стратегий, преодолевать вызовы интеграции и масштабирования и находить оптимальные решения для сложных IT-ландшафтов. Мы обсудим реалии мультиоблачных сред, миграцию крупных организаций в облако, а также тонкости обеспечения безопасности данных в глобальных условиях.
1. Разработка облачной стратегии для компании с глобальным присутствием требует учета множества факторов, включая региональные особенности, требования безопасности и локализацию данных. Как вы подходите к разработке таких стратегий и какие аспекты считаете наиболее важными?
В моей карьере одним из наиболее значимых проектов по разработке и внедрению облачных стратегий стало участие в создании государственной единой облачной платформы (ГЕОП) в рамках моей работы в «Ростелеком». Этот проект был инициирован для обеспечения информационной безопасности и надежного функционирования информационных ресурсов органов государственной власти и государственных учреждений.
Проект «ГосОблако» возник как ответ на несколько ключевых проблем, с которыми сталкивались государственные ведомства. Основные из них включали:
- Непредсказуемость затрат на инфраструктуру: Ранее каждое ведомство реализовывало свою собственную инфраструктуру, что приводило к неконтролируемому росту расходов.
- Медленное масштабирование: Любое увеличение ресурсов требовало новых проектов, бюджетов и значительных сроков на проектирование и пуско-наладочные работы.
- Разнородность решений: Индивидуальные проекты без стандартизированного подхода повышали вероятность появления неучтенных недостатков в информационной безопасности.
- Большие капитальные вложения: Ведомства вынуждены были делать крупные единовременные инвестиции (CAPEX), что создавало дополнительные финансовые нагрузки.
Реализация проекта «ГосОблако» была важной как для «Ростелеком», так и для государства. Для компании это был стабильный источник выручки, а для заказчика — возможность получить стандартизованный набор услуг с прогнозируемой стоимостью и быстрой масштабируемостью, а также перевести капитальные затраты в операционные (CAPEX -> OPEX).Как DevOps-сервис помогает «разгрузить» высоконагруженные системы BPMSoft
Проект «ГосОблако» стал первопроходцем на рынке облачных решений для государственного сектора. Он позволил перевести модель потребления инфраструктуры с капитальных затрат на операционные, снизив при этом общие расходы на IT. Кроме того, проект принес «Ростелеком» стабильный поток контрактов на общую сумму нескольких миллиардов рублей за период 2020-2022 годов.
2. В последние годы мультиоблачные стратегии стали ключевым элементом IT-инфраструктуры многих компаний. Переход на использование нескольких облачных платформ помогает организациям снизить риски, повысить гибкость и избежать зависимости от одного поставщика услуг. Можете рассказать, как вы внедряли мультиоблачные среды и с какими задачами сталкивались?
Переход на мультиоблачную среду, в моем опыте, чаще всего возникает как результат естественного эволюционного процесса, а не исключительно стратегического решения. Например, многие компании сталкиваются с мультиоблачностью после слияний или приобретений, когда новые подразделения приносят с собой свои собственные облачные системы. В таких случаях отказ от уже работающих платформ не всегда целесообразен из-за высокой стоимости и сложности полного перехода.
Я также наблюдал ситуации, когда мультиоблачные среды появляются из-за автономии внутренних подразделений, которые имеют полномочия самостоятельно выбирать поставщиков. В крупных организациях это приводит к разнородности инфраструктуры, что может быть одновременно и вызовом, и преимуществом. Например, некоторые команды предпочитают работать с AWS из-за глубокой интеграции с их внутренними приложениями, в то время как другие выбирают Azure, находя там специфические функциональные возможности, недоступные у других провайдеров.
Конечно, мультиоблачность обещает свободу от «запертости» на одного провайдера. Однако создание уровня абстракции для работы сразу с несколькими облаками — задача, требующая значительных ресурсов и разработческих усилий. В таких случаях мы стремимся минимизировать сложности путем использования инструментов управления мультиоблачной средой, которые помогают стандартизировать процессы и упрощают администрирование ресурсов.
Ключевым аспектом для меня всегда является баланс между гибкостью и оптимизацией затрат. Мультиоблачные архитектуры могут действительно стать эффективным решением для повышения отказоустойчивости и обеспечения непрерывности бизнеса. Однако не всегда оправдано поддерживать полный набор независимых от провайдера функций, особенно когда это ограничивает доступ к уникальным возможностям отдельных облаков и требует серьезных инвестиций в разработку и эксплуатацию.
3. Миграция крупных организаций в облако часто сопряжена с множеством технических и организационных трудностей. Важно учитывать как существующие бизнес-процессы, так и технологическую инфраструктуру компании. Можете поделиться опытом, как вы проводили подобные миграции и какие стратегии использовали?
Миграция крупных компаний в облако действительно сопряжена с множеством технических и организационных вызовов, так как необходимо учесть весь существующий стек технологий и бизнес-процессы. В своей практике я использую поэтапный подход, чтобы минимизировать риски и обеспечить стабильность на каждом этапе.
На первом этапе мы проводим оценку текущей инфраструктуры и бизнес-процессов, чтобы понять, какие приложения и данные имеют ключевое значение и какие можно безопасно перенести в облако. Это позволяет оценить, какие технологии и архитектурные изменения потребуются для успешной миграции. Мы также формируем команду для управления изменениями, поскольку миграция требует координации между разными отделами и вовлечения всех заинтересованных сторон.
На втором этапе происходит проектирование архитектуры миграции. Здесь часто применяю подход «Lift and Shift» для начальных этапов, чтобы быстрее и с меньшими затратами перенести рабочие нагрузки в облако. Позднее, когда критические компоненты системы уже находятся в облаке, начинается этап рефакторинга приложений, их адаптация под облачные возможности. Примером адаптации можно назвать перевод монолитных приложений в микросервисную архитектуру и контейнеризированные среды, что позволяет воспользоваться автомасштабированием и повысить производительность в облаке.
На заключительном этапе фокус на оптимизации и мониторинге. Мы используем специализированные инструменты для отслеживания производительности и затрат, чтобы минимизировать расходы на облачные ресурсы и выявить узкие места. Также проводим обучение сотрудников, чтобы они могли эффективно работать в новой среде и понимать, как использовать облачные сервисы для поддержки своих задач.
4. Интеграция облачных решений с существующей IT-инфраструктурой — сложная задача, требующая глубокого понимания как облачных технологий, так и текущих систем компании. Важно сохранить целостность бизнес-процессов и обеспечить их бесшовное взаимодействие. Как вы подходите к решению этой задачи?
Интеграция облачных технологий с существующей IT-инфраструктурой требует подхода, который сохраняет целостность и непрерывность бизнес-процессов. Ключом к успешной интеграции для меня всегда является глубокий анализ текущей инфраструктуры и детальное планирование.
Для бесшовной интеграции мы сначала выделяем ключевые точки взаимодействия между локальной инфраструктурой и облачной средой. Например, при интеграции с локальными базами данных или ERP-системами мы применяем гибридную архитектуру, которая позволяет использовать как облачные, так и локальные ресурсы. Это может быть полезно, когда полная миграция в облако невозможна или экономически нецелесообразна.
Также применяем промежуточные решения, такие как API-шлюзы и системы управления идентификацией, чтобы обеспечить единый уровень доступа и безопасность. Это позволяет сохранять контроль над доступом и управлением данными, а также упрощает интеграцию приложений с облачными сервисами. Использование микросервисной архитектуры в облаке также помогает повысить гибкость и масштабируемость, обеспечивая быстрый доступ к функциям и данным из любых точек компании.
Кроме того, критически важен мониторинг. Грамотно выстроенный мониторинг это не только дашборды и системы алертинга. Для того чтобы это все работало, необходимо выстроить систему метрик, источников и критериев. Все вместе они позволяют оперативно выявлять и решать проблемы производительности, обеспечивая высокую доступность и надежность системы.
Облачные технологии стали не просто инструментом — они трансформируют подход к управлению бизнесом и развивают целые индустрии. Миграция в облако меняет структуру взаимодействия между IT и бизнесом: она требует пересмотра устоявшихся процессов, повышает гибкость и позволяет организациям быть более адаптивными к изменениям внешней среды. Однако главное, что облачные технологии заставляют нас переосмысливать границы традиционной инфраструктуры. Они стирают понятие статичности, позволяя бизнесу быстрее расти и адаптироваться к вызовам. Облако — это не цель, а средство для постоянного улучшения, и, чем оптимальнее компании смогут встроить его в свою стратегию, тем увереннее они будут чувствовать себя в условиях постоянных перемен. Спасибо за возможность поделиться этим опытом.
Автор: Николай Бородин