Облачный скачок: вопросы и метрики

Исследования и прогнозы в IT
Как правило, в своих постах я обсуждаю новые технологии, которые применяются либо вскоре найдут применение в «облаках». Новые сервисы, новые модели, перспективы. Но все это время я, намеренно или случайно обходил, весьма важную тему, которая несомненно, интересует любое предприятие, которое планирует или хотя бы даже задумывается о переходе на облачные технологии. А именно – какими соображениями и метриками следует руководствоваться при принятии решения о переводе всего или части ИТ-мощностей в облако?

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

Перед внедрением решений на базе технологий облачных вычислений стоит сначала ответить на следующие вопросы: (хотя список, безусловно, неполный)

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

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

Чтобы правильно ответить на вопрос «что мне нужно?», необходимо четко сформулировать проблему или осознать факт ее отсутствия. Так, типичными проблемами бизнеса, которые побуждают многих обратиться к облачным платформам — это:

  • У нас заканчивается место в дата-центре, а большинство приложений используется через интернет. Следует ли вложить средства в дальнейшее наращивание собственных возможностей или перенести часть нагрузки на провайдеров публичных облачных решений?
  • В скором времени мы запускаем новый сервис/приложение и нам необходимо быстро адаптироваться к нагрузке, особенно если она будет быстро расти. Нам скорее всего не удастся наращивать собственные мощности достаточно быстро – необходимо подключить внешнего провайдера чтобы не испортить пользователям впечатление.
  • Нам необходимо ускорить выход на рынок и сделать бизнес более гибким. У нас нет времени ждать пока подтянутся IT и соответствующая инфраструктура.

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

Вот некоторые индикаторы, на которые стоит ориентироваться:

  • Время на разворачивание среды разработки
  • Количество инцидентов блокировки приложений
  • Стоимость инфраструктуры в расчете на приложение
  • Время/затраты на масштабирование приложений
  • Пропускная способность
  • Соглашение об уровне обслуживания (SLA)

Итак, вы решились действовать


Вы разобрались с мотивами перехода и решили, что без облачной платформы вам не обойтись. Отлично. Теперь начинается самое интересное. Если мы создаем под платформу совершенно новое приложение, то процесс его развертывания сильно упрощается, так? Просто загружаете на сервер и, все работает. Так. Но не факт что работать будет так как вам хочется. Помните, что для того чтобы поддерживать эффективность облачных приложений на оптимальном уровне в течении продолжительного времени (и как результат — предоставлять качественные сервисы), их работу необходимо непрерывно отслеживать и сделать это сложнее чем на собственном сервере. Вам необходимы специализированные инструменты. И инструментов, которые предоставляет провайдер скорее всего недостаточно. Они предоставляют только базовую информацию инфраструктурных метрик (т.е. загрузка процессоров, использование памяти, сети и так далее). Они ничего не скажут вам непосредственно о том, что происходит с вашими приложениями и что вам необходимо делать. Вот необходимый минимум метрик:

  • Какие узлы приложений используются в данный момент времени. (динамическое масштабирование, инициализация и деинициализация влияют на эти показатели сильнее всего)
  • Соединения приложений с внешними службами плюс время отклика и процент ошибок. (Обслуживание вызовов извне сильно снижает производительность облачных приложений и повышает затраты так как у большинства провайдеров исходящий трафик оплачивается)
  • Время отклика и логи ошибок для всех бизнес-транзакций пользователей. (Это применимо к любой архитектуре, но у облачных платформ есть дополнительные «подводные камни» — факторы, не зависящие от поставщика приложений, скажем, загрузка сети провайдера, проблемы с провайдером на стороне облака и так далее)
  • Когда возникает проблема – полный стек вызовов приложения для анализа кода. (Также справедливо для приложений, работающих на любой архитектуре)
  • Корреляция уровня KPI хоста и загрузки приложений. (особенно важно для размещаемых в облаке приложений так как из-за виртуализации, общих ресурсов и обилия вариантов хостинга ошибиться в выборе очень легко. Ошибка в меньшую сторону насильно ограничит максимальную производительность вашего сервиса, в большую – вы будете платить за простаивающие мощности)
  • Показатели работы сервиса в прошлом – необходимы для определения нормального и аномального поведения сервиса (Необходимо для идентификации неполадок независимо от архитектуры)

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

Все эти операции являются только подготовительным этапом к миграции. Но они необходимы для обеспечения беспроблемной миграции на новую архитектуру. Планирование – ключ к успеху. Но описанные операции – только часть необходимых. Об остальных читайте в следующих постах.

Комментарии (0)


Добавление комментариев доступно только зарегистрированным пользователям. Используйте свою существующую учетную запись для авторизации. Если у Вас еще нет учетной записи на сайте ее можно создать пройдя несложную процедуру регистрации. Кстати, для входа на сайт, наравне с учетной записью на cloudzone.ru, можно использовать аккаунт из следующих популярных сервисов: Яндекс, Facebook, Google и LinkedIn