Файл: Облачные Сервисы (основы технологий облачных вычислений).pdf

Общая черта популярных отечественных SaaS-решений — их направленность на удовлетворение потребностей малого бизнеса: подавляющее большинство их пользователей составляют компании с числом сотрудников около 10–20 человек.

Перспективы развития SaaS-сервисов

Одна из наиболее многообещающих тенденций развития SaaS-приложений — это взаимная интеграция различных SaaS-сервисов, в том числе разработанных разными поставщиками. Например, приложение для организации адресных email-рассылок MailChimp поддерживает интеграцию с Facebook (что позволяет сочетать возможности email-рассылок с функциональностью социальной сети), Google

Apps (что позволяет использовать данные из Gmail и других приложений Google), Google Analytics (что позволяет визуализировать и анализировать результативность рассылки) и др.

Другой пример: приложение PowerDialer от компании InsideSales.com позволяет пользователям CRM-системы Salesforce.com автоматизировать одну из наиболее рутинных процедур в деятельности современных компаний — «обзванивание» потенциальных клиентов, позволяя оператору сосредоточиться на непосредственном общении, а не на процессе дозвона и подсчете оптимального времени для общения с тем или иным клиентом. При этом компания InsideSales.com разрабатывает и собственную CRM-систему, однако по степени популярности она не может тягаться с лидером рынка Salesforce.com. Таким образом, благодаря интеграции SaaS пользователи получают в едином пакете самую популярную онлайновую CRM-систему с наиболее функциональной системой автоматизации телефонных дозвонов.

Комбинация функциональных возможностей — не единственный плюс от интеграции SaaS-сервисов. Сегодня достаточно завести учетную запись в системе одного из крупных поставщиков, предоставляющих платформу для единой аутентификации, будь то Facebook, Google или Microsoft, — и далее просто по мере необходимости «подключать» новые сервисы от других поставщиков, сведя регистрационную рутину к минимуму.

Чтобы еще больше упростить такое «подключение», каждый из ведущих поставщиков создал собственную площадку для приложений от сторонних поставщиков. Чаще всего такая площадка представляет собой каталог подключаемых онлайн-приложений (AppExchange от Salesforce.com, Google Apps Marketplace, Office 365 Marketplace). Подключение приложений с помощью таких площадок аналогична установке традиционного ПО, только протекает существенно быстрее и не требует вмешательства системного администратора. По сути, ведущие поставщики сегодня создают платформы, которые в будущем возьмут на себя часть функций привычных нам операционных систем.

Вместо того, чтобы создавать приложения для Windows, Linux или MacOS, сегодняшние разработчики пишут программы, изначально нацеленные на интеграцию с Google Apps, Facebook, Salesforce.com или Microsoft. У каждой платформы есть плюсы и минусы. Как и в прошлом, разработчик может принять решение о том, чтобы связать свое будущее с одной платформой или же создать многоплатформенное приложение, которое будет способно интегрироваться с платформами разных поставщиков.

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

2.2. Облачные сервисы, основанные на модели PaaS

Решения класса PaaS — динамично развивающееся направление облачных вычислений, ориентированное прежде всего на веб-разработчиков.

Решения PaaS позволяют упростить разработку и развертывание масштабируемых веб-приложений и сэкономить трудозатраты программистов. Однако взамен на дополнительные удобства разработчики должны быть готовы уступить часть низкоуровневого контроля за системой облачному поставщику.

PaaS-решение в инвентаре разработчика можно сравнить с кухонным комбайном в домашнем хозяйстве: это приспособление позволяет ускорить и упростить приготовление повседневной пищи: например, замешивание теста на пирог, подготовку фарша для пельменей или выжимание сока из яблок. Разумеется, найдутся и такие блюда, в приготовлении которых кухонный комбайн особо не пригодится. Например, если вдруг нам придет в голову приготовить утку по‑пекински, то практически всю кулинарную работу придется выполнять в «ручном режиме». Но таких блюд не так много, и готовим мы их редко.

Аналогичным образом PaaS-системы могут сэкономить разработчику массу времени и сил в большинстве типовых ситуаций. В тех немногих случаях, когда разрабатываемое приложение уникально по своим характеристикам, преимущества от использования PaaS будут сравнительно невелики. Однако такие приложения можно сопоставить с изысканными деликатесами — мы их готовим нечасто, и для большинства обычных веб-приложений PaaS-системы представляют не только приемлемый, но и коммерчески выгодный вариант.

Анализ современного состояния облачных сервисов, основанных на технологии PaaS

Облачные решения класса PaaS — относительно новое направление, старт которому был дан в 2007–2008 годах, когда компания Salesforce.com представила сервис Force.com, а Google — платформу Google App Engine. C тех пор количество различных PaaS-решений резко возросло, и сегодня разработчики обладают беспрецедентной свободой выбора облачных решений. Существует Engine Yard и Heroku для любителей Ruby, PHP Fog для специалистов по PHP, Stackato для программистов на Perl, Cloudbees для Java-разработчиков и т. д. Также существует несколько PaaS-проектов от крупных вендоров, стремящихся одновременно охватить несколько популярных технологий разработки, таких как Windows Azure от Microsoft (.Net, Java, PHP, Ruby), OpenShift от Red Hat (Java, Ruby, PHP, Python) и Cloud Foundry от VMware (Java, Ruby, Node.js). Существуют также десятки менее известных систем, число которых с течением времени только увеличивается.

Общая волна интереса к PaaS затронула и отечественный рынок: много внимания привлекла к себе новость о том, что украинско-российская команда Hivext получила 500 тыс. долл. инвестиций на развитие своих PaaS-продуктов.

