Облачные обещания по-прежнему туманны?

«Запускайте в облаке», «Переносите в облако», «Облако идеально подойдет для ваших приложений» — вы просто не могли не заметить весь этот шум вокруг облачных технологий, если в последние 10 лет вам довелось работать в ИТ (и даже если не довелось).

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

Давайте разберемся подробнее, чтобы понять, что именно представляет из себя эта технология, необходимая для построения современных ИТ-инфраструктур, способных обеспечить разработку и доставку приложений в XXI веке.

Облачная безмятежность?

Масштабируемость всегда была важным фактором для любого бизнеса, который планирует расти и расширяться. С появлением Интернета потребность в ней только усилилась, поскольку теперь наши сервисы должны работать в режиме 24/7. Однако заказчики быстро осознали, что погоня за масштабируемостью без оглядки на цену оборачивается резким ростом издержек, поэтому призыв «делать больше за меньшие деньги» популярен сейчас как никогда раньше. Облако призвано обеспечить наращивание вычислительных мощностей строго по мере необходимости, особенно в современных условиях, когда общедоступные облачные ресурсы можно получать практически в неограниченных объемах и по весьма выгодным ценам.

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

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

Шторм на горизонте

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

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

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

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

Луч надежды?

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

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

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

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

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

Автор статьи — старший архитектор ИТ-решений, Red Hat.

Версия для печати