Файл: Облачные сервисы (ОБЛАЧНЫЕ СЕРВИСЫ КАК ПЕРСПЕКТИВНАЯ ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ).pdf

Покупатель облачных сервисов должен внимательно изучить все условия SLA, чтобы знать, кто, что и когда делает, а также что, кто, за что и как отвечает в случае облачного отказа. SLA — соглашение об уровне обслуживания (англ. Service level agreement) каждого пользователя облака.

Инфраструктура как сервис (IaaS) — наиболее зрелый сегмент облачных вычислений. Именно в сегменте IaaS наиболее последовательно воплощаются классические преимущества облачных вычислений: экономия за счет эффекта масштаба (чем больше пользователей пользуется ресурсом, тем меньше эксплуатационная стоимость в расчете на одного пользователя), эластичность, модель оплаты «по счетчику» и т.д. Amazon Web Services (AWS) — наиболее известное и наиболее успешное предложение класса IaaS.[3,с.231]

Платформа как сервис

Модель предоставления платформы как сервиса (Platform as a Service, PaaS) предоставляет возможность аренды платформы, которая обычно включает операционную систему и прикладные сервисы. [6,с.50]

Платформа как сервис облегчает разработку, тестирование, развертывание и сопровождение приложений без необходимости инвестиций в инфраструктуру и программную среду. Платформа как сервис также включает и инфраструктуру как сервис. Примером платформы как сервис может служить Windows Azure компании Microsoft. [3,с.229]

Здесь потребителями являются сами компании, разработавшие приложения. Платформа обеспечивает среду для выполнения приложений, сервисы по хранению данных и ряд дополнительных сервисов, например интеграционные или коммуникационные. Соглашение о предоставлении сервисов (SLA) обычно распространяется на такие характеристики сервисов, как доступность среды выполнения приложений и ее производительность. Возможности настройки приложений под нужды потребителей практически не ограничены. [3,с.229]

Ограничением может послужить лишь функциональность сервисов, предоставляемых на уровне платформы. Для того чтобы воспользоваться возможностями облачной платформы, необходимо значительно модернизировать или вообще написать заново существующие приложения. [3,с.229]

Оплата облачной платформы рассчитывается исходя из объема использованных вычислительных ресурсов, таких как:

• время работы приложения;

• объем данных и количество операций с данными (транзакций);

• сетевой трафик.

Первым значимым предложением в сфере PaaS-решений стала система Google App Engine, представленная в апреле 2008 г. 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). Существуют также десятки менее известных систем, число которых с течением времени только увеличивается. [6,с.50]

Программное обеспечение как сервис

Модель предоставления программного обеспечения как сервиса (Software as a Service, SaaS) обеспечивает возможность аренды приложений. Программное обеспечение как сервис включает платформу как сервис и инфраструктуру как сервис. Примерами приложения как сервиса являются Business Productivity Online Suite компании Microsoft, Google Docs, а также различные системы автоматизации бизнеса класса CRM, ERP. [3,с.227]

На сегодняшний день это наиболее распространенная модель предоставления облачных сервисов. Модель предоставления программного обеспечения, как сервиса является моделью обеспечения доступа к приложениям через Интернет с оплатой по факту их использования. Организации могут реализовывать подобную модель предоставления сервиса из частных облаков, используя внутренние сетевые каналы, дополнительно защищенные и не связанные с Интернетом. [3,с.227]

Потребителями данного типа сервисов являются конечные пользователи, которые работают с приложениями, предоставляемыми в облаке. Соглашение о предоставлении сервисов (SLA) обычно распространяется на такие характеристики сервисов, как их доступность (uptime) и производительность. Возможности настройки приложений под нужды потребителей минимальны или вообще отсутствуют, их уровень диктуется требованиями рынка или возможностями поставщиков таких приложений. Оплата конечного сервиса, как правило, производится ежемесячно и рассчитывается на основе количества пользователей приложения. [3,с.227]

Решения класса SaaS — разновидность облачных услуг, появившаяся существенно раньше, чем сам термин «облачные вычисления». Из всех облачных решений только SaaS-приложения непосредственно доступны конечному пользователю, и этим они принципиально отличаются от решений класса IaaS и PaaS, которые направлены не на пользователей, а на разработчиков и владельцев IT-систем. [6,с.40]

SaaS-системы занимают устойчивые позиции в сфере корпоративных решений класса CRM и ERP. Поскольку SaaS-решением можно начать пользоваться сразу после оплаты, сроки внедрения таких систем сокращаются до предела по сравнению с традиционными аналогами, что особенно выгодно в условиях быстро растущего малого и среднего бизнеса. [3,с.228]

Особое место на российском рынке SaaS занимают отечественные решения, созданные в оглядке на потребности российского бизнеса. Такие системы лишь отчасти можно считать заменой ПО — в сущности, они решают такие задачи, которые ранее никем решены не были. Ниже рассмотрено несколько примеров практического использования отечественных SaaS-решений в российском бизнесе. [6,с.76]

