July 22, 2013

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

Как планируются решения on-premise

Кстати on-premise переводится как “на предприятии”, что означает использование собственных ресурсов, вместо арендованных.

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

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

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

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

Почему в облаке это неправильно

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

Если вы в облаке заранее резервируете в 10 раз больше ресурсов, чем необходимо сейчас, то вы платите в 10 раз больше, хотя по факту большая часть ресурсов простаивает. Тоже самое касается лицензий на ПО. Нет смысла покупать 8 процессорных лицензий для SQL Server за несколько миллионов, если ваше решение сможет три месяца бегать на двух процессорах, а еще девять месяцев на четырех. Суммарные затраты на три года аренды лицензий и серверов в Azure будут ниже стоимости одних лицензий для on-premise.

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

Как работает облачная экономика

В облаке всегда начинайте с малого. Вам не нужно три воркера и распределенный кеш, вам не нужно 4 WFE для SharePoint, вам не нужна A7 виртуалка с SQL Server. Скорее всего вы можете обойтись в 2-3 раза меньшими ресурсами. Если вы в начале пути, создаете новое веб-приложение или разворачиваете ферму SharePoint – выделяйте минимум ресурсов.

Когда ваше решение начинает масштабироваться – следите за профилем нагрузки. Нет смысла все время держать кучу воркеров, если они ничего не делают. Отключайте виртуалки, если средняя загрузка ниже 50%, а всплески не поднимают её выше 75%. Добавляйте новые диски в виртуалку и SQL Server, так как именно в IO упирается производительность SQL, а платите вы все равно за место.

Когда ваше решение получит более-менее стабильный профиль нагрузки, тогда занимайтесь оптимизацией. Нет смысла оптимизировать облачное решение, когда вы платите за него 10,000 рублей в месяц. Даже если вы сэкономите 10%, то это будет незначительная сумма. Когда ваше решение будет стоить 100,000 в месяц – уже стоит задуматься об оптимизации.

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

Когда перестает работать облачная экономика

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

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

Заключение

Статья получилась в стиле Капитана “Очевидность”, но я каждый день сталкиваюсь с непониманием сути облачной экономики. Может кто-нибудь найдет эту статью, прочитает и начет думать по-другому.