Подходы к переносу приложений в облако
Любое изменение ИТ-инфраструктуры организации, независимо от ее размера, должно быть оправдано с точки зрения бизнес-потребностей и перенос приложений в облако не является исключением. Оценив возможности облачной платформы, следует идентифицировать приложения, которые максимально выиграют от переноса в облако. Приложения со схожей архитектурой будут, вероятнее всего, переноситься в облако схожими методами. Определенные приложения будут лучшими кандидатами с точки зрения технологий, простоты миграции или потому что их перенос в облако отвечает бизнес-потребностям, например повышению надежности или снижению расходов на сопровождение. В данном разделе мы рассмотрим несколько типичных сценариев переноса приложений в облако, исходя из их архитектуры:
Веб-приложение на базе IIS и SQL Server Веб-приложения, использующие веб-сервер Internet Information Services и SQL Server довольно часто применяются для различных задач автоматизации в современной организации. Как правило, пользователями приложений являются сотрудники организации. Перенос таких приложений в Windows Azure может существенно повысить надежность работы, избавить от множества проблем с сопровождением и администрированием инфраструктуры и обеспечить высокое качество предоставления сервиса, обычно недостижимое для большинства приложений уровня департамента. Также, перенос в Windows Azure позволит заложить основу для будущего роста использования приложения, например, если организация примет решение использовать удачную систему для всех сотрудников. Наиболее распространены два варианта архитектуры таких приложений, как показано на рис. 24: Рис. 24. Варианты архитектуры на базе IIS и SQL Server Относительно простая архитектура и выбранные технологические решения делают приведенные на рис. 24 приложения хорошими кандидатами на миграцию в Windows Azure. Тем не менее, следует обратить внимание на следующие аспекты:
Единый вход позволяет использовать учетные записи в домене AD для доступа к приложению в облаке без необходимости повторного ввода имени пользователя и пароля. После миграции в Windows Azure архитектура приложения будет выглядеть следующим образом (рис. 25): Рис. 25. Архитектура приложения после переноса на Windows Azure/SQL Azure Обратите внимание, что для хранения нереляционных данных, таких как файлы, используется Azure BLOB Storage. Веб-приложения для электронной коммерции Приложения для автоматизации задач электронной коммерции обладают рядом особенностей, делающих их отличными кандидатами на перенос в Windows Azure. В ряде случаев преимущества от использования облачных технологий могут оказаться столь привлекательными, что имеет смысл адаптировать архитектуру приложения специально для облака, например воспользоваться платформенными сервисами Windows Azure. На рис. 26 показана схема архитектуры типичного приложения для электронной коммерции. Рис. 26. Типичное приложение для электронной коммерции Как правило, локальная инфраструктура, обеспечивающая работу приложения, не является геораспределенной и централизованно расположена на собственном или арендуемом оборудовании. Организация предоставляет своим заказчикам веб-сайт или другой интерфейс, через который могут производиться B2C операции. Также, веб-сайт или другой интерфейс предоставляется поставщикам наряду с программным доступом для обеспечения B2B операций. В дополнение к тому, что было сказано выше, при переносе более простого приложения, использующего IIS и SQL Server, в данном случае имеются следующие особенности:
На рис. 27 показана схема архитектуры приложения после переноса в Windows Azure. Рис. 27. Приложение для электронной коммерции в Windows Azure Использование динамичной инфраструктуры Windows Azure позволит улучшить следующие аспекты работы приложения:
Высоконагруженный сайт Web 2.0 С увеличением числа интернет-пользователей, в том числе заходящих в сеть с различных мобильных устройств, наблюдается рост числа высоконагруженных сайтов. Эти сайты обслуживают громадное количество пользователей, могут хранить большой объем видео- и фотофайлов, и в целом предъявляют серьезные требования к производительности и масштабируемости аппаратно-программной инфраструктуры. Постоянная доступность и надежность сайта, модель финансирования которого основана на показе рекламы пользователям, является очень важным техническим требованием, напрямую влияющим на успех бизнеса. Обычно, такие сайты арендуют площадки в центрах обработки данных, инвестируя существенные ресурсы в инфраструктуру, в том числе, чтобы обезопасить себя от часто случающихся пиков активности пользователей. При росте бизнеса капитальные инвестиции в оборудование и доработку архитектуры превращаются в регулярный процесс и могут составлять значительную часть расходов. С другой стороны, неспособность быстро отреагировать на рост интереса к сайту может привести к потере пользователей и прибыли от рекламы. На рис. 28 показан вариант архитектуры высоконагруженного сайта. Рис. 28. Высоконагруженный сайт Web 2.0 В дополнение к тому, что было сказано в разделе, посвященном веб-приложениям для электронной коммерции, можно выделить следующие преимущества переноса высоконагруженных сайтов в Windows Azure:
Веб-сайты, которым требуется быстрое масштабирование, являются кандидатами на перенос в облако, однако это может потребовать соответствующей адаптации архитектуры, как представлено на рис. 29. Рис. 29. Cайт Web 2.0 в Windows Azure Как показано выше, потребовались следующие изменения в архитектуре сайта:
Веб-сайт на PHP и MySQL PHP является популярной кросс-платформенной технологией для создания веб-сайтов в Интернете. Часто в паре с PHP в качестве базы используется MySQL, как показано на рис. 30. Рис. 30. Веб-сайт на PHP и MySQL Большинство рекомендаций по переносу приложений в Windows Azure относятся и к данному типу приложений. Однако следует обратить внимание на следующие особенности:
В результате переноса архитектура PHP приложения в Windows Azure может выглядеть так, как показано на рис. 32. Рис. 31. Процесс переноса БД MySQL в SQL Azure Рис. 32. Сайт на PHP в Windows Azure Этот вариант архитектуры концептуально близок к архитектуре с IIS и SQL Server, рассмотренный выше. Отличие заключается в необходимости миграции базы данных из MySQL в SQL Azure и использование специфичных для PHP компонентов. Параллельная обработка данных Как отмечалось выше, множество задач требуют больших вычислительных ресурсов для обработки данных в параллельном режиме, одновременно запуская большое число процессов на разных физических и виртуальных машинах. Типичная архитектура такого приложения представлена на рис. 33. Рис. 33. Параллельная обработка данных Заметим, что такие элементы архитектуры, как ферма обработчиков (обработчики очереди), упоминались выше в разделе, посвященном высоконагруженному сайту. Многие рекомендации применимы и для данного приложения. Но в отличие от приложений, ориентированных на транзакционную работу с данными, в данном случае интерфейс пользователя выполняет функцию консоли управления, а вычисления происходят в асинхронном режиме. Отметим следующие преимущества применения облака для параллельной обработки данных:
На рис. 34 показана схема архитектуры приложения, выполняющего параллельную обработку данных в Windows Azure. Рис. 34. Параллельная обработка данных в Windows Azure Обратите внимание на следующие особенности:
Заключение Проектирование приложения для размещения в облаке может показаться сложным процессом, требующим владения множеством навыков и глубокого знания технологий. Отчасти это так, особенно, если речь идет о SaaS-решении, предназначенном для обслуживания тысяч пользователей. Однако для приложений более скромного масштаба знание основных особенностей облачной платформы и следования нескольким базовым рекомендациям может быть вполне достаточным. Важно помнить, что Windows Azure Platform — это в первую очередь платформа Windows, а следование архитектурной нотации и правилам, приближающим ваше приложение к идеалу, полезно само по себе, и не важно, где в дальнейшем будет размещено приложение — у заказчика или в облаке. 1https://code.msdn.microsoft.com/windowsazuresamples 2 Для получения более подробной информации см. раздел «Цена архитектуры». 3 SQL Server и SQL Azure поддерживают принцип ACID, а Table Storage — принцип BASE. 4 В перспективе ожидается, что Windows Server AppFabric Cache будет поддерживаться в Windows Azure. 5 SimpleCloud API — это результат совместной работы ведущих мировых компаний по стандартизации программных интерфейсов доступа к прикладным сервисам в облаке. |