Приветствую Хабражителей! Это мой первый пост тут, надеюсь, он вам понравится, а кому-то окажется полезным. В посте я опишу нашу практику использования Windows Azure в качестве для SaaS проекта. Статья будет полезна тем, кто работает с .NET и задумывается о переходе в «облако».
Про сервис и команду
В начале скажу пару слов о самом сервисе. СпортФорт автоматизирует процесс создания официального сайта спортивной команды. Наша платформа используется как любителями, так и профессионалами. Возможно, СпортФорт будет полезен небольшим студиям и фрилансерам для изготовления сайта команды или лиги. Наш проект первый из подобных на рынке СНГ.
внешний вид сайта команды
Как это часто бывает, мы упираемся в финансирование, поэтому наша команда небольшая и каждый ее член – «и жнец, и швец, и на дуде игрец». Нас трое: я занимаюсь развитием продукта, программирую, еще у нас есть человек, который занимается поиском финансирования и административными вопросами, и менеджер по продажам. Нам помогают и другие ребята, дизайн подрисовать, рекламную кампанию настроить, сделать видео и т.д.
Технические детали сервиса
Windows Azure нас очень здорово выручил. Особенно учитывая, что сначала мы пользовались им по программе BizSpark. До перехода в WA у нас был обычный , который нас частенько подводил. Ни у кого в команде нет навыков администрирования серверов, а выделить бюджет под нового специалиста возможности не было. Иногда наш падал на целый день и абсолютно ничего нельзя было сделать, служба поддержки просто игнорировала все входящие сообщения и оставалось только гадить в их твиттер. Я рассматривал вариант организовать собственные сервера, но это затратно как по финансам, так и по времени. WA позволил не отвлекаться на аппаратную инфраструктуру, а сосредоточиться на продукте. Работается гораздо комфортнее, когда знаешь, что все надежно и что никаких серьезных изменений для масштабирования не потребуется.
В архитектуре Azure функциональными компонентами являются роли, это могут быть Web Role, обслуживающие внешние запросы или Worker Role для внутренних задач. Каждой роли можно выделять соответствующую нагрузке вычислительную мощность. Например, сайт, обрабатывающий видео, кроме Web Role, которая будет отвечать непосредственно за сайт, будет содержать одну Worker Role для обработки видео. И если будет сразу много запросов, то WA сможет добавить мощности этой Worker Role.
В нашем случае, сервис раньше представлял собой обычный веб-сайт на ASP.NET MVC 3 с базой данных MS SQL и хранением пользовательских файлов (в основном, картинок) в файловой системе. Соответственно теперь это Web Role на ASP.NET MVC 3 с базой данных SQL Azure и хранением картинок в Blob Storage, специальном облачном хранилище для бинарных файлов. Кроме Blob Storage в WA есть еще два типа хранилищ – Table Storage и Queue Storage. Table Storage – нереляционная база данных, мы используем ее для хранение логов, а Queue Storage – встроенный механизм работы с очередями сообщений, который мы пока не используем.
Для управления всеми сервисами в Windows Azure есть панель управления, работающая через браузер. Здесь можно настроить как технические параметры, так и просмотреть статистику использования.
панель администрирования Azure, здесь и hosted service, и storages и databases
Деплой на Windows Azure отличается от деплоя на обычный . Чтобы выложить новую версию, нужно сформировать специальный пакет и загрузить через панель администрирования. При этом обновление произойдет автоматически – все серверы будут обновлены по очереди, сервис не уйдет в оффлайн. Подменить отдельный файл при этом не получится. А вот работа с SQL Azure ведется также как и с обычным SQL Server’ом, через Management Studio. Там есть небольшие отличия, связанные с ключами, но они меня не коснулись.
Кроме различий в деплое, у нас поменялся процесс тестирования. В Azure это сделано удобнее: мы сначала выкладываем новую версию в предварительную среду, так называемую “Staging Environment”, затем тестируем и, если все хорошо, то меняем текущую версию на новую. Это происходит очень быстро в один клик. Другие возможности Azure я еще не изучил, но знаю, что там есть автоматическое выделение новых ресурсов при возрастании нагрузки. В дальнейшем это нам понадобится. Можно сказать, что пока мы в основном используем WA как обычный , кроме деплоя и тестирования ничего не поменялось.
В последнее время с развитием сервиса и появлением новых функций появляется необходимость использовать и другие возможности Azure. В частности для несрочных и долгих задач в WA отлично подходит Queue Storage в связке с Worker Role. Я планирую для рассылки уведомлений завести отдельную Worker Role и использовать очереди Queue Storage для передачи сообщений этой роли. Вообще по-хорошему нужно многие функции, связанные с удаленными службами, переделывать для работы с использованием очередей, но руки пока не доходят.
Перейти на WA было довольно просто, т.к. изначально сервис программировался с использованием «правильных» паттернов, хотя и на скорую руку. Прежде всего, я имею в виду Dependency Injection, использование которого позволило, например, только в одном месте заменить FileSystemPictureStorage на AzurePictureStorage в качестве реализации интерфейса IPictureStorage. Ну и написать скрипт миграции, конечно же. Таким образом, вместо файловой системы, которую нельзя использовать в качестве постоянного хранилища в WA, мы перешли на использование облачного хранилища.
На локальной машине разработчика эмуляция Windows Azure и SDK разворачиваются довольно просто, а база данных используется локальная (в нашем случае SQL Server 2008 R2).
Мой вывод
Самое главное преимущество для меня¬ – это надежность. Больше не нужно краснеть перед пользователями когда у хостера что-то не так. Пользователям стабильность, конечно, тоже нравится. Радует скорость нововведений для среды разработки. Когда в MS сделают поддержку SQL Azure в Database Project будет вообще супер). Также огромным плюсом стало то, что удалось достаточно просто перейти в «облако»: не пришлось ничего капитального переделывать и удалось во всем разобраться самому. И нам не потребовалось нанимать высококвалифицированного специалиста для построения масштабируемой архитектуры.
Если будет интерес к статье, то я опишу еще финансовую сторону вопроса.
Спасибо за внимание!
Автор: gamay
