В этом разделе мы рассмотрим основные плюсы и минусы использования облака для развертывания вашей системы.
За последние 20 лет облачные технологии значительно усовершенствовались и учли все критические замечания. Тем не менее вы все равно услышите аргументы «против», которые приводят компании, упорно отказывающиеся даже пробовать облачные сервисы. Рассмотрим ответы на некоторые из таких возражений:
• Облако небезопасно. Когда-то этот аргумент действительно было трудно оспорить, но благодаря значительному развитию технологий мониторинга, изоляции сетей, шифрования, контейнеров и управления доступом маятник качнулся в другую сторону. Сделать систему на собственном оборудовании такой же безопасной без значительных финансовых затрат и усилий будет трудно. Это не означает, что облако стало синонимом безопасности; оно все еще требует реализации всех необходимых (а также разумных) механизмов безопасности. Однако хороший архитектор облачных решений проделает это без особых усилий, и это неотъемлемая часть создаваемых им проектов.
• Мы не сможем контролировать наши данные. Для подобного убеждения не существует никаких оснований, но оно все еще живо. При использовании облака все ваши данные хранятся у поставщика облачных услуг, а доступ к ним предоставляется с помощью инструментов и API поставщика. Организация хранения может выглядеть по-разному – как в виде файлов, так и в виде баз данных. Контроля над данными у вас будет не меньше, чем если бы они находились в вашей локальной SAN. Да, за загрузку большого объема данных будет взиматься плата. Но доступу к данным никто не препятствует.
Подобные представления возникли из-за иррационального страха пропустить ежемесячный счет на оплату облачных сервисов. Позвольте прояснить: должно пройти много (действительно много) недель, прежде чем крупные поставщики облачных услуг начнут сами удалять ваши данные.
• Это слишком дорого. Да, такое возможно, если вы используете поставщика облачных услуг так же, как традиционный ЦОД. Спустя некоторое время эксплуатация собственного оборудования будет казаться более выгодной (при условии, конечно, что вы учтете все расходы – об этом позже). Однако правильно спроектированное облачное приложение будет экономить значительные средства из года в год, особенно с учетом того, что стоимость облачных сервисов продолжает снижаться.
Чтобы облако стало по-настоящему эффективным, как и все остальное, оно должно использоваться правильно. Само по себе оно не является панацеей от всех проблем.
Некоторые с гордостью заявляют, что работают в облаке, но затем выясняется, что, хотя действительно собственных серверов у них нет, использование облака не приносит им никакой реальной пользы и в большинстве случаев скорее обходится даже дороже. Если вы хотите знать, правильно ли вы работаете с облаком, ответьте на вопросы из этого списка:
• У вас всегда одинаковые расходы на облако. Если каждый месяц вы платите за облачные сервисы примерно одинаковую сумму, особенно когда у вас сезонный бизнес с периодами высокого и низкого спроса, это значит, что вы не используете эластичность облака и возможность платить только за то, что вам нужно, и только тогда, когда вам это нужно.
• Вам требуется прерывание сервиса для его обновления. Если инженеры планируют выключение сервиса для каждого релиза – значит они используют статические серверы, и ПО необходимо обновлять на каждом из серверов. Современный облачный подход предполагает вместо этого создание новых серверов для новой версии (с использованием контейнеров, таких как Docker), постепенный перевод трафика на них, а затем удаление старых серверов.
• Вы не можете добавить ресурсы (или убавить их), чтобы соответствовать нагрузке. Уоррен Баффет сказал: «Девять женщин за месяц ребенка не родят». А вот облако может, и если у вас не получается добавить еще одну «мать», чтобы справиться с нагрузкой, то ваше приложение не готово к работе в облачных сервисах.
• У вас заканчивается место на диске. Сообщения о том, что на серверах заканчивается свободное место, указывают, что используются статические серверы, которые требуют ручного обслуживания. Хорошее облачное приложение должно использовать практически неограниченное хранилище с оплатой по факту использования.
• Происходит потеря данных. Никому не нравится слышать (или сообщать) о потере данных, и этого не должно происходить в правильно спроектированной облачной инфраструктуре (если только пользователь намеренно их не удаляет). В противном случае это говорит о наличии точек отказа и отсутствии реальной эластичности и резервирования инфраструктуры.
• Вы исходите из того, что с вашими серверами ничего не случится. Поскольку в вашем новом виртуальном мире отсутствует физическое оборудование – легко начать думать, что аппаратные сбои вас не коснутся. Однако хотя они случаются редко, но все же бывают, и, если такой сбой приводит к отказу части вашего сервиса и вызывает серьезное нарушение работы, скорее всего, ваши облачные компоненты плохо изолированы друг от друга и отсутствует их резервирование.
• Вы используете какой-то собственный инфраструктурный компонент, например балансировщик нагрузки. Современные провайдеры облачных сервисов предлагают широкий спектр услуг, которые избавляют от необходимости самостоятельно управлять отдельными серверами. Такие сервисы, как балансировка нагрузки, логирование, кэширование и управление конфигурацией на собственных серверах, традиционно приходится настраивать самостоятельно. Поэтому, если вы включаете их создание в вашу архитектуру, это может свидетельствовать о недостатке знаний или понимания того, какие облачные сервисы вам доступны.
• В облаке вы используете механизмы обеспечения безопасности, предназначенные для традиционных ЦОД. Способы обеспечения безопасности традиционных аппаратных серверов отличаются от способов обеспечения безопасности в облаке. Если вы вручную настраиваете файерволы на каждом сервере или у вас отсутствует реальное разделение сетей, вы упускаете целый уровень безопасности, предлагаемый облачным провайдером.
• Вы по-прежнему рассматриваете аварийное восстановление как переключение на резерв. Если вы до сих пор считаете, что отказоустойчивость – это возможность переключиться на запасную копию сервиса, которая простаивает в ожидании этого маловероятного события, то вы точно не готовы к работе в облаке. В грамотной облачной архитектуре отказоустойчивость обеспечивается по умолчанию.
• Вы запускаете несколько сервисов на одном сервере. Железо стоит дорого, поэтому на одном сервере обычно запускают несколько сервисов (вспомните классический стек Linux Apache MySQL PHP). В облаке таких ограничений нет. В облачной среде серверы должны быть максимально легкими, чтобы их было легко заменять, обслуживать и масштабировать.
Если вы используете облако так же, как центр обработки данных с традиционными серверами, без эластичности при изменении нагрузки, то оно потеряет большую часть своей гибкости и будет обходиться вам дороже, чем собственное оборудование. Многие облачные решения стоят больше, чем аналогичное железо, просто потому, что при переходе на них компания не понимала, что такое облако на самом деле.
Большинство людей представляют себе облако в первую очередь как общедоступный инструмент, но часто, особенно в организациях, которые вкладывают большие средства в существующее оборудование, применяется частное облако. Использование на собственном оборудовании облачной ОС с выделением ресурсов по мере необходимости поможет полностью раскрыть потенциал оборудования и вдохнуть в него новую жизнь. Вы можете использовать как коммерческие решения, так и продукты с открытым исходным кодом и выбрать необходимый вам уровень функциональности. Этот путь рекомендуется только в том случае, если у вас есть ресурсы для управления частным облаком. Хотя вы выиграете в стабильности и надежности (поскольку сможете легко перемещать ресурсы с неисправных серверов), вам все равно придется нести накладные расходы на оборудование.
Логичным развитием этой идеи является гибридное облако – сочетание частного и публичного. Когда ресурсы частного облака исчерпываются, публичное может восполнить дефицит, при этом потребители ничего даже не заметят.
Тех, кто привык к традиционному оборудованию, может пугать переход в облако, но бояться не стоит. Вы сможете использовать все имеющиеся у вас навыки и опыт; нужно лишь взглянуть на проблему по-новому. Люди, успешно перенесшие свои проекты в облако, ставили вопрос так: «Вот таким образом я действовал бы при настройке оборудования; как сделать то же самое в облачном сервисе?» Рассмотрим три правила, которые необходимо помнить для успешного перехода:
• Облако не гарантирует безопасность. Защиту необходимо продумать, спроектировать и внедрить в каждую часть решения. Не полагайтесь на какой-либо уровень безопасности только потому, что вы используете сторонний сервис. Каждый раз существует риск неправильной конфигурации, поэтому тщательно проводите тестирование.
• Сбои неизбежны. Облако привлекает тем, что нет необходимости поддерживать оборудование, и создает впечатление, что так вы избавитесь от сбоев. Но облако от них не защищено; аварии будут. Планируйте их, создавайте и отрабатывайте сценарии действий. Благодаря грамотной архитектуре сбои могут пройти незаметно и не нарушить работу пользователей, что избавит вас от значительных дополнительных затрат.
• Создать проблемы проще простого. В облаке очень легко настраивать и использовать ресурсы. Но их так же легко и уничтожить. Будьте осторожны. Понятие «продакшена» здесь существует только в вашей голове. Облачный провайдер предполагает, что вы знаете, что делаете, и не задумываясь выполнит ваш запрос на удаление рабочей базы данных.
Облако избавляет от множества проблем, с которыми вам пришлось бы справляться, работая с традиционным оборудованием. Однако не думайте, что станет легче. Ваши проблемы теперь просто приняли другой характер.
Заметки с полей
Производство меда
Одна из аналогий, которую я использую, описывая разницу между традиционными и облачными приложениями, – это обычная пчела. Мать-природа сделала так, чтобы производство меда не зависело от отдельной пчелы; каждая пчела рано или поздно погибает. Смерть одной пчелы не влияет на общий процесс. Именно так устроено хорошее облачное приложение – сбой является частью его ДНК. С другой стороны, большинство компаний, бизнес которых основан на использовании ПО, устроены как одна-единственная огромная генно-модифицированная пчела, постоянно производящая мед. Однако, если эта «пчела» умрет, производство остановится. И в нашем мире слишком много таких генно-модифицированных пчел.