Подписаться
Читать в телеграм
Свой дата-центр vs публичное облако. Кто кого?
Варианты использования публичных облаков в корпоративном ИТ-ландшафте?
Что нужно учитывать при переносе приложения в cloud-среду?
Хватай мешки, вокзал отходит
Рынок публичных облаков в мире растет огромными темпами. По прогнозам IDC, в ближайшее время ожидается ежегодный рост почти на 30%. И если в недалеком прошлом эта тенденция в России была не такой явной, то теперь, когда пандемия внесла свои коррективы, мы растем опережающими темпами. В такие моменты возникает соблазн поддаться общему ажиотажу и унести в публичные облака все, что можно. Но, как подсказывает опыт, забивать микроскопом гвозди так же неудобно, как и причесываться граблями. Лучше подбирать инструмент, соответствующий задаче.
Выгодно ли мигрировать в облака? И если да, то в какие: частные или публичные? Какие облачные сервисы использовать и для каких целей? Какие факторы, технические и не очень, нужно учесть при миграции приложений в облако? Обсудим перечисленные вопросы в этой статье.
Оптом дешевле (свое или арендованное)
Что выгоднее: иметь собственный ЦОД или использовать публичные облака? Этот вопрос задает нам каждый ИТ-директор, рассматривающий использование облаков. Попробую проиллюстрировать ответ на примере житейской задачи. Что выгоднее: такси или свой автомобиль? Если поездки редкие, а запросы меняются (эконом-, бизнес-класс, а иногда и грузы перевезти), то, конечно, такси. А если требуется ежедневно возить детей в школу, себя на работу, уезжать на выходные на дачу… В общем, аналогия с облачными сервисами просматривается.
По нашим оценкам, собственная инфраструктура будет выгоднее облачных ресурсов по модели IaaS на горизонте двух-трех лет и более для размещения бизнес-критичных нагрузок с постоянными или предсказуемо меняющимися требованиями к производительности.
Значит ли это, что при наличии собственной инфраструктуры нет смысла использовать облачные ресурсы? Конечно, нет. Однако это значит, что прямая замена своих серверов на такие же облачные (IaaS) чаще всего не приводит к экономии. Если продолжать аналогию с автотранспортом: большой рамный внедорожник — вне конкуренции по проходимости, но для езды по бездорожью используется лишь пару раз в году. Вот бы только за эти пару раз и заплатить…
Приведенный пример с автомобилями подсвечивает два ключевых момента, которые нужно учитывать при использовании облачных решений, чтобы получить от них максимальную отдачу. Во-первых, не нужно брать ресурсы впрок: берите то, что нужно именно сейчас. Во-вторых, ни один сервис даже от самого лучшего провайдера не обеспечит вам полного соответствия всему разнообразию требований: следует добиваться целевых показателей за счет сочетания сервисов между собой.
Облачный подход к корпоративному ИТ
Наибольшее преимущество от миграции в облако достигается при переносе процессов разработки новых систем, и вот почему. В крупных организациях процессы управления ИТ чаще всего направлены на обеспечение безопасности и непрерывности бизнес-процессов. Любое изменение в инфраструктуре тщательно и долго согласовывается. И чем больше участников в процессе согласования, тем дольше это происходит.
Облачная платформа становится прослойкой между пользователями ресурсов и службой ИТ. Эта прослойка не просто устраняет потерю времени на согласование: она дает инструмент прогнозирования требований к ИТ, обеспечивает стандартизацию ИТ-услуг и соблюдение политик ИБ и ИТ.
Важно и то, что в такой парадигме пользователями облака становятся не только специалисты ИТ (хотя и они тоже). Основные пользователи облака — команды разработки и эксплуатации приложений. Именно их деятельность ускоряется и упрощается благодаря облакам, в первую очередь за счет самообслуживания и повторяемости конфигураций.
Такая повторяемость конфигураций нужна и специалистам ИБ. Ведь целевую безопасную конфигурацию ПО можно описать в виде кода и затем тиражировать по серверам в автоматическом режиме.
Подразделение ИТ, помимо очевидного снижения рутинной нагрузки на администраторов, наконец получает реально работающий инструмент контроля и прогнозирования потребления ресурсов, а также возможность автоматической аллокации ресурсов на бизнес-подразделения.
Представьте, что ваш конкурент прямо сейчас заказывает себе сервер в облаке и приступает к созданию прототипа нового решения, пока вы обсуждаете, где взять ресурсы для проекта.
Основные сценарии использования публичных облаков в корпоративных ИТ
Итак, перенос имеющейся инфраструктуры в облако один к одному не обеспечит ни экономии, ни повышения доступности. Так зачем же тогда все эти облака?
Мы проанализировали крупнейшие примеры применения публичных облаков в корпоративных ИТ и выделили следующие три основные цели:
1. Достичь максимально возможной скорости выделения и освобождения ресурсов
Это не только создание сред тестирования и разработки на арендованных ресурсах. В облаках удобно запускать новые проекты, пока для них ожидается поставка оборудования, или внедрять пилоты (Proof of concept), для которых не хватает внутренних ресурсов.
Если нагрузка на вычислительные ресурсы крайне неравномерная, есть высокие пики нагрузки (характерно, например, для ритейла), то динамическое «раздувание» промышленных сред в облако будет полезным вариантом.
Все эти сценарии объединяет необходимость получить ресурсы здесь и сейчас, в течение минут или часов, и (желательно) в автоматизированном режиме. Казалось бы, это скорее про технику, а не про бизнес. Но представьте, что ваш конкурент прямо сейчас заказывает себе сервер в облаке и приступает к созданию прототипа нового решения, пока вы обсуждаете, где взять ресурсы для нового проекта и кто их будет обслуживать. Не менее важно и то, что от облачных ресурсов легко отказаться, когда необходимость в них отпадет, чего не скажешь о собственном оборудовании.
Резюмируем: если взамен сервера с X процессорами и Y памятью купить такой же, но в облаке, то экономии не добиться. Облачные ресурсы нужно использовать как и положено в облаках — запрашивая и высвобождая по необходимости.
2. Перевести CAPEX в OPEX
Очень многие компании стремятся максимально перевести капитальные затраты на ИТ в операционные. Это позволяет снизить стоимость инвестиций, оптимизировать налогообложение, уменьшить затраты на обслуживание инфраструктуры. А кроме того, дает гибкость в изменении конфигурации ИТ-ресурсов. Если единственная задача — сократить капитальные затраты, а другие преимущества облачных решений не требуются, то, помимо облаков, целесообразно рассмотреть аренду серверов или другие финансовые сервисы.
3. Получить высокотехнологичные сервисы, по которым нет собственной экспертизы
Сейчас на слуху огромные возможности машинного обучения, обработки больших данных, распознавания речи и других технологий будущего. Ажиотажный спрос на специалистов в этих областях разогревает рынок зарплат. Часто (будем честными — никогда) не получается быстро найти квалифицированных специалистов и удержать их на долгий срок. Хорошей альтернативой развитию этих компетенций внутри организации может стать использование соответствующих SaaS-сервисов, особенно если они нужны на ограниченный срок для однократного решения какой-либо задачи.
Если какие-то из описанных сценариев актуальны для вашей организации, то следующей задачей станет перенос сервисов в облако. Об этом далее.
Технологии контейнеризации и микросервисная архитектура приложений как никогда близко подводят нас к голубой мечте — запускать полезную нагрузку где угодно, легко перемещать ее с сервера на сервер, из ЦОДа в ЦОД, из облака в облако.
Наш паровоз, вперед лети! (Миграция в облако)
Возьму на себя смелость сказать, что одна из важнейших тенденций последних лет двадцати в ИТ — отвязать приложения от «железа». Голубая мечта — запускать полезную нагрузку где угодно, легко перемещать ее с сервера на сервер, из ЦОДа в ЦОД, из облака в облако. Если этого добиться, то развертывание, обеспечение высокой доступности, разработка, тестирование — все это многократно упрощается. Технологии контейнеризации и микросервисная архитектура приложений как никогда близко подводят нас к этой мечте. Но какой ценой это достигается!
Ценой полной смены архитектуры и подхода к разработке — cloud native application development. Приложения cloud native масштабируемы, гибки, устойчивы к отказам и пригодны к размещению в публичных, гибридных или частных облачных средах. Проблема в том, что раньше никакого cloud native не было — то есть большинство существующих приложений, которые и «крутят шестеренки» вашего бизнеса, делались по совершенно другим принципам и не так легко переносятся в облачную среду.
Раньше мы строили виртуализированные инфраструктуры, «помещали» в них приложение и ожидали, что инфраструктура «окружит его любовью и заботой», защитит от любых инфраструктурных сбоев и даже переключит в резервный ЦОД при необходимости. В противоположность этому, подход cloud native значительную часть задач по обеспечению бесперебойности возлагает на само приложение, другую часть — на программную платформу, а инфраструктура в этом почти не участвует. Видно, что классический подход и cloud native отличаются кардинально.
Возможность перенести классическое приложение в облачную среду часто определяется целым рядом факторов, чаще всего не технических.
Во-первых, информационная безопасность. По данным публичных исследований, в достаточной безопасности публичных облачных сервисов сомневаются более половины респондентов. Поэтому крупнейшие облачные провайдеры, как мировые (AWS, GCP, Azure), так и российские (Yandex, Mail.ru), имеют в своем портфеле предложения по созданию приватных, если так можно выразиться, «выносов» своих публичных облаков в ЦОДы заказчиков. Благодаря этому заказчики могут разместить наиболее критичные для бизнеса приложения на своих площадках, сохранив преимущества облачной платформы. Кроме того, большинство отечественных провайдеров сертифицируют часть своего облака для размещения персональных данных в соответствии с законодательством. Но, даже выбирая такие решения, вы сталкиваетесь с необходимостью настроить их в соответствии как с внутренними требованиями ИБ, так и с предписаниями регулятора. Обеспечение безопасности сетевого стыка, ролевая модель доступа, централизованное управление конфигурациями облачных ресурсов — лишь немногие из задач, которые необходимо решить при переходе в облака. К счастью, чаще всего они имеют решение. Провайдеры облачных услуг предлагают широкий спектр сервисов безопасности — от сетевой изоляции до шифрования хранимых данных. Однако, по нашему опыту, этого не всегда достаточно. В таких случаях мы по согласованию с провайдером можем развернуть в облаке классические ИБ-решения (например, VPN с шифрованием по ГОСТ).
Во-вторых, показатели доступности и SLA облака. В отличие от внутреннего ИТ, где управление может быть в какой-то степени неформальным, взаимодействие с провайдером будет регламентироваться договором. Уровень доступности, прописанный там, может оказаться ниже ожидаемого. И здесь самое время вспомнить, что перенос систем в облако один к одному — не самый правильный путь. Используйте зоны доступности, распределяйте ваши приложения, по возможности размещайте их в разных облаках (строя мультиоблако) — и результирующий уровень доступности будет достаточным. Чтобы справиться с обилием арендованных ресурсов, можно рассмотреть managed-сервисы либо классический аутсорсинг «поверх» публичных облаков.
В-третьих, важно определиться, чьими силами фактически будет проектироваться и выполняться миграция в облако. Перенос большого числа систем часто сопровождается огромным объемом совместной работы инженеров, обновлением проектной документации, привлечением высококвалифицированных специалистов по отдельным технологиям. При этом ресурсы внутреннего ИТ нередко ограничены, инженеры заняты выполнением задач эксплуатации и могут посвятить миграции только часть своего времени. И это может стать острой проблемой на проекте. Среди заказчиков наших услуг по миграции — крупнейшие российские банки, у которых число информационных систем в промышленной эксплуатации измеряется многими сотнями. Их перенос в облако сопровождается изменением архитектуры, порой существенным — вплоть до смены платформы и программного стека. Это приводит к необходимости перепроектирования и тестирования новой инфраструктуры, а также согласования ИБ-решений. Чтобы обеспечить реализацию подобных проектов в срок, мы предусматриваем работы по проектированию, а также привлекаем инженеров, которые мигрируют системы совместно с заказчиком.
И наконец, в-четвертых, техническая совместимость. Сейчас большинство приложений уже виртуализированы на платформе x86. Их размещение в облаке обычно проходит без проблем. Если же возникает задача миграции с более редких платформ и/или переноса специфических СУБД, то спектр вариантов размещения, скорее всего, значительно сократится. Поэтому иногда в процесс миграции необходимо включить смену отдельных компонентов приложения (например, переход с коммерческой СУБД на СУБД с открытым исходным кодом). Однако, по нашему опыту, лучше минимизировать задачи по смене архитектуры приложений при миграции в облако, так как это значительно удлиняет сроки проекта.
Ни один из наших заказчиков не отказывается от облачных решений, ведь они добавляют внутренним ИТ так необходимую им гибкость.
Уголок скептика
Итак, облако — это не серебряная пуля. Миграция в него не всегда выгодна, и далеко не любое приложение получит преимущества от переноса в облако. Но, как сказал поэт, «скептицизм есть только первый шаг умствования» (А. С. Пушкин). Давайте попробуем шагнуть чуть дальше. В последние годы периодически появляются сообщения о том, что крупные компании возвращаются из публичных облаков в собственные ЦОДы. Решение Dropbox вернуть данные из AWS в свои дата-центры прозвучало громом среди ясного неба на фоне роста облачного рынка. Однако компания продолжает оставаться одним из крупнейших клиентов AWS и в 2018 г. перенесла 34 ПБ данных на платформу анализа данных Amazon.
Подход западных ИТ-гигантов показывает нам, что облачные технологии позволяют по-новому взглянуть на ИТ в целом. Идти не «от оборудования» (облако как ответ на вопрос «Где взять железо для новой бизнес-инициативы»), а наоборот — «от приложения». Были бы планы по развитию своих ИТ-систем, а вычислительные ресурсы — свои или внешние — найдутся. Вопрос лишь в том, в каких случаях использовать одни, а в каких — другие. Пока ни один из наших заказчиков не отказывается от облачных решений, ведь они добавляют внутренним ИТ так необходимую им гибкость.