В PaaS-сегменте прямая конкуренция, подобная той, что наблюдается на рынке IaaS между Amazon Web Services и Rackspace, является скорее исключением, чем правилом. Каждый PaaS-поставщик продвигает собственное уникальное платформенное решение, ориентированное на отдельный класс веб-разработчиков. В этом смысле рынок PaaS очень напоминает рынок настольных средств разработки: хотя такие среды, как Visual Studio и Eclipse, теоретически позволяют решать одни и те же задачи, на практике они предоставляют различные наборы инструментов, связанные с различными технологическими предпочтениями и, наконец, с разными привычками программистов.

Существующие сегодня PaaS-решения настолько разнообразны по характеру решаемых задач, что выделить их родовое свойство довольно трудно. Если говорить в целом, то все PaaS-решения позволяют повысить эффективность труда разработчиков приложений. Однако существует целый ряд различных подходов и инструментов для решения этой задачи. Действительно, любая PaaS-платформа позволяет создать динамический веб-сайт, но каждое отдельно взятое PaaS-решение при этом предоставляет специфические возможности и удобства. Можно указать несколько факторов, в силу которых использование PaaS-решений упрощает жизнь разработчикам. В разных PaaS-системы эти факторы по‑разному комбинируются, что позволяет удовлетворить запросы разработчиков, обладающих различными потребностями и предпочтениями.

Возможность создания масштабируемых приложений без необходимости самостоятельно поддерживать массивную вычислительную инфраструктуру.

К этой категории следует отнести прежде всего системы Windows Azure, Google, App Engine. Последняя позиционируется как система для создания веб-приложений, способных справиться со столь же массированной нагрузкой, с которой сталкиваются приложения самой компании Google. Взамен разработчики App Engine должны быть готовы на определенные жертвы, такие как освоение специфической.

Разработчик, который приступает к использованию PaaS-системы, должен быть готов к тому, что его абсолютная свобода будет ограничена. Так, не все необходимые для его приложения инфраструктурные компоненты могут быть доступны в «облаке». Например, PaaS-сервис Heroku ориентирован только на язык программирования Ruby, а «облако» Google, хотя и предоставляет разработчикам возможность выбора, ограничивает его только языками Python, Java и Go. Но даже те технологии, которые доступны в «облаке», могут предоставляться в «урезанном» виде, недостаточном для развертывания некоторых приложений. Это ограничение может быть не таким существенным, когда речь идет о создании приложений «с нуля», однако при развертывании в «облаке» системы, основанной на использовании достаточно сложных готовых компонентов (например, система документооборота Alfresco) существует высокий риск, что не все эти компоненты удастся без проблем запустить в «облаке». Кроме того, в «облаке» могут присутствовать дополнительные ресурсные ограничения, не всегда привычные для разработчиков приложений по традиционной модели. Например, один из разработчиков, испытав Google App Engine, был вынужден частично переписать свою программу из‑за 30‑секундного ограничения на выполнение процессов. Аналогичные ограничения существуют и в других PaaS-решениях.

Следует также иметь в виду, что специфика PaaS-окружения в отдельных случаях делает невозможным размещение разработанных в «облаке» приложений где‑либо, помимо «облака» конкретного поставщика. К сожалению, механизм «подсаживания на крючок» конкретной технологии в облачную эпоху не только не потерял своей актуальности, но и приобрел новые тревожные черты: по крайней мере раньше пользователи сами контролировали те компьютеры, на которых работали приложения от конкретных поставщиков, в то время как теперь и компьютеры, и приложения полностью уходят из‑под контроля, и степень необходимого доверия к поставщику существенно возрастает.

Важно и то, что привычные технологии и средства разработки могут быть заменены специальными инструментами, требующими дополнительного освоения.

И если для кого‑то усвоение подходов к программированию, диктуемых в рамках Google App Engine, — это часть профессионального удовольствия, то другие разработчики предпочтут не менять свои привычки.

Подходы к хранению данных в «облаке»

Внимание большинства разработчиков PaaS-систем в настоящее время сосредоточено на серверах приложений, веб-серверах и технологиях разработки веб-приложений. Проблеме размещения баз данных в «облаке» уделяется меньше внимания, однако едва ли это означает, что проблема масштабирования баз данных в «облаке» вообще не имеет значения. Так, Майкл Стоунбрейкер (Michael Stonebraker), признанный эксперт в области баз данных и создатель нескольких известных СУБД, включая Ingres и PostgreSQL, считает, что громоздкая система хранения данных на базе MySQL в основе популярного сервиса Facebook — это «участь, которая хуже, чем сама смерть». По сведениям Стоунбрейкера, для поддержания работоспособности Facebook в настоящее время используется 4000 сегментов MySQL и 9000 экземпляров кэширующего сервера memcached. По мнению эксперта, единственный выход из сложившейся ситуации — это переписать систему хранения данных с нуля, используя более подходящие инструменты. «Старая модель SQL ни на что не годится; ее нужно отправить в дом престарелых программных продуктов», — считает эксперт.

Несмотря на то, что большинство PaaS-поставщиков предлагают доступ к тем или иным системам хранения данных (как SQL, так и NoSQL), большая часть этих систем хранения данных не позволяет осуществлять масштабирование по мере роста объема данных в «облаке». Среди исключений можно назвать лишь такие сервисы, как Google App Engine (однако разработчики Google принесли реляционность в жертву масштабируемости) и Amazon Simple DB (также не является реляционной БД). Из поставщиков значимых реляционных СУБД пока что лишь Microsoft предприняла усилия для того, чтобы привести свою систему в соответствие с условиями облачных вычислений: их облачное предложение SQL Azure представляет собой специальную версию MS SQL Server, которая позволяет осуществлять масштабирование в «облаке» (таблица 2).

Особенности популярных облачных БД

Таблица 2.