Интересен результат Microsoft, т.к. от Amazon S3 он отстает не сильно, но при этом использует реляционную SQL Azure, а не Windows Azure Storage Table (аналог S3), которые в исследовании участия не принимал (по причине отсутствия полной транзакционости).

 

5. Разработка  облачного приложения

 

     Разработка  веб-приложения  для «облака» мало чем отличается от обычного веб-приложения. Для демонстрации технологии была выбрана  платформа Windows Azure. Приложение, написанное на ASP.NET, переписывалось для работы в облаке, для чего был установлен Azure SDK. В Visual Studio появился новый вид проектов Windows Azure Project. Приложение запускалось на эмуляторе облака, однако, стоит учесть, что разработка на эмуляторе несколько отличается от использования облачного окружения.

     В структуру полученного проекта (Рисунок 5) добавлена аппликация (TestProjectAzure), которая отвечает за «облачную» составляющею проекта.  

     

     Рисунок 5 Структура приложения

      

     Рассмотрим конфигурационные файлы:

     ServiceConfiguration.cscfg – этот файл определяет конфигурацию сервиса, и как им будет управлять Azure. Например, там указывается количество веб-ролей, для каждой специфической веб-роли (количество виртуальных машин поднять для заданной веб-роли). Автоматически для каждой веб-роли выделена одна виртуальная машина. 

     

     Рисунок 6 ServiceConfiguration.cscfg 

     ServiceDefinition.csdef – определяет какие сервисы, являются частью аппликации, и если есть внешний доступ, то конфигурацию протоколов и портов сервера.

     Также в конфигурационном файле можно указать какую конфигурацию виртуальной машины должно использовать приложение. Этот параметр задается в настройках веб-роли. Конфигурация виртуальной машины в Windows Azure зависит от цены за час использования (Таблица 1).  

     Таблица 1-Цены на виртуальные машины

 

     В Windows Azure есть три типа сервисов хранения данных блобы, таблички и очереди. Каждая из них может быть использована для разных нужд. К примеру, в табличках мы можем хранить статистические данные, которые необходимы для создания отчета, или же мы можем там хранить информацию о товарах в магазине; в очереди мы можем хранить строчки, собственно хранением это назвать тяжело – скорее пересылкой сообщения от роли к роли; блобы – самые большие, объемные и больше всего подходящие под хранение файлов, музыки, видео, и другого медиа-контента. Именно блобы лучше использовать как аналог файловой системы для всего приложения.

     Blobs (далее блобы) – это аббревиатура от Binary Large OBjects. В самом начале блобы появились в реляционных базах данных, и использовались для хранения файлов в табличке, собственно с такой же идеей они и перекочевали в Azure. Блобы находятся в контейнерах, на аккаунте может быть создано любое количество контейнеров. Контейнер создается следующим кодом:

     SetConfiguration();

CloudStorageAccount account = CloudStorageAccount.FromConfigurationSetting("testConnectionString");

            CloudBlobClient blobClient = account.CreateCloudBlobClient();

            CloudBlobContainer container = blobClient.GetContainerReference("newcontainer");

            container.CreateIfNotExist(); 

     Добавить  файл в блоб можно следующим кодом:  

     var blob = container.GetBlobReference("NHL.jpg");

             blob.UploadFile(@"c:\NHL.jpg"); 

     Можно использовать следующие методы:

• UploadByteArray –данный метод позволяет нам загружать определенный массив байтов в сервисы хранения данных;
• UploadFile – принимает как параметр путь к файлу и именно его загружает;
• UploadText –записывает в блобы текст;
• UploadFromStream – позволяет использовать для загрузки потоки

     Максимальный объем блоба – 1 терабайт. Если пользоваться для загрузки библиотекой – то если блоб будет более 64 мегабайт – он будет разбит на блобы по 4 мб. В случае если нужно создавать видеохостинг и предоставлять потоковое видео это идеальное решение.

     В остальном разработка приложения ничем не отличается от обычного. Так же стоит отметить, что у разработчика есть возможность определить из кода, где запущено приложение, на «облаке» или на локальном сервере, это позволяет писать универсальные библиотеки в зависимости от места где запущено приложение.

 

Заключение

 

     Из  исследований практической стороны вопроса разработки приложения, предназначенного для работы в «облаке», можно сделать выводы:

• Разработка приложения для работы в «облаке» занимает в среднем на 20% больше времени, при условии, что оно сразу оптимизировано работать параллельно на многих серверах;
• Повышение мощности оборудования и увеличение количества доступных серверов занимает минимальное время и минимальные затраты бюджета;
• Приложение, написанное для обычного сервера, быстро переносится на облачную платформу;
• Один и тот же код может работать, как и на локальном сервере, так и в «облаке», что улучшает согласованность версий приложения.

     Для конечного пользователя можно выделить весомые плюсы облачных услуг

по технологии «программное обеспечение как сервис»:

• Требовательные к быстроте процессора программы и объему оперативной памяти программы будут работать на любом персональном компьютере с доступом в интернет;
• Нет необходимости в обновлении и в настройке программ - это делается поставщиком услуг, теперь это все часть сервиса;
• Документы всегда доступны, при подключении Интернета.
• Появляется возможность совместной работы над одним и тем же документом у нескольких пользователей - нет необходимости пересылки и синхронизации версий документов.

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

     Перспектива развития облачных вычислений идет к  тому, что на смену существующим видам технологии появится объединенная структура «*aaS» (Everythig as a Service), когда абсолютно все, что может понадобиться для работы, станет доступно через «облако» в качестве услуги. Однако вряд ли эта технология когда-либо станет безальтернативным решением, всегда найдутся области применения собственных центров обработки данных и персональных систем.

 

Список использованных источников

 

1. Version One. Cloud Confusion Amongst IT Professionals: [Electronic resource]. - http://www.versionone.co.uk/news/cloud-of-confusion-amongst-it-professionals.php                            
2. Business Adoption of Cloud Computing: [Electronic resource]. - http://www.aberdeen.com/Aberdeen-Library/6220/RA-cloud-computing-sustainability.aspx
3. Schneier B. Security in the Cloud: [Electronic resource]. - http://www.schneier.com/blog/archives/2006/02/security_in_the.html
4. TPC Benchmark: [Electronic resource]. - http://www.tpc.org/tpcw
5. Kossmann D. An Evaluation of Alternative Architectures for Transaction Processing in the Cloud: [Electronic resource]. -http://systems.ethz.pubzone.org/servlet/Attachment?attachmentId=76&versionId=1363456
6. Amazon. Amazon WebServices. [Electronic resource]. - http://aws.amazon.com
7. Kraska T. End-To-End Performance Study Of Cloud Services. [Electronic resource]. -http://highscalability.com/blog/2010/5/26/end-to-end-performance-study-of-cloud-services.html
8.  C. Hay, B. Prince. Azure in Action - Manning Publications, 2010. – 425c.