(За)облачные траты
Предприятия сегодня не просто рассматривают преимущества облачных сервисов, они буквально вынуждены переходить в облако, и делать это быстро. И причины тому – необходимость повышения гибкости бизнеса и высокая конкуренция. Но независимо от того, насколько велик риск возникновения цифровых сбоев, крайне важно потратить время на создание и реализацию облачной стратегии. В конце концов, принятие неверного решения - с точки зрения того, какого провайдера выбрать или какой объем ИТ-ресурсов следует перенести в облако, - в дальнейшем может быть чрезвычайно дорогостоящим и потенциально трудным для исправления.
Некоторые из этих решений основаны, например, на неправильных представлениях об экономике облака. Поскольку многие компании знают, что облако может быть дорогим (а оно, действительно, может), они часто не сравнивают схожие между собой сервисы по стоимости.
Многие администраторы утверждают, что использование собственной инфраструктуры обходится дешевле, но зачастую при оценке они не смотрят на общую стоимость владения в течение срока службы приложения. Таким образом, разработчики и администраторы должны думать не только об отдельном аппаратном и программном обеспечении, а о приложении в целом в течение всего срока его полезного использования.
Это собственное оборудование может показаться недорогим, но стоимость - это не только оборудование, но и скрытые расходы на системное администрирование, инфраструктуру, обслуживание, лицензирование, питание, охлаждение и другие нематериальные объекты.
Принятие облака - это не просто факт переноса рабочих нагрузок на выбранного провайдера облачных услуг; этот процесс также включает в себя затраты на осуществление миграции при переносе инфраструктуры в облако. Кроме того, приложения, предназначенные для миграции, также должны быть разработаны для использования в облаке, и компании, пытающиеся переделать используемые программные продукты для соответствия такой среде, столкнутся с огромными трудностями.
По этой причине администраторы, которые занимаются вопросами внедрения новых сервисов и приложений, имеют большое преимущество перед теми, кто работает в рамках устаревшей инфраструктуры. Ведь именно планирование является абсолютным требованием для успешного развертывания облака.
Важно быть реалистичным относительно требований приложений. Очень просто декларировать «масштабируйся по мере необходимости», однако фактически это сопряжено с затратами, которые должны быть определены заранее, - и здесь подразумевается не только фактическая стоимость приложения, но также стоимость его дальнейшего технологического развития и поддержки.
Масштабирование не может быть просто заявлено и сразу проведено, ключевым фактором в данном случае является тестирование, тестирование и еще раз тестирование. Кроме того, не всем требуется автоматическое масштабирование, поэтому будьте честны при предъявлении требований к облаку, необходимых для вашей организации. Функционал стоит денег и превращается в бесполезные траты, когда он не используется.
Крайне важно иметь подписанный проект, который будет согласован и, главное, понят всеми заинтересованными сторонами. До появления такого проекта выбор облачного провайдера в принципе не должен рассматриваться. При этом любой проект должен включать оценку требуемых размеров и стоимости инфраструктуры.
Только IaaS
Распространенная проблема, с которой сталкиваются облачные администраторы, когда новые администраторы или разработчики впервые пытаются ускорить свою собственную облачную среду, заключается в том, что они стремятся сконцентрироваться на том, чтобы все делать по принципу инфраструктура как услуга (IaaS), а не платформа как услуга (PaaS) и, по сути, пытаются изобрести колесо (как правило, необоснованно дорогое колесо).
Это означает, что вместо установки нового сервера базы данных используется общая инфраструктура, например общие серверы баз данных, и инфраструктура балансировки нагрузки.
В этом есть как много положительных, так и много отрицательных сторон. Один большой положительный момент - административная нагрузка на серверы баз данных высокой доступности теперь ложится на плечи поставщика облачных услуг, в то время как администратор должен справляться с графиками обслуживания от поставщика облачных вычислений.
Возможность использования инфраструктуры типа PaaS также в значительной степени зависит от конкретных требований компании. Если компания работает в жестко регламентированной отрасли, совместная инфраструктура PaaS вряд ли может стать для нее приемлемым вариантом. Ваш опыт может отличаться, но в любом случае важно проверить, убедиться и проверить еще раз.
Любой проект, на который закладывается бюджет, подразумевает наличие в штате человека для управления ресурсами (и пользователями). Часто на этом этапе любое увеличение объема услуг, которое не было запланировано, приводит к появлению шокирующе больших счетов. Особенно чувствуется удивление, если сотрудник указал свою банковскую карту в качестве средства оплаты.
Кроме того, чтобы сделать жизнь чуть проще с самого начала, предоставьте одному человеку роль ответственного за предоставление ресурсов пользователям. Это помогает остановить неконтролируемый рост расходов и не дает пользователям решать, что им нужно, помимо (или вместо) того, что им необходимо в действительности.
На этом этапе должна быть возможность взглянуть на стоимость ИТ-среды. Знание того, насколько большой будет среда, может быть очень полезным в следующих отношениях:
- Это позволяет оценить бюджет.
- Знание размеров может позволить компании резервировать объемы сервисов заранее, а не по требованию (т.н. спотовые цены), что может помочь контролировать расходы.
- Переход к облаку сопряжен с «невидимыми» затратами, такими как увеличение пропускной способности сети. Это вещи, о которых нужно подумать, поскольку они могут обходиться недешево.
- Разработка в облаке должна храниться отдельно, хотя бы потому, что ее будет легче отключать, когда она не используется, например, в нерабочее время, экономя деньги.
Готовимся к провалу
Наконец, на фоне всех шуток по поводу доступности поддержки (или отсутствия таковой) некоторых провайдеров в критические моменты, для компании в целом важно иметь план аварийного восстановления. Не так важно, как это достигается, важно наличие проверенной стратегии.
Одним из основных недостатков облачных провайдеров является то, что с потенциально миллионами клиентов вы всего лишь один из многих, и вам придется смириться с простоем и ждать решения возникающих проблем, не имея возможности как-либо повлиять на ситуацию.
Для локальных сред это спорный вопрос, но возможность правильно (и быстро) переключиться на альтернативного облачного провайдера может сэкономить бизнесу много нервов.
Многие провайдеры предлагают отказоустойчивость, но в тех случаях, когда какой-либо базовый сервис инфраструктуры выходит из строя, зависимые сервисы могут быть недоступны.
Существует несколько поставщиков программного обеспечения, ориентированных на аварийное восстановление, которые позволяют компаниям при необходимости переключаться между различными облачными инфраструктурами. В зависимости от нескольких сценариев, включая требования к доступности и договорные обязательства, такие инструменты могут быть весьма полезны. Однако одним из главных советов является обеспечение того, чтобы система аварийного восстановления могла работать полностью независимо от исходной инфраструктуры.
Другими словами, избегайте зависимостей любой ценой. Само собой разумеется, что должна быть возможность протестировать эти среды аварийного восстановления изолированно, чтобы быть готовым к тому дню, когда они могут потребоваться.
Подводя итог, скажем: облачные проекты, как правило, работают лучше всего, когда они хорошо спланированы, хорошо документированы и тщательно протестированы. Короче говоря, наличие плана поможет не только техническому персоналу, но, если все сделано правильно, также поможет организации лучше понять и контролировать свои расходы.