Если в области корпоративных коммуникаций на российском рынке используются в целом те же решения, что и на Западе, то в сфере автоматизации бизнеса специфика российского бизнеса проявляется более ощутимо. Присутствие Salesforce.com — признанного мирового лидера в области CRM — на российском рынке ограниченно, что создало возможности для появления здесь нескольких независимых малых поставщиков, предлагающих аналогичные решения, оптимизированные для российских пользователей: Asoft CRM, qCRM, On-crm и др. Кроме того, в России довольно популярны системы с открытым кодом SugarCRM и ее форк vTiger CRM. [3,с.228]

Существенный интерес представляют решения для автоматизации бизнеса, изначально созданные для удовлетворения специфических потребностей российских пользователей. Таковы, например, онлайн-сервисы от «СКБ Контур», системы «Мое дело», «Мойсклад» и др. Если использование электронной почты по модели SaaS позволяет сэкономить на заработной плате системного администратора, то перечисленные сервисы позволяют малым компаниям экономить на зарплате бухгалтера и сотрудников, занимающихся учетом. Хотя эти системы и не могут конкурировать в полной мере с тяжеловесным бухгалтерским ПО, они позволяют решать большую часть повседневных задач, с которыми сталкиваются индивидуальные предприниматели, а также оказывают существенное подспорье бухгалтерам, работающим по совместительству. [6,с.44]

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

По словам Петра Диденко, директора по стратегическому развитию «СКБ Контур», коммерчески выигрышные программные продукты должны быть связаны с решением распространенных, но никем не решенных задач: «Чем сложнее проблема, тем больше в ней денег», — считает Петр Диденко. В своих SaaS-продуктах — «Контур-Экстерн», «Эльба» и других — «СКБ Контур» старается следовать именно этому пути, автоматизируя рутинные задачи, которые год от года отнимают десятки и сотни часов времени у десятков тысяч российских компаний. [6,с.79]

Вероятно, в будущем эта беспроигрышная стратегия будет подхвачена новыми поставщиками, и разнообразие предложений на рынке SaaS-сервисов, ориентированных на нужды российских пользователей, будет возрастать. При этом в основном выигрыше будут малые и средние компании, которые с точки зрения разработчиков более платежеспособны, чем индивидуальные предприниматели. [6,с.80]

Таким образом, среди достоинств облачных вычислений обычно выделяют следующие:

• снижение требований к вычислительной мощности персональных компьютеров (непременным условием является только наличие доступа в Интернет);

• отказоустойчивость;

• безопасность;

• высокую скорость обработки данных;

• снижение затрат на аппаратное и программное обеспечение, обслуживание и электроэнергию и другие экономические факторы. [2,с.149]

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

Во-вторых, следует отметить, что расчеты выгодности использования облаков, на основании методики, предложенной исследователями из Беркли, показали максимальную экономическую эффективность облачных приложений при их неравномерной или низкой загрузке. При достаточно высокой и равномерной загрузке (около 60-70 %) более выгодным является вариант использования собственного центра обработки данных. [8,с.108]

Некоторые из перечисленных достоинств не очевидны, а некоторые вообще проблематичны. В первую очередь проблематичным достоинством представляется безопасность. Понятно, что конфиденциальность должна обеспечиваться по всей цепочке, включая провайдера облачного решения, потребителя услуги и связывающие их коммуникации. [2,с.150]

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

1) несовершенство управления идентификацией контроля доступа;

2) слабость и отсутствие стандартов для облачных вычислений, в том числе и стандартов безопасности;

3) скрытность провайдеров и непрозрачность облачных технологий с технической и юридической точек зрения;

4) отсутствие защиты при возможности доступа к облачному сервису с любого компьютера;

5) низкая квалификация ИТ-сотрудников;

6) невозможность сохранить данные внутри страны или организовать их территориальную привязку по желанию клиента из-за перемещения виртуальных машин. [8,с.108]

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

Проведенные исследования показывают, что основными потребителями услуг информационной безопасности в России являются субъекты крупного, среднего и малого бизнеса.

Наиболее сложным для поставщиков услуг информационной безопасности (ИБ) является сегмент среднего и малого бизнеса. Основными специфическими особенностями его являются:

● непредсказуемость спроса, что связано с отсутствием системного подхода к ИБ и реакцией на уже произошедшие инциденты;

● недостаток денежных средств и квалифицированных кадров для внедрения аппаратных средств обеспечения (ИБ);

● малочисленность и несовершенство готовых технических решений для субъектов малого и среднего бизнеса. [8,с.111]

Все механизмы для уменьшения рисков ИБ сводятся к ликвидации рисков утечки информации путем сокращения не декларированных возможностей или их отслеживания:

● ИТ-консалтинг – передача функций обеспечения ИБ специализированным организациям, обладающим большими финансовыми и аппаратными возможностями в этой области;

● предотвращение рисков утечки информации на стадии разработки включает распределенный цикл разработки программного продукта и сканирование программного кода;

● сертификация программных продуктов – недостатком данного метода является длительность и высокая стоимость процесса сертификации (особенно если версии программного продукта часто обновляются в связи, например, с изменением законодательства);

● информационный аудит - имеет смысл проводить только после проведения адаптации программного продукта к потребностям клиента, т. е. является кратковременной мерой, к тому же обладает теми же недостатками, что и сертификация. [8,с.112]