Вы находитесь на странице: 1из 138

Все права защищены.

Данная электронная книга предназначена исключительно для

частного использования в личных (некоммерческих) целях. Электронная книга, ее

части, фрагменты и элементы, включая текст, изображения и иное, не подлежат

копированию и любому другому использованию без разрешения правообладателя. В

частности, запрещено такое использование, в результате которого электронная книга,

ее часть, фрагмент или элемент станут доступными ограниченному или

неопределенному кругу лиц, в том числе посредством сети интернет, независимо от

того, будет предоставляться доступ за плату или безвозмездно.

Копирование, воспроизведение и иное использование электронной книги, ее частей,

фрагментов и элементов, выходящее за пределы частного использования в личных

(некоммерческих) целях, без согласия правообладателя является незаконным и влечет

уголовную, административную и гражданскую ответственность.


Вступительное слово

Перед прочтением этой книги задайте себе вопрос: знаете ли вы,

что такое облака? Если в первую очередь вам пришло на ум

облачное хранилище файлов, то вы правы. Но это лишь малая

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

бизнеса, но и для частных пользователей. Предприятия с

помощью «облаков» могут как создавать удаленные рабочие

места и виртуальные сети, так и помогать тестировать и

разрабатывать приложения в облачных средах, использовать

технологии машинного обучения. Облачный рынок даже во

время кризиса и пандемии Covid-19 не потерял высоких темпов

развития.

Вокруг темы «Облачные технологии» до сих пор ходит

достаточно много мифов и домыслов. К сожалению, нельзя

сказать, что книжный рынок изобилует современными

изданиями, где простыми словами объясняется самая суть

облаков.

Компания SberCloud — один из российских и достаточно

известных облачных провайдеров — создана в январе 2019 года.

Мы неоднократно получали награды, в том числе,

международные, за свои продукты и решения. Мы предоставляем

облачную IT-инфраструктуру в аренду, предлагаем 50+

платформенных сервисов, а также являемся разработчиком

самого мощного в России суперкомпьютера Christofari,

доступного из облака, и платформы ML-разработки — ML Space.

Наши услуги популярны как среди бизнеса и государственных

организаций, так и среди физических лиц.


Принимая участие в новом для нас проекте, мы использовали

нашу накопленную экспертизу в области облачных технологий,

чтобы в легкой, интересной, а главное правильной форме донести

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

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

чтивом для любителя новых технологий, а эксперт, надеемся,

также найдет в ней что-то полезное для себя. Приятного чтения!


Предисловие

Как исследователь в различных областях, получивших одну лишь

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

очевидно, что мы еще долгое время будем продолжать движение

по пути открытий и разработки новых инструментов и сервисов.

С появлением ПК мы отошли от такой исторической парадигмы,

как мейнфрейм, затем последовательно переходили на все более

мощные рабочие станции, универсальные

высокопроизводительные вычисления, распределенные

вычисления, и теперь — в «облако». Справедливости ради, одним

из недостатков таких изменений является то, что сторонники

этих новых архитектур зачастую подают последнюю парадигму

как наилучшую практически во всех отношениях, а значит, она

должна заменить все предыдущие архитектуры, переводя

пользователей на новейшие, величайшие и наилучшие системы.

Это явно не тот случай, когда шумиха не имеет значения, и

потому предназначением данной книги можно считать

просвещение читателя: в каждой работе должен использоваться

свой, подходящий именно ей инструмент.

Читая эту книгу, я был поражен разнообразием целевой

аудитории в предметной области; это к лучшему, потому что

сообщества практикующих специалистов, которым так важно

использовать облачные технологии, найдут для себя подходящие

примеры. Однако я также очень надеюсь, что книгу прочитает

еще одна группа — руководители проектов или старшие

преподаватели: книга должна стать для них обязательной к

прочтению. Наряду с выполнением традиционных функций они

сегодня несут и юридическое обязательства — по соблюдению


требований об открытости данных и воспроизводимости; для

этих целей как раз подходит перенос сервисов в облако и

хранение в нем данных. Кроме того, следует понимать

преимущества и, что не менее важно, проблемы, которые может

принести облачная стратегия.

Работая с Хуаном и Диего еще до написания этой книги, мы

уделили немало времени проработке различных моделей

применения IaaS в сфере наук об окружающей среде, и в

частности — о климате. Следовательно, многие замечания,

сделанные в книге, были выработаны авторами на практике, а не

в ходе теоретических изысканий. Помимо этого, с учетом моего

опыта разработки общеевропейских федеративных облачных

сервисов для исследований, я отчетливо вижу, что уроки об

особенностях использования облака, извлеченные в том числе из

неудач, можно было усвоить быстрее и легче, если бы тогда

существовал подобный текст, которым мы могли бы поделиться с

пользователями. Я считаю также, что эта книга будет крайне

полезна не только тем исследователям, кто со временем станет

пользователем крупных публичных облачных служб, но и тем, кто

выберет облачный проект European Open Science Cloud, который

становится все более популярным инструментом среди

европейских исследователей.

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

мысль: в динамичном и изменчивом мире облачных вычислений

все устаревает крайне быстро. Примеров тому предостаточно;

однако вот что важно: наличие различных моделей

развертывания облачных вычислений означает, что, описывая

свой метод использования облака, двое исследователей отнюдь не

обязательно говорят об одном и том же. Вот почему необходимо

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

вычислений, как это сделано в начале данной книги. В

заключение добавлю: как только читатели поймут, как можно

использовать в их исследованиях облачные вычисления, им не


мешает сделать паузу в чтении и поразмыслить над тем, как они

хотели бы двигаться вперед с облачными решениями, проведя

тесты и убедившись, что они действуют в соответствии с

обоснованными научными и техническими принципами

развертывания сервисов в облаке. Да, облако не палочка-

выручалочка, но в долгосрочной перспективе при грамотном

развертывании может ощутимо упростить все процессы.

Профессор Дэвид Уоллом

доцент и заместитель директора по инновациям Оксфордского

центра электронных исследований,

Оксфорд, Великобритания
Введение

Эту книгу мы написали для ученых, инженеров и для всех, кто

хочет ближе познакомиться с облачными вычислениями, чтобы

узнать о них больше или оценить облако как альтернативное или

дополнительное решение для собственных вычислительных

потребностей. Кроме того, книга может быть полезна ИТ-

специалистам, например архитекторам программных решений,

желающим быть в курсе текущих и будущих потребностей

научного сообщества, а также понимать, как можно

удовлетворить их с помощью облачных технологий — и как

следствие предлагать своим клиентам более подходящие

решения. Таким образом, этот текст может стать своеобразным

мостом между видением пользователя и поставщика.

В этой книге мы попытались дать общее представление о

современном состоянии облачных вычислений. Текст может

послужить вводным курсом для выпускников, студентов

магистратуры и аспирантов, обучающихся любым дисциплинам:

он даст представление о потенциальных возможностях

использования облачных технологий и о том, как они могут

помочь в разработке проектов и будущей работе.

Хуан Аньель

Диего Монтес

Хавьер Родейро Иглесиа

Оренсе, Испания

Ноябрь 2019 г.
Благодарность

Эту книгу мы хотели бы посвятить нашим семьям и друзьям за их

ежедневную поддержку и понимание, позволяющие нам отдавать

себя исследовательской работе, что слишком часто происходит за

счет времени, которое мы могли провести с ними.

Кроме того, мы хотим поблагодарить Springer за интерес к

этой книге и возможность опубликовать ее, и особенно Закари

Романо, нашего ответственного редактора, а также редакторскую

службу AJE. Особая благодарность Пауло Родригесу из Dropbox за

полезные дискуссии и содействие в работе, за внесенный в эту

книгу вклад. Кроме того, мы хотели бы поблагодарить Google

Enterprise, Microsoft Research и Amazon Web Services за

предоставленные вычислительные ресурсы и техническую

поддержку для проведения экспериментов с использованием их

облачных платформ. Том Грей, Барак Регев и Шайлеш Рао из

Google, Кендзи Такеда из Microsoft Research — мы выражаем вам

глубокую признательность. Также мы благодарим коллег из Clima

tePrediction.net в Оксфордском университете, особенно Дэвида

Уоллома, всех сотрудников Галисийского центра

суперкомпьютерных вычислений (CESGA), в частности Карлоса

Фернандеса, а также Томаса Фернандеса Пену из Университета

Сантьяго-де-Компостела.

Мы благодарим преподавателя кафедры физиологии

Университета Сантьяго-де Компостела Сулаю Тóвар и профессора

Хосе Агустина Гарсию из Университета Эстремадуры за отзывы о

черновых версиях этой книги. Кроме того, мы выражаем

признательность Александре Иглесиас за ее вклад в дизайн

обложки.
Часть исследований, проведенных в течение многих лет и

позволивших нам накопить знания для создания этой книги,

финансировались различными агентствами и учреждениями, в

т.ч. Европейским фондом регионального развития (ERDF). Кроме

того, в последние годы Хуану Аньелю была оказана поддержка в

виде гранта Рамона-и-Кахаля от правительства Испании (RYC-

2013–14560).
Список сокращений

AI Artificial Искусственный интеллект

Intelligence

API Application Программный интерфейс приложения

programming

interface

AWS Amazon Web Облачный сервис; коммерческое публичное облако,

Services поддерживаемое Amazon

BOINC Berkeley Open Открытая программная платформа университета Беркли;

Infrastructure for некоммерческое межплатформенное ПО для организации

Network распределенных вычислений

Computing

CDC USA Centers for Центры по контролю и профилактике заболеваний США

Disease Control

and Prevention

CERN Conseil Européen Европейская организация ядерных исследований (ЦЕРН)

pour la Recherche

Nucléaire

CLI Command Line Интерфейс командной строки

Interface

CNCF Cloud Native Фонд, созданный при поддержке Linux Foundation для

Computing разработки и продвижения облачных технологий

Foundation

DoD US Department of Министерство обороны США

Defense

EC2 Elastic Cloud Один из сервисов AWS, позволяющий пользователю

Compute арендовать виртуальный сервер с настраиваемым объемом

ресурсов

ERP Enterprise Планирование ресурсов предприятия; ПО для управления

Resource Planning бизнес-процессами

ESA European Space Европейское космическое агентство (ЕКА)

Agency
EU European Union Европейский союз

FaaS Function as a «Функция как услуга»

Service

FDA U.S. Food and Управление по санитарному надзору за качеством пищевых

Drug продуктов и медикаментов США

Administration

FMI Finnish Финский метеорологический институт

Meteorological

Institute

GCP Google Cloud Набор облачных служб, предоставляемый Google

Platform

GCS Google Cloud Служба хостинга файлов в инфраструктуре GCP

Storage

GPL GNU Public Генеральная общедоступная лицензия GNU, проекта по

License разработке свободного ПО

HIPAA Health Insurance Закон о медицинском страховании и обмене

Portability and идентификационными данными участвующих при этом

Accountability Act сторон

HIV Human Вирус иммунодефицита человека, ВИЧ

Immunodeficiency

Virus

HPC High performance Высокопроизводительные вычислительные системы

computing

HPCaaS HPC as a Service «Суперкомпьютер как услуга»

IaaS Infrastructure as a «Инфраструктура как услуга»

Service

IOPS Input/output Количество операций ввода-вывода в секунду

operations per

second

IoT Internet of Things Интернет вещей

IRC Internet relay chat Протокол прикладного уровня для обмена сообщениями в

режиме реального времени

IT Information Информационные технологии (ИТ)

Technologies

JPL Jet Propulsion Лаборатория реактивного движения, NASA

Laboratory

JSON JavaScript object Текстовый формат обмена данными

notation
Met United Kingdom’s Главная метеорологическая служба Великобритании

Office National Weather

Service

MPI Message Passing Программный интерфейс для передачи информации

Interface

NAS Network Attached Сервер для хранения данных на файловом уровне

Storage

NASA National Национальное управление по аэронавтике и исследованию

Aeronautics and космического пространства, США

Space

Administration

NOAA USA National Национальное управление океанических и атмосферных

Oceanic and исследований, США

Atmospheric

Administration

NREL National Национальная лаборатория по изучению возобновляемой

Renewable Energy энергии

Laboratory

OS Operating system Операционная система (ОС)

PaaS Platform as a «Платформа как услуга»

Service

POSIX Portable Набор стандартов, описывающих интерфейсы между ОС и

Operating System прикладной программой, библиотеку языка С и набор

Interface приложений и их интерфейсов

PUE Power Usage Эффективность использования электроэнергии

Effectiveness

RAM Random-Access Запоминающее устройство с произвольным доступом

Memory

S3 AWS Simple Веб-служба файлового хостинга, предоставляемая AWS

Storage Service (Amazon)

SaaS Software as a «ПО как услуга»

Service

SDK Software Набор средств разработки, позволяющий создавать

Development Kit приложения для определенного пакета программ, ПО

базовых средств разработки, аппаратной платформы,

компьютерной системы, игровых консолей, ОС и прочих

платформ

SEO Search Engine Поисковая оптимизация

Optimization
SSD Solid-State Drive Твердотельный накопитель

SSL Secure Sockets Криптографический протокол, обеспечивающий

Layer безопасную связь

TLS Transport layer Криптографический протокол на транспортном уровне

security

UI User Interface Пользовательский интерфейс (ПИ)

VPC Virtual private Виртуальное частное облако

cloud

VPN Virtual private Виртуальная частная сеть

network

VPS Virtual private Виртуальный выделенный сервер

server
ГЛАВА 1

Почему вам нужна эта книга?

Активное использование компьютеров в научных целях

постоянно стимулировало развитие технологий. В

исследовательской работе компьютеры используются по-разному,

но наиболее востребованными их функциями являются хранение

данных и высокопроизводительные вычисления (HPC). При

таком использовании наличие сетевого оборудования всегда

являлось обязательным требованием; однако оно потеряло

актуальность с развитием концепции облачных вычислений в

последнее десятилетие и внесерверной обработки данных в

1
последние годы. И действительно, отчет проекта top500.org

гласит: за период 2016–2017 гг. рынок HPC вырос примерно на

1,6%, тогда как использование облачных HPC-сервисов возросло с

7 до 44%. Скорее всего, объяснить эту разницу можно тем, что

HPC как услуга (HPCaaS) используется для дополнения ресурсов

локальных инфраструктур HPC, когда таких ресурсов

недостаточно для удовлетворения нужд пользователя. Это,

пожалуй, одна из самых привлекательных особенностей

облачных вычислений, стимулирующая их использование в

исследованиях: удовлетворение потребности в вычислительных

ресурсах при реализации тех или иных проектов.

Облачные вычисления уже более десяти лет являются широко

распространенной и внедряемой ИТ-отделами технологией.

Приложения, решения и варианты практического применения

облачных вычислений исследуются повсеместно. Однако далеко

не всегда пользователи имеют полное представление об их


потенциале, вариантах использования, устройстве и ситуации на

рынке в целом. Так, они могли ознакомиться с основными

характеристиками компьютера, ноутбука, рабочей станции и т.д.

и получить общее представление о том, какими функциями они

будут располагать при наличии такой технологии, а также о том,

какую из технологий выбрать в соответствии с памятью или

процессором своего устройства. Однако все это — пока не

облачные вычисления. Многие еще просто-напросто не

приспособились к этой новой парадигме, что привело к пробелу в

знаниях между преобладающей сегодня технологией и тем, к

чему привыкли пользователи. Тем не менее, мы все чаще

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

так и для развлечений, например, открывая приложение на

смартфоне. Также это касается и тех, кто работает в науке,

занимается изысканиями, возглавляет лаборатории или

исследовательские центры — вплоть до первых лиц. Все они могут

получить весомые преимущества, если хотя бы частично

задействуют облачные решения, как будет рассказано и показано

на примерах далее. Они применимы практически к любой

научной дисциплине. Что касается руководителей высокого

уровня, то им, возможно, придется рассмотреть вопрос о переходе

ИТ-инфраструктуры на облачные технологии; и, конечно, они

захотят больше узнать о последствиях такого перехода. Отчет

компании The Economist Intelligence Unit за 2016 г. содержал

дискуссию о том, как недостаток знаний и недоверие становятся

2
барьерами для внедрения облачных вычислений . И хотя сегодня

эти показатели, скорее всего, улучшились, недавний опрос

Евростата показал: всего 28% европейских предприятий

используют облачные технологии, а их более широкое внедрение

3
ожидается только в будущем .

Бессерверные вычисления — своего рода эволюция облачных:

эта еще более свежая концепция призвана повысить уровень

абстрагирования для пользователей, для которых вопрос


используемой ими вычислительной инфраструктуры станет не

так уж важен.

Что до тех, кто финансирует исследования, то как

государственные, так и частные организации изучали и

применяли облачные решения в инфраструктуре и проектах, в

которые вкладывались. Достигнуть этого можно разными путями:

например, через развертывание облачной инфраструктуры с

использованием общедоступных HPC-центров или

предоставление ваучеров на использование ресурсов облачных

вычислений от коммерческих поставщиков вместо того, чтобы

выделять время общедоступных высокопроизводительных

вычислительных центров.

Еще один довод в пользу широкого использования и

внедрения облачных технологий: они предоставляют прекрасную

возможность для демократизации развития научных

исследований, так как отменяют необходимость создавать и

обслуживать собственные HPC-центры. Это особенно важно для

финансирующих научные изыскания организаций,

исследователей и лабораторий, не имеющих доступа к таким

центрам, а также тех, кто получил финансирование под

конкретный ограниченный во времени проект и не хочет

вкладывать средства в покупку и обслуживание оборудования,

которое устареет или не будет использоваться в будущем.

Потенциал этой технологии огромен: она устраняет препятствия

для исследований в самых неблагополучных странах и уголках

планеты, т.е. там, где инфраструктура для проведения научно-

исследовательских и опытно-конструкторских работ развита

недостаточно.

Что немаловажно, существует возможность объединить

облачные вычисления с другими технологиями, такими как

большие данные и машинное обучение, для повышения

продуктивности научных исследований. Подобная интеграция

позволит использовать комбинацию таких функций, как


хранение данных или реализация моделей в облачных системах,

что обеспечит прямой доступ к готовым решениям, уже

реализованным поставщиком и полностью адаптированным к

среде облачных вычислений. Тем самым будет снижена

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

адаптации или настройке сервисов. Интеграция функций

упрощает анализ, интерпретацию и представление данных,

хранящихся в облаке, и создает большой потенциал для

получения новых, порой неожиданных результатов и

достижений. Подход, при котором происходит эффективная

комбинация этих методов, получил название «облачного

4
датамайнинга» .

Еще одно преимущество комбинации всех этих технологий

состоит в том, что она предлагает способ реализовать сценарий

«нулевой загрузки», решая одну из насущных проблем, связанных

с доступностью исследовательских данных, — чрезмерное

количество и объем запросов на загрузку, для обслуживания

которых требуются огромные хранилища данных. Для некоторых

ученых, лабораторий и областей исследований этот подход стал

практически культурной революцией: отказ от загрузки данных

для локальных вычислений и переход к выполнению вычислений

в облаке с загрузкой лишь окончательных результатов.

Наконец, если рассматривать технологии с точки зрения

рынка труда, то предложения о работе на руководящих

должностях в сфере научных вычислений отражают

существующее движение к облачным технологиям. Причем

особенно подчеркивается, что соискатели должны обладать

знаниями, позволяющими управлять частной и публичной

облачной инфраструктурой. На этом этапе тем, кто трудится в

сфере науки и исследований, необходимо как можно скорее

получить полное представление об экосистеме облачных

вычислений, о сложностях работы с ней и возможностях, которые


она предлагает для расширения научных изысканий,

оптимизации расходов и воздействия на окружающую среду.

Итак, книга, которую вы держите в руках, призвана

рассмотреть все перечисленные вопросы, заполнить пробелы и

представить данные, которые позволят точнее определить, какую

выгоду может принести переход на облачные вычисления. Если

вы — глава исследовательского центра или ученый,

использующий вычислительные ресурсы, но обладающий лишь

поверхностными знаниями об облачных и бессерверных

технологиях (или вовсе ничего о них не знающий), сотрудник ИТ-

отдела лаборатории или поставщик ИТ-технологий, надеемся, эта

книга станет для вас кратким и полезным руководством к

действию.
ГЛАВА 2

Зачем нам облако?

2.1. Введение

Пользователи выбирают облачные технологии по разным

причинам. В некотором смысле решение о переходе на облако

зависит от того, планируете ли вы использовать его для

высокопроизводительных вычислений (HPCaaS), хранения

данных или просто для размещения адаптивных веб-сервисов

(IaaS) или для выполнения менее сложных задач, например

организации производственной деятельности (электронная

почта, написание кода и т.д.). В любом из этих случаев облачные

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

использовать менее мощные компьютеры и снизить затраты на

содержание помещения для лаборатории. Кроме того, ваш ИТ-

отдел сможет сосредоточиться на работе на перспективу (на

программировании, повышении вычислительной эффективности

вашей повседневной работы и т.д.), вместо того чтобы тратить

время на решение проблем с обслуживанием оборудования.

Продвигая переход на облачные технологии в

исследовательских процессах, поставщики подчеркивают такие

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

вычисления в считанные минуты обеспечат доступ к тому, что в

противном случае заняло бы недели, включая заказ нового

оборудования, его получение, установку ПО и проведение

экспериментов. Кроме того, будут снижены затраты (вы

заплатите только за то, чем фактически пользуетесь, а не за время


простоя) и достигнуто гибкое расходование ресурсов: у вас

появится возможность адаптировать свой проект под выделенный

бюджет. Примером последнего может стать проведение

экспериментов только тогда, когда их стоимость оказывается

ниже установленного ранее порога, или наоборот, возможность

проводить неограниченное количество опытов одновременно и

выбирать компьютеры с большей производительностью, если вы

торопитесь из-за горящих сроков. Еще одним фактором является

безопасность, которая по данным поставщиков облачных

решений, находится на высшем уровне, заметно превосходящем

возможности собственных ИТ-подразделений большинства

лабораторий: наличие отдела, специализирующегося на

безопасности, пока не является общим стандартом.

Еще одним доводом в пользу внедрения облачных вычислений

в научную сферу является расширение научного сотрудничества,

развитие совместных исследований и инноваций. Если вы

располагаете инструментами, моделями или данными, которыми

хотел бы воспользоваться коллега с другого конца света, вам не

нужно ничего отправлять и ждать, пока не осуществится

длительная передача данных или что-то в этом роде.

Использование облачного хранилища позволит вам просто

поделиться копией, а все сопутствующие расходы, связанные с

работой коллеги, покроет он сам.

Таким образом, вы можете больше не беспокоиться об оплате

физических носителей данных (диски и т.п.), стоимости доставки,

таможенных сборов и налогов.

Кроме того, облачные вычисления могут сэкономить время

конечного пользователя, которому больше не придется

заботиться о вопросах обновления ПО, совместимости или

исправления уязвимостей. Вы получите исчерпывающую

информацию об этом, а плюс к тому — постоянный доступ,

например, к нескольким версиям одного и того же ПО: вы


сможете использовать ту, которая соответствует вашим

потребностям в каждом конкретном случае.

2.2. Потребности и нужды

Эта глава ориентирована на технически неподготовленных

пользователей: здесь мы рассмотрим типичные примеры или

общие стратегии, которые такой пользователь может найти в

интернет-поисковике, введя запрос, связанный с облачными

вычислениями. Мы перечислим основные требования для работы

в облаке, например, хорошее интернет-соединение с

необходимой пропускной способностью и ПК с мощностью,

достаточной для запуска всех сервисов, которые могут

потребоваться. Эти два пункта — необходимые требования для

доступа к услугам и продуктам на удаленных серверах или

инфраструктуре.

Все эти вопросы мы рассмотрим на примере Саши — человека,

которого могли бы встретить где угодно, хоть сегодня на

утренней прогулке. Саша может заниматься чем угодно и ставить

перед собой в профессии любые цели, и мы попытаемся

рассмотреть, как облачные вычисления могут помочь Саше их

достичь. Вот какие сценарии мы разберем:

У Саши есть небольшой бизнес или он самозанятый,

работает из дома.

У Саши есть бизнес с множеством сотрудников, клиентов

или поставщиков, и всем им необходимо каждый день

выполнять множество операций.

Саша руководит лабораторией и работает с другими

исследователями.

У Саши есть идея, как автоматизировать процесс

выставления счета клиентам.


Саше необходима мобильность.

2.2.1. Саша работает из дома или владеет собственным

бизнесом

Предположим, вы — Саша, профессионал, работающий из дома.

Вы занимаетесь разработкой компьютерных приложений, пишете

исходные коды и составляете технические руководства для

клиентов, обрабатываете множество документов и черновых

версий, а также часто общаетесь с поставщиками и клиентами.

Саша мог бы наладить систему для работы из дома:

оптоволоконное подключение к Интернету, сервер, файловое

хранилище, Git-сервер для отслеживания и ведения истории

изменения файлов проекта, приложение для видеоконференций,

систему резервного копирования и т.д. Однако у Саши есть время

только на собственную работу; на управление системой и ее

поддержку его не хватает. Кроме того, на данный момент у Саши

нет средств на покупку всей необходимой техники. В довершение

всего Саша не профессионал в сфере ИТ: он просто хочет

сосредоточиться на выполнении своих задач (см. таблицы 2.1, 2.2,

2.3 и 2.4).

Если Саша не захочет тратить деньги на всю эту

инфраструктуру, то может попробовать бесплатные инструменты,

доступные в облаке. Понятно, что как профессионал Саша хотел

бы иметь все технологические возможности для работы; однако

вряд ли все их можно получить бесплатно.

Рассмотрим альтернативы каждой из необходимых Саше

5
технологий .

2.2.2. Саша как предприниматель

У Саши есть некоторое количество сотрудников; его бизнес

предполагает взаимодействие с клиентами и поставщиками.


Саше нужно выставлять счета, планировать расходы и

обмениваться информацией по отгрузке и доставке с клиентами и

поставщиками. Кроме того, для отслеживания доставок клиентам

Саше нужны сведения о логистике и оплатах счетов.

1. Google Drive Cloud Storage (2019) https://www.google.com/drive/. По состоянию на

30 октября 2019 г.

2. IDrive (2019) https://www.idrive.com/pricing. По состоянию на 30 октября 2019 г.

3. Mega Cloud Storage (2019) https://mega.nz/. По состоянию на 30 октября 2019 г.

4. One Drive Cloud (2019) https://onedrive.live.com/about/en-gb/. По состоянию на 30

октября 2019 г.

5. Box Cloud Storage (2019) https://www.box.com/en-gb/pricing/individual/. По

состоянию на 30 октября 2019 г.

6. ICloud Cloud Storage (2019) https://support.apple.com/es-es/HT201238/. По

состоянию на 30 октября 2019 г.

7. GitHub (2019) https://github.com/pricing#feature-comparison/. По состоянию на 30

октября 2019 г.
1. GitHub (2019) https://github.com/pricing#feature-comparison/. По состоянию на 30

октября 2019 г.

2. Там же.

3. GitLab (2019) https://about.gitlab.com/pricing/. По состоянию на 30 октября 2019 г.

4. Там же.

5. Там же.

6. Там же.
7. Bitbucket (2019) https://bitbucket.org/product/pricing/. По состоянию на 30 октября

2019 г.

8. Там же.
1. Bitbucket (2019) https://bitbucket.org/product/pricing/. По состоянию на 30 октября

2019 г.

Саше необходимы информационные системы для хранения и

управления всей информацией по операциям с клиентами и

поставщиками. Эти системы должны предлагать клиентам

безопасную, надежную и удобную платформу для совершения

покупок и отслеживания статуса поставок. Более того, они

должны предоставлять актуальные данные о том, как совершается

каждая продажа, а также о привычках и предпочтениях клиентов,

чтобы Саша мог предлагать им новые продукты. Поставщики же

должны иметь возможность отслеживать статус заказов,

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

отчетность относительно платежеспособности.


1. Skype (2019) https://www.skype.com/. По состоянию на 30 октября 2019 г.

2. Там же.

3. GoToMeeting (2019) https://www.gotomeeting.com/es-es/meeting/pricing-ma/. По

состоянию на 30 октября 2019 г.

4. Zoom (2019) https://zoom.us/pricing/. По состоянию на 30 октября 2019 г.

5. Webex (2019) https://www.webex.com/es/pricing/index.html. По состоянию на 30

октября 2019 г.
1. BACKBLAZE (2019) https://www.backblaze.com/backup-pricing.html. По состоянию на

30 октября 2019 г.

2. CARBONITE (2019) https://www.carbonite.com/backup-software/buy-carbonite-safe/.

По состоянию на 30 октября 2019 г.

3. Там же.

4. Там же.

5. CRASHPLAN (2019) https://www.crashplan.com/en-us/pricing/. По состоянию на 30

октября 2019 г.

6. Livedrive (2019) https://www2.livedrive.com/ForHome/. По состоянию на 30 октября

2019 г.

7. Там же.

8. IDrive (2019) https://www.idrive.com/. По состоянию на 30 октября 2019 г.

9. Там же.

10. Там же.

У Саши есть несколько вариантов, как получить эти услуги. С

одной стороны, он может создать соответствующую

инфраструктуру на собственной территории. Однако


приобретать, настраивать и обслуживать собственные серверы

Саша не хочет. Есть другой вариант: арендовать облачный сервер

и установить на нем все сервисы. Однако, как и в предыдущем

случае, Саша не хочет заниматься настройкой и обслуживанием

сервисов. Последний вариант — нанять разработчика (ERP или

торговой площадки). Так Саша и поступает. Следовательно,

единственное, что теперь нужно сделать — это внести данные в

систему и предоставить доступ клиентам и поставщикам, чтобы

они могли работать непосредственно в своей информационной

системе. Теперь вся бизнес-информация Саши находится в

облаке, что дает такие преимущества, как резервное

копирование, бесперебойные системы, гарантирующие

постоянную доступность сервиса или круглосуточную

техническую поддержку.

При найме разработчика Саша может выбирать между

несколькими вариантами в зависимости от объема работы и

количества функций. Конечно, затраты будут расти по мере

увеличения объема. Внедряя информационную систему,

компания должна иметь возможность выйти на рынок с

соответствующим имиджем, набором важных элементов,

включающих фирменный дизайн, комплект программ для

осуществления бизнес-функций, интеграцией функциональных

возможностей и импортом данных, а также приобрести услуги

хостинга, включающие домен и использование SEO-технологий

для лучшего позиционирования в поисковых системах Интернета.

В таблицах 2.5 и 2.6 вы найдете примерные затраты на

строительство указанной инфраструктуры.


1. WebsiteBuilderExpert (2019) https://www.websitebuilderexpert.com/building-websites/

howmuch-should-a-website-cost/. По состоянию на 30 октября 2019 г.

1. OuterBox (2019) https://www.outerboxdesign.com/web-design-articles/ecommerce_we

bsite_pricing. По состоянию на 30 октября 2019 г.

2.2.3. Саша в своей лаборатории

Теперь давайте предположим, что Саша — исследователь в

специализированном центре, располагающем бюджетом для

покрытия потребностей лаборатории. Допустим, проводимые

Сашей изыскания дают большие объемы информации, которую

необходимо обработать для извлечения данных. Для хранения и


обработки информации, как и для доступа к ней в любое время,

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

предполагаем, что лаборатория располагает подключением к

Интернету и достаточной пропускной способностью сети,

позволяющей получить доступ к услугам за пределами

лаборатории. Информатика не является Сашиной

специализацией, и он не может (и не хочет) строить

инфраструктуру для обработки данных. Вопрос их хранения мы

подробно рассмотрели в первом примере из этой главы; теперь

же сосредоточимся на необходимости обработки информации.

Для анализа данных Саша мог бы арендовать виртуальный

сервер, как выделенный, так и нет: это решение можно

реализовать на нескольких уровнях. На самом нижнем Саша мог

бы арендовать виртуальный сервер без предварительной

настройки, однако это потребует последующей настройки всех

без исключения систем на виртуальном сервере (такой вариант

именуется IaaS — «инфраструктура как услуга»). На более

высоком уровне Саша мог бы арендовать сервер с частично

предварительно настроенной системой, после чего донастроил бы

все необходимое (это PaaS — «платформа как услуга»). Еще

одним решением для Саши стал бы виртуальный сервис с

6
полностью настроенной системой (SaaS — «сервис как услуга») .

Все, что ему останется сделать, — это подготовить и выполнить

процесс обработки данных.

На стоимость аренды подобных серверов влияет ряд факторов.

Количество ядер: определяет, сколько процессов могут

одновременно выполняться на сервере.

Тип и объем хранилища: чем выше скорость доступа и чем

больше объем хранилища, тем выше стоимость аренды

сервера.

Специализированная RAM-память: чем больше у

виртуального сервера оперативная память, тем меньше


времени требуется для доступа к диску и тем быстрее

выполняется обработка.

Пропускная способность: чем она выше, тем меньше

времени требуется для передачи данных между

лабораторией и виртуальным сервером (это время зависит

также от пропускной способности лабораторной сети).

Тип поддержки: круглосуточная поддержка всегда

обходится дороже.

Цифровой сертификат (TLS): наличие этого сертификата,

гарантирующего защиту информации, обмен которой

происходит между виртуальным сервером и компьютерами,

увеличивает стоимость аренды.

Как мы уже говорили, Саша может выбирать между

управляемым и самоуправляемым сервером. Виртуальный сервер

второго типа настраивает сам пользователь (а Саша, как мы

помним, делать этого не хочет). Самоуправляемый виртуальный

сервер включает в себя утилиты, облегчающие работу с ним для

не самых продвинутых пользователей. Например:

автоматическую быструю установку ПО;

управление сервером и обновления безопасности;

возможность настраивать электронную почту, базы данных

и домен через панель управления;

бесплатный частный сертификат SSL и автоматическое

резервное копирование.

В таблице 2.7 представлены примеры существующих на рынке

решений и их сравнительная стоимость.


1. Hosting Facts (2019) https://hostingfacts.com/best-vps-hosting-review/. По состоянию

на 30 октября 2019 г.

Знак вопроса означает, что хранилище предположительно

реализовано на SSD, однако это не обозначено поставщиком.

2.2.4. У Саши есть идея

Саша задумал упростить бюрократические процессы в своей

лаборатории и повысить эффективность исследований. Он хочет

автоматизировать процесс составления заказов на контракты со

спонсорами и закупку материалов, что делалось вручную. Для

этого Саша разработал сервис MyBillProcess. С его помощью

зарегистрированный пользователь может, сфотографировав

рукописный заказ, отправить его в электронном виде из любой


точки мира. Уникальность сервиса состоит в том, что при

сканировании изображения заказа MyBillProcess распознает все

данные клиента, посредника или поставщика, а также продукты и

их количество в заказе. Зарегистрированный пользователь

получает доступ к каталогу лаборатории, в том числе к перечню

услуг, результатам исследований, примерам работ и перечню

достижений — ко всей необходимой информации, в том числе к

сведениям о наличии материалов. Сервис MyBillProcess

использует распознанные сведения для создания цифрового

заказа, включающего данные о продуктах, которыми

зарегистрированный пользователь располагает в системе, и

отправляет заказ в офис, конкретному лицу или подразделению

лаборатории. Сервис MyBillProcess использует отсканированные и

другие данные для создания профилей, возможных офферов или

информационных рассылок, которые можно отправлять

заинтересованным лицам по электронной почте, чтобы повысить

их вовлеченность и прорекламировать успехи лабораторных

исследований.

Как и в приведенных ранее примерах, для воплощения своей

идеи Саша мог бы выстроить физическую инфраструктуру,

однако он не обладает соответствующими знаниями и не хочет ни

покупать, ни настраивать необходимые компоненты. Его идея

хороша, но требует реализации на виртуальном сервере (как и в

предыдущих разделах). Внедрение системы повлечет за собой

наем опытного персонала, который займется ее разработкой и

тестированием. Кроме того, эти сотрудники могли бы создавать

или арендовать дополнительные сервисы, задействованные в

реализации Сашиной идеи. Примером такой интеграции может

7
послужить Mailchimp , онлайн-сервис, позволяющий отправлять

автоматические сообщения по личной или корпоративной

электронной почте — осуществлять информационные рассылки и

устраивать кампании, нацеленные на заинтересованных лиц.

Среди прочего Mailchimp предоставляет возможность


импортировать контакты, с которыми вы хотите поддерживать

связь по электронной почте, сегментировать их списки и

внедрять формы в электронные письма. Mailchimp также может

быть интегрирован более чем с двумя сотнями сервисами в

различных бизнес-категориях (см. табл. 2.8).

1. Mailchimp (2019) https://mailchimp.com/. По состоянию на 30 октября 2019 г.

Как показывает пример Mailchimp, затраты варьируются в

зависимости от удовлетворяемых требований пользователя.

Прибегнув к услугам Mailchimp, как и любого другого сервиса

рассылок, Саша должен будет включить его стоимость (как

правило, помесячную) в стоимость своей услуги (как правило,

тоже помесячную). Успех Сашиной идеи будут оценивать с точки

зрения инновационности, экономии, полученной за счет

снижения бюрократического бремени, и полученного с помощью

MyBillProcess финансирования.

2.2.5. Саше требуется мобильность

Саша почти не бывает дома: он весь год в рабочих поездках. Он не

может хранить всю необходимую для работы информацию на

ноутбуке или мобильном устройстве; ему нужен постоянный

доступ к актуальной информации — контактам, проектам,

контрактам и свежим данным. Кроме того, Саше необходимо


быть на связи с партнерами и клиентами. Он обращается к

международному интернет-провайдеру, у которого есть

соглашения о роуминге со странами, где работает Саша. Теперь у

него есть постоянный доступ в Интернет и ко всем необходимым

для работы данным. Облако позволяет в любой момент получить

запрашиваемую информацию и обмениваться ею с коллегами и

клиентами. В каждом из предыдущих рассмотренных нами

сценариев Саша тоже мог не бывать в офисе; а значит, выбор в

пользу облачных решений для выполнения ежедневной работы

является наиболее разумным.

2.3. Каждый из нас — Саша

В каждом из рассмотренных ранее сценариев большинство

предлагаемых решений являются взаимозаменяемыми.

Единственная переменная — это требуемый объем облачного

хранилища. Все факторы, влияющие на решение о переходе на

облако, можно свести к двум критериям: практичности и цене.

Практичность и функциональность облачных вычислений во

многих видах повседневной работы очевидна, и в ряде случаев

отказ от облака в пользу аналогичных по функционалу

внутренних систем можно считать ненужной расточительностью.

Использование облачных технологий во многих случаях ощутимо

снижает затраты, особенно в том, что касается небольших и

ограниченных во времени задач, по сравнению с обслуживанием

внутренней инфраструктуры, требующим постоянных и

фиксированных затрат. В организации с непостоянной и

нерегулярной прибылью затраты на установку и обслуживание

оборудования окупить будет нелегко.

Конечно, у Саши всегда есть выбор. Можно построить

необходимую для бизнеса инфраструктуру, что чаще всего влечет

за собой большие первоначальные финансовые вложения. Нужно


учитывать затраты не только на оборудование, но и на ПО, а

также на наем персонала, необходимого для его установки,

настройки и поддержания работоспособности инфраструктуры.

Другой вариант — арендовать те же услуги в облаке. При таком

раскладе первоначальные затраты будут не столь высоки, а объем

инвестиций будет варьироваться в зависимости от потребностей

развивающегося бизнеса.

Наконец, облачные технологии позволяют оптимизировать

экономическую составляющую, оказывая услуги в зависимости от

спроса; Саша же сможет сосредоточиться на практической работе

для достижения своих целей.


ГЛАВА 3

От истоков к будущему

3.1. Облачные вычисления — что это?

Как мы уже говорили, парадигма облачных вычислений и все к

ней относящееся складывается в единый подход: изменение

8
местоположения вычислительных ресурсов . Они больше не

располагаются у вас на столе, в офисе или серверной: они

находятся совсем в другом месте, возможно, даже на другом

конце света, а в будущем могут оказаться и вовсе на борту

спутника.

Этот переход совершился в последнее десятилетие благодаря

новому взгляду на вычисления, изначально ориентированные на

предоставление гибких, адаптивных сервисов для сайтов с

высоким трафиком, а также из-за необходимости

синхронизировать компьютеры, чтобы люди могли работать где

угодно и когда угодно. Эти потребности распространились на

многие сферы деятельности; сегодня такая тенденция стала

массовой, и под ее влиянием сформировались различные подходы

и направления в облачных технологиях, которые мы сейчас

рассмотрим.

3.2. Виды облачных хранилищ

Во-первых, хотя у Саши весьма специфический профиль и

наиболее подходящее для него решение мы рассмотрели в

предыдущей главе, ни одно из облачных решений не может быть


априори лучше другого. Можно выполнить сколько угодно

сравнений; и все же комбинация «поставщик — облачная

модель», наиболее подходящая для конкретной цели, всегда

уникальна. В главе 4 мы обсудим различные соображения,

которые следует принимать во внимание при выборе поставщика.

Многие варианты в сфере облачных вычислений появились

вследствие роста потребностей пользователей и клиентов. Таким

образом, выбранное облачное решение — это целая комбинация

решений. Ее конфигурация в каждом отдельно взятом случае

связана с тем, является ли приложение коммерческим по сути,

будет ли требоваться индивидуальное или совместное

использование, а также с безопасностью и уровнем используемой

инфраструктуры (будь то только оборудование, оборудование и

ПО и т.д.). Возможные комбинации мы и опишем ниже.

3.2.1. Коммерческие и некоммерческие

Коммерческие и некоммерческие предложения сосуществуют еще

с тех пор, как компьютеры вышли из лабораторий и заняли свои

места в домах и офисах корпораций. К 1970–1980-м гг. такое

разделение перенесли на новые сущности — коммерческое и

бесплатное ПО. Сегодня это отражается и на облачных

вычислениях: они стали средой, где можно получить услуги на

основе коммерческого и бесплатного ПО. В следующих разделах

мы рассмотрим различные типы облачных сервисов и приведем

примеры, которые помогут лучше понять, что предлагает, делает

и представляет из себя каждый из них.

3.2.1.1. Коммерческие облачные сервисы

Почти каждая крупная ИТ-компания сегодня предлагает

услуги, связанные с облачными вычислениями. Далее мы обсудим

некоторые имеющиеся на рынке варианты и используем их как

примеры коммерческих решений от разных поставщиков.


Некоторые из них по цене или функциональности окажутся лучше

остальных для бизнеса клиента.

AWS: коммерческое публичное облако, поддерживаемое

Amazon с 2006 г. AWS можно считать первой платформой

облачных вычислений, по крайней мере, в том смысле,

который мы сегодня вкладываем в слово «облако». AWS

принято считать лидером рынка; платформа особенно

популярна среди тех, кому необходима высокая

адаптационная способность, т.е. возможность в периоды

пикового спроса использовать и настраивать большое

количество ресурсов. Яркий пример типичных

пользователей AWS — компании или сервисы, которые

могут столкнуться с неожиданными всплесками спроса или

интернет-трафика из-за того, что их контент внезапно стал

вирусным.

Популярность AWS также связана с их так называемыми

спот-инстансами (spot instances), т.е. возможностью

использовать ресурсы облачных вычислений практически

бесплатно, когда это позволяет загруженность процессора.

Если он не занят, AWS предлагает его использовать по цене,

близкой к нулю, и пользователь может дождаться, когда

стоимость максимально снизится. Таким образом, в

выигрыше оказываются обе стороны: пользователь

выполняет свою задачу за наименьшую плату, а AWS

снижает процент простаивающих процессоров.

GCP: облачная платформа, поддерживаемая Google. GCP

была второй из самых известных платформ, запущенных в

2008 г. Она пользуется большой популярностью в научных

кругах: например, ее выбрали для работы с Большим

адронным коллайдером, о чем мы поговорим позже в этой

главе. На сегодняшний день Google пока не удалось


максимально популяризировать свою платформу, и чаще

всего на рынке GCP оказывается на третьем месте.

Azure: служба облачных вычислений, поддерживаемая

Microsoft с 2010 г. За последние годы популярность сервиса

значительно выросла. Microsoft предпринимала активные

действия на рынке, чтобы занять свое место в бизнесе

облачных и бессерверных вычислений, и, похоже, преуспела

в этом.

Azure ориентирована в первую очередь на пользователей,

уже использующих другие продукты Microsoft и желающих

просто развернуть их в облачной среде.

Rackspace: компания, основанная в конце 1990-х как

простой хостинг-провайдер, превратилась в поставщика

облачных вычислений с приличной долей рынка. Rackspace

внесла вклад в развитие ряда известных облачных

технологий и успешно использовала свой опыт в этом

секторе.

IBM: один из основных поставщиков технологических услуг

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

игроков на рынке облачных вычислений. Однако его доля на

рынке и уровень развития бизнеса в сфере облачных

технологий не успевают за темпами развития отрасли и

пока не достигли необходимой компетентности. В середине

2019 г. IBM закрыла сделку по приобретению Red Hat —

компании, занимающейся бесплатным ПО и имеющей

большой опыт предоставления облачных сервисов. Ее

интеграция была призвана улучшить позиции IBM как

крупного игрока в области облачных вычислений.

3.2.1.2. Некоммерческие облачные сервисы

С ростом популярности облачных вычислений в последние

годы пользователи зачастую рассматривали облако как

возможное решение для своей повседневной работы. Однако


некоторые пользователи предпочитают не полагаться на

коммерческого поставщика, что привело к созданию

альтернативного варианта — некоммерческого облака. Обычно

его использование соответствует развертыванию облачной

вычислительной инфраструктуры в принадлежащем

пользователю дата-центре. Такой сценарий напрямую связан с

темой, которую мы обсудим в следующем разделе: моделью

частного облака. Помимо собственного оборудования,

некоммерческое облако также включает программный

компонент. Некоммерческое облачное ПО на самом деле может

стать основой коммерческой облачной вычислительной среды.

Существует несколько вариантов, и порой различия между ними

минимальны — как с точки зрения подхода, так и в технических

возможностях. Чтобы выбрать наиболее удобный вариант

развертывания и определиться, какую среду использовать —

облачную или другую, — требуются глубокие технические

познания, выходящие далеко за рамки этой книги. Однако

знакомство с некоторыми названиями и ключевыми идеями

может быть полезно для понимания доступных опций.

Особняком в этом ряду стоит OpenNebula, проект, начатый в

2005-м и реализованный в 2008 г. С тех пор OpenNebula стала

весьма популярной, доступной под лицензией на свободное

программное обеспечение платформой. Однако, хоть она и

продолжает показывать рост по ряду критериев, в масштабах

рынка процент ее использования незначителен. Еще один

заметный проект — OpenStack, изначально запущенный в 2010 г.

Rackspace и NASA. От OpenNebula он отличается несколькими

техническими характеристиками. Однако самое поразительное

различие — в подходе. OpenStack — это бесплатное программное

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

вычислительной среды, но разрабатывается оно не сообществом

пользователей, как та же OpenNebula, а консорциумом

коммерческих поставщиков или поставщиков, использующих его


в качестве решения для предлагаемых ими услуг. Большинство

поставщиков применяют или предлагают OpenStack среди своих

решений для облачных и бессерверных вычислений.

Правительственные исследовательские центры обычно

используют OpenNebula или OpenStack для развертывания

внутренней инфраструктуры облачных вычислений.

Еще одна «долгоиграющая идея» — возможность сочетания

облачных и волонтерских вычислений, чего можно достигнуть

несколькими способами. Самый простой — создать службу

облачных вычислений, использующую домашние компьютеры

9
добровольцев в качестве инфраструктуры .

3.2.2. Модели развертывания

Существует несколько способов использования и предоставления

услуг облачных вычислений, чаще всего зависящих от требований

к безопасности и конфиденциальности. Чаще всего используется

модель публичного облака. При такой модели серверы дата-

центра могут использоваться сразу несколькими пользователями

10
в зависимости от их потребностей . Такой подход дает гибкость в

получении доступа к ресурсам, а инфраструктура обычно

управляется ИТ-персоналом владельца дата-центра.

В других случаях конкретному клиенту или пользователю

могут потребоваться усиление мер безопасности или

конфиденциальности, что делает использование одного и того же

сервера или дата-центра разными пользователями

нежелательным. Подобные случаи, когда один пользователь

занимает весь облачный вычислительный сервис, представляют

собой частное облако — модель, при которой инфраструктура

может управляться непосредственно ИТ-отделом клиента или

поставщиком в соответствии с потребностями. Более того: такая

модель может быть реализована путем совместного

использования дата-центра несколькими клиентами, но с


усилением мер безопасности для каждого из них (брандмауэры,

эксклюзивное использование некоторых серверов и т.д.).

Опыт показывает, что порой наилучшим решением является

сочетание обеих моделей: так, для выполнения одних задач Саша

может найти публичное облако, для других — частное. А значит,

подходящим решением для него станет гибридное облако —

комбинация различных облачных инфраструктур.

Эти три модели выстроены вокруг одной важнейшей

концепции — собственности. Очевидно, облачные вычисления

можно просто арендовать, т.е. использоваться будет дата-центр,

предоставленный поставщиком; в этом случае пользователю не

нужно покупать и обслуживать оборудование. Другой вариант —

продолжить управлять своим дата-центром и обслуживать его. У

каждой опции есть свои плюсы и минусы в зависимости от

сценария использования.

Примечательно, что частные облачные решения, как правило,

вполне удовлетворяют нужды большинства пользователей,

включая даже правительства. Примером может служить один из

крупнейших контрактов в оборонном секторе на сумму до $10

млрд, предоставленный Azure Министерством обороны США в

11
2019 г.

3.2.3. Типы услуг

Поставщики облачных решений могут предлагать различные

услуги в соответствии с иерархией абстракций, представленной

на рисунке 3.1. Абстракции высшего уровня (расположенные

вверху диаграммы) несут меньшую операционную нагрузку и

включают больше готовых функций, однако и большее

количество ограничений и высшую степень зависимости от

поставщика. Учитывая, что каждый новый уровень строится на

предыдущем, абстракции, технологии, сервисы и решения на


наивысшем уровне, как правило, новейшие. Последовательно

изучая уровень за уровнем, мы получим следующее:

«Инфраструктура как услуга» (IaaS): нижний уровень

иерархии, на котором поставщики предлагают доступ к

виртуализированному оборудованию. Примером может

послужить один из сервисов AWS — EC2, предлагающий полный

доступ к оборудованию виртуального сервера.

«Платформа как услуга» (PaaS): следующий уровень

иерархии позволяет сделать еще один шаг к абстракции и, как

правило, предоставляет пользователям полную платформу,

скрывая при этом детали нижнего уровня, такие как

оборудование. Примером может послужить Google Dataproc с его

полностью управляемыми кластерами Hadoop и Spark, где

пользователю не нужно ни настраивать базовую инфраструктуру

(в т.ч. сеть, вычислительное оборудование и хранилище), ни

управлять ею. Этот облачный сервис представлен как единая

платформа с четко разграниченными рабочими потоками.

«Программное обеспечение как услуга» (SaaS): грань между

PaaS и SaaS размыта и варьируется в зависимости от автора (и

уровня абстракции), но мы можем четко определить, что такие

сервисы как Dropbox или Gmail относятся к SaaS. Подобные

сервисы и приложения размещаются и полностью управляются

третьей стороной (которая не обязана при этом являться


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

модифицировать только заранее заданные параметры —

дисковое пространство, пропускная способность и т.д. Однако

пользователь не получит доступа к основным аппаратным

ресурсам: он не будет даже знать о них. Как пример рассмотрим

Dropbox, где пользователи могут управлять объектами (папками

и файлами) и видеть, сколько свободного места у них осталось, —

и на этом их уровень знания инфраструктуры заканчивается (так,

Саша не знает и не будет задумываться о том, какой технологией

хранения пользуется).

«Функция как услуга» (FaaS): этот уровень абстракции, более

известный как бессерверные вычисления, ориентирован скорее на

тех, кто занимается разработкой. Аппаратные ресурсы

абстрагированы, и пользователь может сосредоточиться на

создании ПО, а не на управлении инфраструктурой: это забота

поставщика. FaaS может быть особенно интересным вариантом

12
для микро- и наносервисов , актуальных для мобильных

приложений и интернета вещей. Примеры FaaS — AWS Lambda и

Google Cloud Functions. Более подробно мы рассмотрим

бессерверные вычисления в главе 7.

3.3. Особенности облака

Есть множество причин, чтобы использовать облачные

вычислительные технологии в исследованиях. Некоторые из них

хорошо известны: поставщики рассказывают о них на своих

сайтах в маркетинговых целях. Рассмотрим их вкратце.

3.3.1. Эластичность и масштабируемость

Масштабируемость облачных вычислений очень полезна для двух

типичных сценариев проведения исследований. Первый связан с


пользователями: так, Саша может создать или слишком большой

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

слишком много раз, что делает размещение в собственном дата-

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

наилучшим выбором станет размещение массива данных в

облаке, возможно, зеркально отображаемого в нескольких дата-

центрах по всему миру: такая система сможет справиться с

задачей независимо от количества пользователей или пропускной

способности сети, необходимой для передачи данных.

А вот и второй типичный сценарий: Саше нужно выполнить

вычисления за ограниченный промежуток времени, а локальных

ресурсов HPC недостаточно. В таких случаях Саша может

прибегнуть к облачным сервисам для достижения эластичности,

необходимой для своевременного завершения вычислений.

Обычно в подобных сценариях мы сталкиваемся с

необходимостью выполнить непредвиденную задачу в крайне

сжатые сроки, т.к. некий аспект вашего исследования внезапно

стал актуален для СМИ или сложившейся политической ситуации.

Саша может использовать HPCaaS в облаке в дополнение к своему

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

своей очереди на вычисления.

3.2.2. Возможность самообслуживания

Сервис самообслуживания в облаке предоставляет пользователю

возможность запрашивать любые доступные ресурсы (например,

инстансы или хранилище) из каталога поставщика. Поставщики

же предлагают разнообразные прозрачные сервисы

автоматизации, обеспечивающие абстракцию. Отметим, что в

облаке Саша не получает сервер (или инстанс), а должен выбрать

предопределенный образ сервера, в большей или меньшей

степени соответствующий требованиям (например, образ с

Apache и PHP для веб-сервера). В более традиционной


(вычислительной) среде доступные ресурсы всегда

предопределены и зачастую используются совместно (например,

если доступ к процессорному времени приходится ждать), а

самообслуживание вообще не рассматривается или требует

вмешательства оператора.

С расширением свободы выбора пользователи должны

получать лучшее понимание вариантов и применимых

технологий; вот почему большинство поставщиков устраивают

специальные тренинги и аттестации (в т.ч. бесплатные), что уже

стало самостоятельным бизнесом.

3.3.3. Интерфейсы прикладного программирования

Интерфейс прикладного программирования (API) — это

абстракция (очень) высокого уровня, обеспечивающая

стандартный способ взаимодействия с ПО или инфраструктурой.

Совсем упрощенно можно определить API как ПО,

предоставляющее стандартизированный интерфейс, с помощью

которого другое ПО может выполнить желаемое действие.

Мы углубимся в тему и приведем примеры API в главе 6.

Сейчас скажем лишь, что API — представители «высшего

облачного общества», предлагающие лучший способ

взаимодействия между компонентами. Так, создание нового

каталога в облачном хранилище выполняется через обращение к

соответствующему API службы (например, S3 на AWS) и

предоставление необходимых атрибутов, например названия

каталога.

Еще один пример — инструменты командной строки,

предоставляемые пользователям поставщиками. Как правило, это

надстройки, связывающие API с абстрактными общими

действиями, например, созданием нового каталога.

3.3.4 Мониторинг и измерение производительности


Облако предоставляет пользователю возможность мониторинга:

Саша может получить доступ к метрикам и журналам, что

позволит проводить эмпирические наблюдения с использованием

данных доступных систем и служб, а также разрабатывать модели

для таких приложений, как прогнозирование расходования

ресурсов. Примером подобных показателей являются загрузка ЦП

и свободное дисковое пространство на уровне экземпляра или

кластера, а также более важные характеристики, такие как

частота ошибок в определенном количестве запросов, который

получает веб-сервер.

Каждый поставщик по-своему представляет эту информацию,

прибегая к собственным решениям (таким как AWS CloudWatch

или GCP Stackdriver). Кроме того, доступны бесплатные проекты

13 14
(такие как Graphite и Grafana ): их можно адаптировать для

работы в большинстве облачных сервисов.

3.4. Концепции Cloud Native

Все описанные в этом разделе облачно-ориентированные

концепции необходимы для понимания некоторых

рассматриваемых в этой книге вопросов (или облегчают его),

поэтому мы призываем читателя узнать о них как можно больше.

Подробное изучение реализации этих концепций выходит за

рамки данной книги; поэтому мы представим только

поверхностный обзор.

3.4.1. Cloud Native

Cloud Native — понятие широкое. Как читатель, наверное, успел

понять во время чтения этой книги, определение границ в сфере

облачных вычислений довольно расплывчато и чаще всего

вызывает оживленные споры. Приложение или сервис можно


назвать Cloud Native, т.е. облачно-ориентированным, если они

успешно функционируют в среде, предоставляемой облачными

вычислениями, и в той или иной мере нуждаются в ней. Более

того: приложение или сервис вне облачной среды, вероятнее

всего, окажутся бессмысленными (или и вовсе не смогут

работать), так как большинство функций — к примеру, API —

окажутся недоступны или будут работать иначе.

В поддержку этой концепции и для того, чтобы

поспособствовать созданию экосистемы, в 2015 г. был основан

фонд CNCF (Cloud Native Computing Foundation, являющийся

частью Linux Foundation; https://www.cncf.io/). Здесь мы

приведем их определение понятия Cloud Native:

Технологии Cloud Native позволяют организациям разрабатывать и запускать

масштабируемые приложения в современных, динамичных средах, таких как

публичные, частные и гибридные облака. Примерами этого подхода служат

контейнеры, технологии сервисных сеток, микросервисы, неизменяемая

инфраструктура и декларативные API.

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

устойчивые, управляемые и наблюдаемые. В сочетании с надежной

автоматизацией все это позволяет разработчикам часто вносить важные

изменения с предсказуемо низкими трудозатратами.

Фонд Cloud Native Computing Foundation старается стимулировать принятие

данной парадигмы, поощряя и поддерживая экосистему проектов с открытым

кодом, независимых от производителя. Мы демократизируем новейшие модели,

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

3.4.2. Контейнеры

С формальной точки зрения контейнер — это виртуальная среда

выполнения, работающая поверх ядра операционной системы и

15
эмулирующая ОС, а не базовое оборудование . Наиболее часто

используемым и известным ПО (PaaS), запускающим контейнеры

16
через виртуализацию на уровне ОС, является Docker .

Контейнеры считают наиболее выраженным примером

концепции Cloud Native, продвигаемой CNCF.


С точки зрения научных исследований контейнеры

предлагаются как возможное решение давней и непростой

проблемы — вопроса вычислительной воспроизводимости

результатов научных изысканий. Вычислительные инструменты

активно используются во всех областях исследований, и

воспроизводимость их результатов становится все более

17
актуальной проблемой . Облачные вычисления привносят

элемент сложности, однако эту проблему прекрасно решит

18
хорошее описание и использование контейнеров , т.к. все

используемое ПО общедоступно и снабжено детальным

описанием.

3.4.3 Микросервисы

Микросервисы можно определить как отдельные небольшие и

независимые сервисы, обычно обслуживающие отдельный аспект

функционирования бизнеса. У других авторов и в иных

контекстах микросервисам могут даваться кардинально иные

определения — как и другим концепциям облачных вычислений.

Микросервисы — это способ написания ПО, рекомендованный

CNCF. В главе 7 мы подробно рассмотрим простой пример

микросервиса (бессерверные вычисления).

3.4.4. Kubernetes

Kubernetes — созданное Google открытое ПО для оркестровки

контейнизированных приложений, предлагающее набор

абстракций для развертывания, масштабирования и запуска кода.

Чаще всего Kubernetes используется как PaaS (например, через

GCP, AWS или Azure), а также активно применяется в индустрии

высоких технологий.

Kubernetes, разрабатываемое и поддерживаемое CNCF,

является рекомендуемым методом оркестровки микросервисов


для реализации неизменяемого подхода к инфраструктуре.

3.5. Вопросы экологии

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

дата-центров, является воздействие на окружающую среду —

расход энергии на содержание инфраструктуры, в том числе

охлаждение. Этот фактор также следует учитывать при оценке

облачных вычислений: он представляет особый интерес для

организаций, желающих снизить пагубное воздействие на

экологию. С точки зрения логики, обслуживать более крупный

централизованный дата-центр должно быть проще и дешевле,

нежели несколько отдельных вычислительных инфраструктур.

Так и есть. Кроме того, компании, предлагающие услуги

облачных вычислений, отдают себе отчет в том, какие

экологические проблемы вызывает их бизнес, и прилагают

усилия к тому, чтобы минимизировать их влияние, например,

снизив выбросы углерода. Воздействие на окружающую среду

может быть весомым аргументом при переходе на облачные

вычисления; однако это не истина в последней инстанции.

Например, если вы собираетесь перенести ПО, которым обычно

пользуетесь на своем ПК (ноутбуке, рабочей станции и т.д.), в

облако, плюс очевиден: вы сможете использовать оборудование,

потребляющее меньше энергии. Однако, если вы используете

облако для обработки больших объемов данных и их

непрерывной передачи, эти процессы могут нести более пагубное

воздействие на окружающую среду, а совокупное потребление

19
электричества дата-центром может возрасти . И все же при

взвешивании побочных эффектов необходимо учесть ряд

факторов: отказ от использования помещений (локального дата-

центра), все связанные с ним затраты электроэнергии (иногда


измеряемые в таких показателях, как коэффициент

энергоэффективности) и т.д.

Некоторые данные могут пролить свет на эту проблему.

Проведенное Microsoft исследование по использованию Azure

показало: экономия энергии при использовании SaaS в среднем

больше (а в некоторых случаях — более 90%), чем при

20
использовании IaaS (52–79%) . Кроме того, более половины

использованной AWS в 2018 г. энергии была возобновляемой,

согласно данным, предоставленным самой компанией, а ее

«углеродный след» — уровень выбросов парниковых газов в

атмосферу — по данным за 2019 г. был на 88% ниже в сравнении

с соответствующим показателем среднестатистического дата-

центра.

Наконец, отметим: современные дата-центры намного более

энергоэффективны, нежели были несколько лет назад, и

ожидается, что ситуация будет только улучшаться.

Энергоэффективность специализированных центров обработки

данных, предоставляемых некоторыми поставщиками, постоянно

контролируется, в то время как в ряде собственных дата-центров

этот критерий учитывается лишь при их проектировании или

обновлении. Вот почему, рассматривая преимущества облачных

вычислений с точки зрения экологии, нужно учитывать не только

конкретную ситуацию на момент внедрения, но и ее эволюцию с

течением времени.

3.6. Истории успешного применения облачных и

бессерверных вычислений в науке

За последние годы облачные технологии достигли высокого

уровня зрелости в том числе благодаря историям их успешного

применения в научных исследованиях. Для иллюстрации

приведем несколько показательных примеров. Кроме того,


истории успеха можно найти на сайтах поставщиков, в том числе

и представленных ниже. И этот список нельзя назвать

исчерпывающим: без сомнения, еще немало примеров появится,

пока мы пишем, а вы читаете эту книгу.

3.6.1. Археология

Стэндфордский археологический центр использует облачные

технологии для создания точных и исчерпывающих записей о

найденных в ходе раскопок предметах и для обмена данными с

исследовательским сообществом. Помимо этого, не так давно

Центр предложил облачное решение для усовершенствования

археологических исследований главных достопримечательностей,

21
включающее возможность сочетать опции IaaS, PaaS и SaaS .

3.6.2. Компьютерные науки

Разработанный Калифорнийским университетом в Беркли проект

по машинному обучению и анализу данных призван повысить

эффективность энергопотребления батарей. Кроме того,

облачные вычисления были задействованы для

усовершенствования процесса изготовления чипов, что повысило

производительность на 15%. Еще один пример — использование

облачных сервисов исследовательской группой из Национального

университета Тайваня: таким образом они смогли расширить

свой локальный кластер.

3.6.3. Энергетика

Облачные вычисления уже комбинируются с датамайнингом и

технологиями искусственного интеллекта для прогнозирования

цен на энергоносители и достижения наилучшего соответствия

производства электроэнергии спросу. Кроме того, существуют


инструменты, объединяющие полезные для статистики

климатические и энергетические данные, полученные из

облачных сервисов, для таких проектов, как, например,

22
программа Copernicus .

3.6.4. Науки о Земле

В данной области облачные технологии применяются для

визуализации и хранения данных, а также как HPCaaS (включая

системы прогнозирования погоды и моделирования климата).

Существуют примеры применения облачных решений в

23
исследованиях атмосферы и моделирования климата .

Институты и метеорологические службы разных стран мира

используют облачные вычисления для масштабируемой

обработки данных, например когда возникает пиковый спрос на

подключение, поиск данных во время экстремальных

катаклизмов или запрошено большое количество результатов

моделирования климата. Кроме того, существуют приложения

BOINC (Berkeley Open Infrastructure for Network Computing —

открытая инфраструктура сетевых вычислений в Беркли) на

24
облачных сервисах . Американская NREL использует облачные

вычисления в ряде проектов для совместного создания баз данных

по энергетике и обмена ими.

В бессерверных средах тестировалась возможность

использовать нейронные сети для прогнозирования погоды. В

таких случаях нейронные сети требуется адаптировать для

работы в бессерверной среде (см. главу 7).

3.6.5. Библиотечное дело

Сохранение документации и ее доступность в Интернете для

использования в других исследованиях необычайно важны. Это

особенно актуально в случае со старыми документами:


использование оцифрованных копий повышает их доступность,

чего чаще всего нельзя было бы достигнуть никаким другим

способом ввиду плохого состояния оригиналов. Ресурсы такого

типа включают изображения высокого разрешения и связанные с

ними метаданные. Библиотеки, например Каталонская

национальная, используют облачные сервисы для предоставления

оперативного доступа к консультациям по этим источникам

информации.

3.6.6. Математика

Отличным примером применения облачных вычислений в

25
коллективных исследованиях (и преподавании) является CoCalc

(ранее известная как SageMathCloud) — общедоступная веб-

система, позволяющая выполнять совместные математические

вычисления. CoCalc была разработана с использованием схем

предоставления облачных вычислений для исследований,

подобных тем, о которых мы поговорим в главе 4. Поэтому CoCalc

можно назвать действительно хорошим примером. По данным

Википедии, в 2017 г. у CoCalc было порядка 300 000 активных

пользователей.

В более широком плане разработку математических

приложений в облачных средах поощряли и государственные

органы: так, проект MSO4SC, финансируемый ЕС, включал HPC.

3.6.7. Медицинские науки

Есть множество примеров внедрения облачных и бессерверных

вычислений в области медицинских наук. Сегодня FDA

использует облачные технологии для совершенствования

обработки огромных массивов письменных отчетов о

воздействии препаратов, которые Управление получает каждый

год. Кроме того, CDC использует эту технологию для получения и


обмена информацией об эволюции болезней. Если рассматривать

более частные случаи использования HPCaaS, то Институт

медицинских исследований Уолтера и Элизы Холл прибегает к

облачным вычислениям для анализа данных микроскопических

исследований с высоким разрешением. Кроме того, Фонд Майкла

Дж. Фокса разработал программу исследований, в ходе которой

пациенты постоянно передают данные с переносных устройств в

облако. Полученную от разных пациентов информацию

анализируют одновременно, что является огромным прогрессом

по сравнению с плановыми ежемесячными медицинскими

осмотрами и, как следствие, полезно для изучения симптоматики

и лекарственных средств. Еще два примера — Исследовательский

институт больницы Оттавы, использующий облачные ресурсы в

рамках программы, направленной на изучение вопроса, почему

люди неохотно соглашаются на прививки, и Университет

Западной Капской провинции, предоставляющий в рамках своего

исследования веб-платформу для изучения устойчивости к

препаратам от ВИЧ. Не меньшую важность имеет

распараллеливание рабочих процессов: так, Смитсоновский

институт использует их при аннотировании геномов.

Стэндфордский университет прибегает к облачным вычислениям

для совершенствования рабочих процессов при исследованиях в

области нейровизуализации. Кроме того, данная технология

позволяет укрепить компьютерную безопасность и упрочить

соблюдение строгих правил в отношении медицинской

информации.

Упомянем здесь также использование бессерверных

вычислений. Так, примеры применения AWS Lambda включают

GenePool от Station X — платформу, которую можно использовать

для анализа генетических данных, и Benchling — компанию,

разрабатывающую и продающую ПО для генной инженерии.


3.6.8. Физика

Пожалуй, одним из самых ярких примеров использования

облачных технологий в физике является управление огромным

массивом данных, получаемых ЦЕРН в ходе экспериментов на

Большом адронном коллайдере. GCP применяется для анализа

данных эксперимента Atlas, а OpenFOAM, популярное бесплатное

ПО в области вычислительной гидродинамики, можно запустить

непосредственно на AWS.

3.6.9. Общественные науки

В качестве примера из этой области знаний можно привести

Цифровую обсерваторию Квинслендского технологического

университета: она использует облачные технологии для сбора и

хранения данных соцсетей со всей Австралии и предоставляет

удобный доступ к этим данным для исследователей, что весьма

полезно с точки зрения аналитики и визуализации.

3.6.10. Космические исследования

ЕКА, NASA и ее лаборатория JPL, а также Университет Аляски

используют облачные вычисления для обработки и

распространения огромного количества спутниковых снимков. В

случае с JPL их променяли для систем наведения роботов и

обеспечения масштабируемой потоковой передачи видео-миссии

Mars Curiosity. Кроме того, для обработки полученных из космоса

26
изображений применялись бессерверные вычисления .
ГЛАВА 4

Покажите деньги

4.1. Средства на исследования с использованием облачных

вычислений

В последние годы несколько вендоров (поставщиков

оборудования и ПО), задавшись целью содействовать

использованию облачных вычислений, создали программы

предоставления грантов или кредитов исследователям,

проверяющим применимость данной технологии в своей работе.

Такой подход был и остается беспроигрышным, так как научное

сообщество получает доступ к огромным объемам ресурсов для

HPC или датамайнинга; вендоры же, заранее узнавая о проблемах

и потребностях будущих клиентов, решают их загодя, а значит,

разрабатывают более надежный и комплексный продукт. Такой

подход сам по себе является отличной маркетинговой кампанией:

вендоры инвестируют в проекты на благо общества.

Некоторые из подобных программ выполняются или

выполнялись в прошлом в течение ограниченного промежутка

времени; другие действуют дольше или открыты постоянно. В

качестве примера можно привести Azure for Research и AWS

Research Credits; некоторые программы ориентированы на более

узкие темы, например Microsoft Climate Data Initiative или Amazon

Sustainability Data Initiative. В других случаях можно связаться с

вендорами и узнать, можно ли получить грант на использование

их ресурсов; многие вендоры открыты для сотрудничества.


Несомненно, заслуживают изучения и другие варианты. Чаще

всего ответы можно найти, просто изучив сайты вендоров.

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

оптимизации и учета финансирования исследований. Какую

научную дисциплину ни возьми, получение доступа к

инфраструктуре и инструментам, необходимым для проведения

исследований, стоит немалых трудов. Подавая заявку на

финансирование различных проектов, исследователям зачастую

приходится закладывать суммы на приобретение необходимой

инфраструктуры и приборов. Кроме того, финансирующие

органы иногда не очень охотно предоставляют необходимые

средства: приобретенные материальные ценности остаются на

больший срок, чем продлится сам исследовательский проект. Эту

проблему обычно решают поиском другого источника средств:

например, основного финансирования от исследовательских

центров или совместного использования критически важной

инфраструктуры. Однако в случае компьютерной

инфраструктуры для однократного использования (отдельный

исследовательский проект), как указывалось ранее, подобный

доступ и использование можно профинансировать за счет

специальных средств в составе исследовательского гранта,

избежав необходимости поддерживать инфраструктуру,

приобретенную для единственной задачи или оправдывать трату

денег на оборудование, которое останется после завершения

исследования.

4.2. Распределение расходов

Мы уже рассматривали случай, когда Сашина лаборатория

участвует в исследованиях, где не обойтись без HPCaaS.

Лаборатория производит обширные объемы данных, которые

нужно где-то хранить, и ей наверняка придется приложить


усилия, чтобы получить хранилище требуемого объема и

подключение к Интернету, позволяющее обмениваться данными

и результатами исследований с коллегами. С этим могут

возникнуть проблемы, если Сашины исследования обретут

известность или если в результате изысканий будут получен

набор данных, которым захочет пользоваться исследовательское

сообщество. Более того, в подобных случаях облачные сервисы

могут стать отличным инструментом для распространения

результатов. Если Сашины коллеги пожелают скачать себе

данные или получить результаты с помощью своего ПО, облачное

решение просто запросит у лаборатории доступ для стороннего

исследователя, и эти задачи будут выполнены через облачную

службу. Дополнительным плюсом станет то, что все связанные с

этим траты на передачу данных или HPCaaS лягут на плечи коллег

или заинтересованных лиц, а не на Сашину лабораторию.

Эта схема представляет собой огромный шаг вперед по

сравнению с традиционной, при которой Сашина лаборатория

может потребовать от коллег подписать контракт и платить за

услугу, подать совместную заявку на грант или даже получить

компенсацию в виде соавторства за результаты исследований.

Сашина лаборатория понесет расходы только на научную

деятельность, но не будет платить за совместное использование

результатов: как минимум, они могут разделить эти расходы с

другими.

4.3. Продажа исследований

Рассмотренный в предыдущем разделе случай является

следствием возможности использовать облако для обеспечения

доступа к результатам определенного исследования, что

представляет собой важный плюс для бизнеса. Рассмотрим

действия Саши после того, как он успешно разработал


программную платформу или продукт. Скорее всего, многие его

коллеги пожелают воспользоваться новым инструментом.

Сделать это можно несколькими способами, и один из них —

посетить Сашину лабораторию для совместной работы. В ряде

случаев это может потребовать адаптации к потребностям нового

пользователя: для этого можно развернуть инструмент в облаке и

продавать пользователям доступ к нему и, по необходимости, к

услугам персонализации. Осуществить это можно, например,

через дочернюю компанию.

Рассмотрим другой случай: Сашина лаборатория производит

слишком большой объем данных, что делает обработку силами

одной лишь его команды невозможной; кроме того, использовать

эти данные можно такими способами, которые команде уже не

интересны. При таком раскладе хорошим вариантом

монетизации проделанной исследовательской работы стал бы

такой: открыть доступ к данным в облачной среде и позволить

другим пользователям скачивать их или проводить датамайнинг,

применяя пользовательские алгоритмы к массиву данных и

взимая за это плату. Так действуют некоторые частные компании,

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

упоминали в разделе 3.6.

Для Саши такие варианты станут отличным способом

повысить эффективность изысканий, одновременно снизив

трудоемкость для других исследовательских групп, использующих

систему, методологию или данные, предоставленные Сашиной

лабораторией. Кроме того, такой подход дает пользователям

возможность контролировать затраченные на исследования

средства с помощью системы оплаты по факту использования.

4.4. А если я не заплачу?


Саша может опасаться, что потеряет доступ к данным своих

исследований, если не оплатит облачные услуги. Прежде всего,

такой сценарий применим только к коммерческим поставщикам,

выставляющим счета за использование своих облачных ресурсов.

В остальных случаях подобный страх в некотором смысле не

оправдан. Однако простое хранение информации в облаке стало

практически бесплатным; затраты связаны в основном с

передачей данных, и в целом их можно назвать приемлемыми.

Более того, если Саше требуется доступ к данным, но в данный

момент он не может себе позволить оплатить его, скорее всего,

Саша может связаться с поставщиком и попробовать отказаться

от оплаты. Поскольку данные запрашиваются в

исследовательских целях, вполне вероятно, что Саша все же

сможет получить к ним доступ: как мы уже говорили, для таких

случаев существуют специальные гранты, особенно если

исследовательская работа проводится не ради получения

прибыли.

4.5. А если мой поставщик не предоставит услугу?

Другой проблемой может стать непредоставление коммерческим

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

Как и в случае с любой другой сферой услуг, коммерческие

поставщики должны предоставлять гарантии и несут

ответственность за невыполнение своих обязательств.

Коммерческие поставщики обычно стремятся к высокому уровню

прозрачности в отношении проблем технического характера и

прочих сложностей; также они резервируют средства для оплаты

непредвиденных расходов. Кроме того, зачастую проблемы

решаются так оперативно, что пользователь может даже их не

заметить.
Однако это не единственная из возможных трудностей.

Уровень надежности поставщиков облачных решений

чрезвычайно высок. Так, в ходе своего главного ежегодного

мероприятия в сфере облачных вычислений — Google Cloud Next

— в 2019 г. Google заявили, что являются номером один по

степени надежности среди поставщиков облачных услуг,

подкрепив это следующими сведениями: в 2018 г. их сервис был

недоступен всего в течение примерно 200 минут. Ближайшим

конкурентом стали AWS с показателем порядка 300 минут.

Развернулись споры о том, насколько точны эти данные и кто на

самом деле является самым надежным поставщиком услуг; но

важнее всего здесь то, что за целый год время простоя облачных

сервисов составляет всего 3–5 часов. Очевидно, такие цифры все

же являются проблемой для критически важных систем; однако

вероятность столкнуться с более продолжительным простоем при

эксплуатации собственной локальной системы наверняка гораздо

выше. Так, в следующем разделе мы рассмотрим, как оценить

переход на облако на основе реального опыта. Надежность

сервиса не принимается во внимание, т.к., на наш взгляд, этот

критерий не является обязательным для большинства

пользователей облачных сервисов.

4.6. Оценка перехода

В дополнение к обычным проверкам и экспериментам вам может

понадобиться оценка того, имеет ли вообще смысл переходить на

облачную инфраструктуру. В следующих разделах мы рассмотрим

некоторые соображения и аспекты, по которым можно оценить

возможный переход.

4.6.1. Выбор поставщика


Выбор поставщика облачных сервисов, одного или нескольких,

27
является наиболее важным решением , поскольку он не только

определит ваши возможности (и ограничения), но и сыграет

ключевую роль в последующих шагах и открытии новых

возможностей для будущей работы. Именно поэтому делать этот

шаг следует лишь после того, как вы тщательно взвесили все

варианты.

В этом разделе мы не предлагаем никакой новой стратегии

выбора поставщика и даже не определяем, какой подход вам

выбрать; у большинства поставщиков есть собственные

руководства, где указаны методы оценки и выполнения перехода

на облако. Здесь мы лишь предоставим общие сведения об

основных концепциях, чтобы пользователь мог сделать

наилучший выбор, отталкиваясь от проблемы, которую пытается

решить.

Хотя представленная нами оценка абсолютно нейтральна, у

каждого поставщика есть своя уникальная стратегия и целевая

группа клиентов. Таким образом, разработанные и

предоставляемые каждым поставщиком решения как правило

адаптируются к заданному набору целей. А значит, поставщик

облачных сервисов, более других соответствующий вашим

потребностям, скорее всего, уже сотрудничает с другими

исследователями в вашей области.

4.6.2. Определение проблемы

Первый шаг — определение проблемы, которую необходимо

решить, и ее составляющих на высоком уровне. Чем конкретнее

удастся определить требования, тем легче будет найти

оптимальное решение (и поставщика). Так, в рассмотренном

нами примере Саша пытается запустить моделирование климата,

чтобы рассчитать, допустим, облачность: узнать, насколько

облачно в разных уголках Земли в определенный день.


4.6.3. Сбор требований

Для создания такой подборки можно использовать самые разные

28
методы и подходы . Однако в любом случае следующим шагом

является сбор всех требований, которые улучшат понимание, как

именно в данном случае будут использоваться технологии, и

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

29
ниже аспектов :

Пригодность: доступных сервисов и систем будет

достаточно для удовлетворения наших потребностей,

включая требования к производительности и скорости

сетевого соединения между дата-центрами поставщика для

репликации данных.

Удобство использования: понятные интерфейсы, API и т.д.

адаптированы к уровню знаний сотрудников, которым

предстоит управлять проектом.

Эластичность: поставщик обладает достаточной гибкостью,

чтобы предоставлять различные (и даже наилучшие)

решения в соответствии с нашими потребностями.

Затраты: стоимость услуг поставщика соответствует нашим

ожиданиям; стоит также учитывать, предоставляются ли

скидки и рассматриваются ли варианты отказа от оплаты.

Безопасность и соответствие требованиям: нам всегда

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

обеспечение требует усилий и тщательного планирования.

Саша понимает: пробелы в безопасности могут привести к

серьезным потерям, и не только финансовым. То же

касается требований, включающих соответствие

нормативным документам, возможность запуска кода под

более благоприятной юрисдикцией, если это потребуется, и

обеспечение полного соответствия сервисов закону. При

некорректном планировании два этих аспекта могут иметь


самые серьезные последствия или привести к полному

провалу.

Саше следует ранжировать эти аспекты по важности и

присвоить каждому значение от 0 до 1, где 0 — наименее, а 1 —

наиболее значимый аспект.

Следуя примеру, рассмотренному в предыдущем разделе, и

обсудив ситуацию с командой, Саша составляет расширенный

список требований:

Обычно моделирование выполнялось на одном локальном

сервере, но исследователи хотели бы в будущем иметь

возможность выполнять несколько вычислительных потоков

параллельно. Полная техническая характеристика сервиса

должна быть доступна для ознакомления.

Приложению требуется мощный процессор, а большой

объем памяти — нет.

Данные поступают из публичного API, доступного в

интернете.

Выходные данные незначительны по объему и должны быть

доступны всей команде в общем хранилище.

Результаты должны быть конфиденциальны, а значит,

требуется обеспечить определенный уровень безопасности.

Сашина лаборатория работает в соответствии с

установленными правительством правилами.

Проект находится на ранней стадии, а значит, бюджет

ограничен. Однако Саша может получить дополнительное

финансирование в случае, если получит

удовлетворительные результаты.

Учитывая все эти требования, в ходе дальнейшего обсуждения

команда присвоила каждому из рассматриваемых аспектов баллы


(см. табл. 4.1).

4.6.4. Получение данных

После определения всех граней задачи данные о поставщиках

заносятся в самый удобный для нас формат, например в таблицу.

Учитывая все требования, мы присваиваем каждому из

поставщиков баллы и оцениваем их с точки зрения способности

удовлетворить наши потребности. Так, для решения задачи,

рассмотренной в предыдущих разделах, мы присваиваем

поставщикам от 1 до 10 баллов по каждому критерию. В табл. 4.2

показан пример оценки поставщиков, который позволит Саше

выбрать наиболее соответствующего его потребностям.


4.6.5. Обзор и принятие решения

Все данные получены (см. табл. 4.2), и теперь можно провести

первичный отбор, чтобы отсеять явно неудовлетворительные

варианты, где не выполняются многие требования.

В нашем примере предстоит сделать выбор между

Поставщиками 1 и 2. Новый расчет можно осуществить,

скорректировав баллы на основе полученных результатов. Если

несколько поставщиков предлагают услуги одинакового уровня,

для получения более точной оценки, возможно, придется искать

дополнительную информацию о каждом сервисе или функции.

Саша может предпринять несколько дополнительных шагов:

Связаться напрямую с отделами продаж выбранных

поставщиков: стандартная цена, как правило, не дает

представления о доступных скидках или специальных

условиях.

Попробовать получить пробное время или льготный период,

чтобы на практике оценить, способен ли поставщик

удовлетворить все требования.

Еще раз коллегиально обсудить проблему, которую

необходимо решить, и убедиться, не изменились ли

некоторые из изначальных требований в связи с появлением

новых сведений и сделанными выводами.

Повторять процесс многократно, пока количество

вариантов не уменьшится, например, до двух возможных

поставщиков.

4.7. Выводы

Наконец следует отметить, что в облачных вычислениях всегда

есть переменные факторы: использование облака сопряжено с


некоторыми затратами, и они могут в том числе зависеть от того,

как и в какой области вы будете его применять: так, затраты на

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

грамотно разработанное облачное решение может сэкономить

вам деньги (и принести прибыль), но, как мы отметили в этой

главе, помимо финансового аспекта вам следует учитывать

многие другие.

Кроме того, выбирая поставщика облачных услуг, необходимо

принимать во внимание, что организации нередко прибегают к

мультиоблачному и гибридному подходу. Первый означает, что

организация по какой-то причине не полагается на одного

поставщика: например, из желания воспользоваться

преимуществами, которые предлагают разные поставщики (ПО,

дизайн и т.д.). Другая возможная причина — желание избежать

привязки к одному поставщику. Прибегнув же к гибридному

подходу, организация пользуется как частными, так и

публичными облачными службами, причем не обязательно от

разных поставщиков. Следовательно, такое решение можно

рассмотреть, если наилучшим вариантом является преданность

одному поставщику.
ГЛАВА 5

Инструментарий в облаке

5.1. Саше нужен лучший инструментарий

Как руководитель исследовательской организации Саша

стремится усовершенствовать доступный ему инструментарий и

услуги, применяя в работе наилучшие методики и следуя

передовым тенденциям. Одним из требований является

доступность инструментов в сети, так что SaaS являются удачным

вариантом. Более того, решения SaaS не требуют наличия ИТ-

команды.

5.2. Общая производительность

Если не говорить о нишевых областях применения, для

использования в различного рода проектах, в том числе научных

и технических, существует огромный выбор универсального ПО.

В этом разделе мы подробно рассмотрим самые общие типы и

конкретные примеры.

5.2.1. Office

Офисные пакеты — одни из наиболее часто используемых

приложений, которыми особенно активно пользуются ученые:

составление документов, электронных таблиц для ведения

бюджета, описей и т.д. К самым популярным офисным пакетам

SaaS относятся:
Google Docs / G Suite: Google Docs — облачный пакет

офисных приложений, созданный Google, включает в себя

текстовый редактор, электронные таблицы и приложение

для презентаций. Бесплатная версия доступна для всех

пользователей, а платная ежемесячная подписка (G Suite),

предлагающая расширенные функции и хранилище,

доступна профессионалам и компаниям (https://www.googl

e.com/docs/about/). У G Suite множество пользователей по

всему миру, и один из ярких примеров —

транснациональная фармацевтическая компания Roche,

частная организация, занимающаяся исследованиями.

Office 365: Облачная версия популярного пакета Microsoft

предоставляет онлайновые варианты приложений Word,

Excel и PowerPoint. Предоставляется по платной годовой

подписке (https://www.office.com/).

Zoho Office: Веб-решение, помимо прочего

предоставляющее текстовый редактор, электронные

таблицы и презентации, базы данных и ПО для управления

проектами. В наличии есть бесплатная (с ограничением на

группу из 25 пользователей) и платная версия с помесячной

оплатой за каждого пользователя, который получает

расширенное пространство и функционал (https://www.zoh

o.com/docs/).

5.2.2. Коммуникации

ПО для организации чатов и коммуникаций существует уже

продолжительное время. Но в последние годы инструменты и

платформы для организации онлайн-общения набирают

популярность и пользуются все большим спросом в обществе.

Чаще всего используются следующие платформы.

Slack: это не столько коммуникационная платформа в чистом

виде, сколько ориентированный на совместную работу


инструмент со многими хорошо известными пользователю

функциями (в том числе непосредственно адаптированными из

IRC), а также интеграциями с расширенными платформами или

продуктами, такими как Jira и GitHub. Slack также поддерживает

аудио- и видеоформат. Небольшим командам подойдет и

бесплатная версия; также существует коммерческая с помесячной

оплатой за каждого пользователя (https://slack.com/).

Google Hangouts: коммуникационная платформа,

интегрированная со всеми инструментами и платформами Google

(такими как G Suite), предлагает услуги аудио- и видеосвязи (http

s://hangouts.google.com/).

Zoom: платформа для видеоконференций и звонков

предоставляет пространство для чата и возможность

обмениваться контентом (https://www.zoom.com/).

IRC: существующий с 1988 г. IRC (Internet relay chat) является

хорошо известным протоколом связи. Для разных платформ

существует выбор бесплатных клиентов. IRC не теряет

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

доступ к своим IRC-серверам, причем иногда бесплатно.

5.3. Наука и инженерия

Развивая новые модели бизнеса, такие как оплата только за

необходимые функции или ресурсы, и оптимизируя таким

образом затраты, облачное ПО для научных и технических целей

изменило правила игры в отрасли. Такой подход также позволяет

пользователям получать доступ к платформам или системам,

ранее для них закрытым. Далее мы обсудим некоторые из

подобных программ.

5.3.1. Редактирование и обмен документами (LaTeX)


На протяжении веков публикация результатов исследований была

основным способом обмена научными знаниями и

стимулирования прогресса. Совершенствованию этих процессов

способствовало несколько способов совместного редактирования

документов с помощью облачных технологий, в основном в тех

случаях, когда научный труд разрабатывался несколькими

людьми или командами. Вот несколько примеров.

Overleaf: веб-редактор LaTeX представляет собой платформу

совместного составления и публикации документов. Для

небольших и средних проектов подойдет ограниченная

бесплатная версия, в которой не может быть приватного или

защищенного контента. Также доступна годовая платная

подписка (https://www.overleaf.com). Overleaf позволяет

напрямую отправить статью в выбранный вами журнал.

LaTeX Base: еще одна доступная система совместного

редактирования, которая удовлетворит потребности большинства

самостоятельных авторов или небольших команд (https://latexbas

e.com).

5.3.2. Управление проектами и решение проблем

Одной из многих задач ученого или инженера является

отслеживание своей работы и обмен результатами с коллегами в

режиме реального времени. SaaS — отличные инструменты для

управления проектами и решения проблем — прекрасно

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

платформ.

Jira Cloud: Jira (и Atlassian) — пожалуй, самое известное ПО

для управления проектами. Эти платформы позволяют

пользователям выполнять самые разные задачи — от решения

наиболее простых проблем до осуществления комплексного

управления проектами (включая гибкие панели мониторинга и

интеграции). Также отметим еще одну систему, предоставленную


Atlassian. Trello (https://trello.com) предлагает достаточно

простую карточную систему управления небольшими проектами,

ориентированную на методику Agile. Отличная бесплатная версия

Trello обеспечивает полную интеграцию с прочими проектами

Atlassian, в том числе Bitbucket. На каждого пользователя

требуется лишь продлевать лицензию (https://www.atlassian.co

m/software/jira).

Basecamp: набор интегрированных инструментов для

управления проектами, коммуникациями и т.д., требующий

ежемесячной оплаты. Однако для использования в

образовательных целях предоставляются бесплатные версии (http

s://basecamp.com/).

Asana: эта платформа, используемая крупнейшими игроками

сферы ИТ, ориентирована на отслеживание и временные рамки.

Небольшим командам подойдет бесплатная версия; для доступа к

расширенным функциям потребуется помесячная оплата (http

s://asana.com).

5.3.3. Контроль версий

Системы контроля версий отслеживают различные модификации

файлов и как правило используются в процессе разработки ПО и

при работе с документацией. Вот несколько наиболее популярных

платформ:

Git: система, которой чаще всего пользуются сторонники

открытого ПО, была изначально создана Линусом

Торвальдсом для управления разработкой ядра Linux. Git

предлагают в качестве SaaS многие поставщики, например:

— GitHub: веб-сервис предлагает бесплатные публичные

репозитории и является центральным узлом для

сообщества свободного ПО (https://github.com/).


— GitLab: альтернатива GitHub, набирающая популярность в

последние годы, предлагает частные репозитории и

расширенные функции для тестирования и разработки.

Привлекательность GitLab в сравнении с GitHub возросла

после покупки последнего Microsoft в 2018 г., что вызвало

ряд проблем с точки зрения научной

30
воспроизводимости (https://gitlab.com/).

— Bitbucket: разработка Atlassian, которая отлично

взаимодействует с экосистемой Jira

(https://bitbucket.org).

Mercurial: представленный сообществу одновременно с Git,

Mercurial являет собой единый подход, менее сложный, чем Git.

Его используют многие крупные проекты, например Mozilla и

Nginx (https://www.mercurial-scm.org/).

SVN: Apache Subversion (SVN), одна из старейших систем

управления версиями (существует с 2000 г.), предлагает более

централизованный подход, чем Git

(https://subversion.apache.org/).

Хотя обсуждение Git не было целью написания этой книги, мы

бы настоятельно рекомендовали изучить ее основной

функционал и рабочие процессы; в целом это необходимый

31
навык .

5.3.4. Другие релевантные SaaS

Как уже упоминалось в начале главы, невозможно охватить все

продукты, предлагаемые в качестве SaaS. Каждый день

появляются новые приложения, и некоторые из них даже

вызывают удивление. Так, AWS работает с университетами,

предоставляя чат-боты, позволяющие студентам задавать

вопросы, связанные с учебой, с помощью смартфона, планшета


32
или устройства Alexa . Среди других SааS, подходящих для

научных и технических задач, можно назвать следующие.

5.3.4.1. Интегрированная среда разработки

Перечислим несколько из наиболее актуальных ИСР:

Codeanywhere: кроссплатформенная облачная ИСР,

позволяющая совместно разрабатывать программные проекты с

помощью веб-браузера на любом устройстве (https://codeanywhe

re.com/).

AWS Cloud 9: аналогична Codeanywhere, но разработана AWS

(https://aws.amazon.com/cloud9/).

Ideone: облачный инструмент для компиляции и отладки

исходного кода на нескольких языках программирования (http

s://ideone.com/).

5.3.4.2. Составление диаграмм

В облаке доступны также инструменты для совместного

рисования и создания диаграмм с использованием одного только

веб-браузера. Заинтересованному читателю мы можем

посоветовать ознакомиться с тремя инструментами: draw.io (http

s://www.draw.io/), yEd Live (https://www.yworks.com/yed-live/) и

Lucidchart (https://www.lucidchart.com/).

5.4. Саша принимает решение

Рассмотрев существующие облачные решения, посоветовавшись с

командой и принимая во внимание свои потребности и

имеющийся бюджет, Саша должен выбрать инструменты.

Возможным решением может быть такое:

Создание и совместное использование документов: G

Suite для общих документов (и обсуждений), Overleaf для


LaTeX (и совместных изданий).

Связь: Slack, т.к. это, по-видимому, современный стандарт;

кроме того, Slack включает множество полезных плагинов.

Управление задачами: Trello, потому что он бесплатный и

простой; более сложный продукт команде не требуется.

Контроль версий: GitLab, предлагающий Git с частными

репозиториями, чтобы команда могла хранить код в тайне

до тех пор, пока он не будет готов к выпуску, а также

множество бесплатных инструментов для тестирования и

разработки.

Использование других инструментов пока обсуждается,

поскольку команде необходимо прийти к общему решению,

какие стандарты (и форматы) будут использоваться.


ГЛАВА 6

Эксперименты в облаке

6.1. Саша готов приступить к новому эксперименту

Теперь, когда у Саши есть четкое представление об облачных

технологиях, а главное, о том, как получить финансирование и

как его использовать, можно приступать к новому эксперименту

или запуску проекта. С момента возникновения облачных

технологий одной из их целей было массовое распространение

ПО, что обеспечивало бы повсеместный и прозрачный доступ к

33
любым необходимым ресурсам . Запуск и разработка ПО наряду

с интерпретацией результатов являются, вероятно, самыми

распространенными задачами для ученого или инженера. Одна из

основных проблем, с которой сталкиваются разработчики ПО в

облаке, это некоторые накладки, связанные с непониманием

абсолютно распределенной природы облака (или и того хуже — с

попытками бороться с ней), где «готовые» ресурсы не всегда

совпадают с теми, какие ожидаешь получить в традиционной

среде HPC, например, сети с низкой задержкой по умолчанию.

6.2. Выполнение кода в облаке

На первый взгляд выполнение кода может показаться самым

банальным процессом. Однако порой все обстоит не так,

особенно если ПО и инфраструктура, необходимая для его

запуска, достаточно сложны. То же применимо и к научному коду.


6.2.1. Особенности разработки ПО в облаке

До появления облачной парадигмы большинство разработчиков

генерировали и запускали ПО, прибегая к двум классическим

подходам:

Использование «локальных» ресурсов — особого набора

ресурсов (например, рабочих станций) с легким и быстрым

доступом, но при этом весьма статичных. В случае, если

требовалось дополнительное оборудование, его

приходилось приобретать; иногда доступные ресурсы, такие

как пространство на диске или память, и вовсе не

использовались.

Использование инфраструктуры HPC: разработчики или

ученые из числа входящих в группу участников или

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

пулу ресурсов (например, к вычислительным узлам) и могли

запросить доступ к ресурсам более высокого уровня для

решения конкретной задачи, например, проведения

эксперимента. Доступ к любому ресурсу осуществлялся, как

34
правило, через диспетчер ресурсов или планировщик и

определялся уровнем предоставленного доступа. Доступные

ресурсы и масштабируемость зависели от возможностей

поставщика.

Отметим, что эти решения не являются бесплатными, и их

стоимость зачастую абстрагируют или скрывают от пользователя

с помощью прямого финансирования или бюджетных

35
ассигнований .

Облачные технологии предлагают кардинально иное решение,

где ресурсы весьма динамичны, и вы можете использовать

именно то, что вам нужно, тем самым сокращая объем

простаивающих ресурсов. Однако чудодейственного средства не


существует, и даже с учетом всех условий, рассмотренных нами в

предыдущих главах, прежде чем перейти на облачные

вычисления, Саше следует изучить еще несколько вопросов,

которые помогут ему понять, как написать и выполнить код в

облаке.

Подходит ли Сашино ПО для работы в облаке? Этот

вопрос может показаться очевидным, однако на деле этот

фактор способен оказаться жестким препятствием для

перехода на облако: ваше ПО в его настоящем виде нельзя

будет с легкостью развернуть в облаке. Никто, кроме вас или

разработчика вашего ПО, не сможет точно ответить на

поставленный вопрос. Скорее всего, ответ будет

положительным, но вам следует учесть такие

характеристики, как жестко запрограммированная

инфраструктура и вложения в ресурсы, в случае если

36
некоторые части кода придется переписывать .

Сколько ресурсов на самом деле требуется Саше? Этот

вопрос крайне важен: хоть и некоторая степень

неопределенности всегда допустима, Саша должен заранее

знать, какие ресурсы ему потребуются. Вот основные

вопросы, на которые ему предстоит ответить:

— Сколько требуется процессоров и памяти, в том числе —

из расчета на один узел?

— Какой требуется объем хранилища? Должен ли он быть

постоянным?

— Как долго будет работать приложение?

Заранее ответив на эти вопросы, Саша избавит себя от

серьезных проблем, таких как превышение лимитов API или, что

еще хуже, лишние траты на ненужные ресурсы. Кроме того, Саше

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


облачные ресурсы как правило более обширны, чем ресурсы

текущей инфраструктуры HPC. Эту информацию можно

получить, связавшись с поставщиком.

Каков допустимый критический уровень для Сашиного

ПО или экспериментов? Иными словами, каковы Сашины

ожидания? Код или эксперименты можно выполнять по

достаточно низкой цене, если у вас нет жестких временных

ограничений: например, если вы не возражаете против того,

что выполнение вашего кода займет больше времени.

Каким бюджетом располагает Саша? Теперь, когда все

предыдущие вопросы сняты, можно ответить на самый

главный: сколько ресурсов вам доступно? Чем точнее вы

можете ответить на предыдущие вопросы, тем корректнее

будет ответ на этот, последний. Мы подробно рассматривали

данный аспект в главе 4 этой книги.

6.2.2. Интерфейсы прикладного программирования (API)

6.2.2.1. Что такое API?

API-интерфейсы, абстракции очень высокого уровня,

обеспечивающие стандартный способ взаимодействия с ПО или

инфраструктурой, широко распространены в информатике. API

предоставляют системную точку входа или библиотечную

функцию с четко определенным синтаксисом, доступным из

прикладных программ или пользовательского кода для

предоставления четко определенного функционала. API играют

важную роль в облачных системах и могут иметь различные

формы (например, API POSIX). Базовый рабочий процесс API

показан на рис. 6.1.


Современные облачные системы как правило используют и

обеспечивают передачу состояния представления (REST) при

помощи CRUD-операций («создание», «чтение», «обновление»,

37
«удаление») и/или API GraphQL , инкапсулированных в HTTP.

Вот несколько интересных примеров такого подхода:

Примером API, построенного на основе REST, является NASA

38
Earth API , позволяющий исследовать доступные наборы

данных, в том числе изображения.

Также в открытом доступе есть несколько построенных

39
таким же образом API от Google (например, поиск) .

6.2.3. Облачное окружение и среда выполнения кода

Само по себе облако как сущность, если говорить о степени

доступа и контроля, можно рассматривать как спектр: от простого

доступа к оборудованию через API нижнего уровня до API

высшего уровня и сложных пакетов SDK. Этот спектр

неразрывный: облако — не монолит, а живая экосистема,

состоящая из подвижных компонентов, как правило

взаимодействующих и передающих друг другу информацию.

Таким образом, хоть компоненты и независимы, они имеют

тенденцию создавать взаимозависимости посредством

коммуникаций, и обычно — через API. Все доступные


компоненты — сервисы или системы, их открытые интерфейсы и

переменные параметры и составляют облачную среду,

пространство, в котором существует эта экосистема.

Понимание облачной среды — ключ к успешному запуску или

разработке ПО для облака. Однако единой облачной среды не

существует: у каждого поставщика она своя, а потому мы

рекомендуем изучить их возможности и прочитать официальную

документацию, имеющуюся в каждой облачной среде.

6.2.3.1. Почему API так важны в облаке?

Как мы говорили ранее, перейти на облако — значит

погрузиться в его среду, предоставляющую ресурсы через API и

набор разрешенных операций. Вот и другие аспекты, которые

следует учитывать:

Многие функции доступны только через API и должны быть

реализованы программным путем.

API предоставляют возможность создавать повторяющиеся

или автоматизируемые шаблоны; пользовательский

интерфейс или любые другие методы условно оптимальны и

могут со временем быть изменены.

Основные поставщики общедоступных облачных сервисов

располагают обширной и четко регламентированной

документацией по своим API, включая примеры для различных

языков программирования:

40
Azure REST API ;

41
Руководства AWS и API ;

42
Google Cloud API .

6.2.3.2. Пример использования облачного API


В качестве примера рассмотрим, как AWS EC2 делает

информацию об экземпляре доступной с помощью метаданных в

формате JSON; т.е. экземпляр может получить информацию о

себе через запрос в локальную службу, предоставляющую

метаданные. Например, для получения списка доступных

экземпляров в метаданных можно выполнить следующую

команду:

$ curl http://169.254.169.254/latest/meta-data/

Исходя из этого списка, для получения общедоступного IPv4

инстанса вводим такую команду:

$ curl http://169.254.169.254/latest/meta-data/public-ipv4/ 193.146.46.94

Очевидно, этот процесс представляет собой один из низших

уровней доступа. В этом случае к интерфейсу можно получить

прямой доступ, чтобы сделать GET-запрос с помощью curl. Этот

подход необходим лишь в определенных случаях; если возможно,

рекомендуется применять SDK, обычно предоставляемый

поставщиками облачных услуг или третьей стороной.

Использование SDK предлагает более высокий уровень

абстракции — например, взаимодействие с различными API для

разных сервисов — и упрощает написание кода. Для основных

поставщиков публичных облаков доступны следующие SDK:

43
AWS SDK ;

44
GCP SDK ;

45
Azure SDK .

Дополнительную сложность привносит концепция Регионов,

которой пользуются поставщики облачных услуг. Регион — это

географическая точка, в которой фактически расположена


инфраструктура и где управляются ресурсы. Регион — не только

физическое понятие, но и указание на то, что имеющиеся ресурсы

и даже их свойства могут отличаться. Так, на платформе GCP

доступные типы процессоров отличаются в регионах asia-east1 и

46
europe-north1 .

Когда к предыдущему примеру добавляется проблема

регионов, список запущенных экземпляров для проекта на GCP в

Python потребует следующих действий:

Установите Google Cloud SDK, как описано на официальной

странице (этот шаг выполняется только один раз).

Установите клиентскую библиотеку для Python (этот шаг

также выполняется только один раз).

$ pip install ––upgrade google–api–python–client

Как только все зависимости будут соблюдены, этот

несложный класс выдаст список работающих экземпляров:

“””

This code list the instances on a given project and zone.

Данный код выводит список экземпляров для заданного проекта и зоны

“””

import os

from pathlib import Path

import googleapiclient. discovery

# Credentials can be generated at your:

# Вы можете получить исходные данные по адресу

# https://console. cloud.google.com/iam–admin/serviceaccounts

# Put your JSON credentials file on your $HOME/.google/credentials. json

# Поместите ваш файл данных JSON в свой каталог $HOME/.google/credentials. json

os. environ [

“GOOGLE_APPLICATION_CREDENTIALS”] = “%s/.google/credentials.json”%

Path.home()
class GCPCompute(object):

“””

This class contains the logic to return a list containing the instances for a zone (for a

project).

Этот класс содержит код, возвращающий список экземпляров зоны (для проекта).

“””

def __init__ (self, project: str, zone: str):

self.compute = googleapiclient. discovery. build (’compute’, ’v1’)

self. project = project

self.zone = zone

def list_instances (self) –> list:

“””

Return a list of items (instances).

Возвращает список экземпляров.

“””

result = self.compute. instances (). list (

project =self. project, zone=self.zone). execute ()

return result. get (’items’, [])

if __name__ == “__main__”:

PROJECT = “my–experiment”

ZONE = “europe–west1-c”

GCPCOMPUTE = GCPCompute(project=PROJECT, zone=ZONE)

INSTANCES = GCPCOMPUTE.list_instances()

print(“>> Project:%s “% PROJECT)

# Just print instances names (if any):

#Просто выводит на печать имена экземпляров (при наличии)

if not INSTANCES:

print(“ \ nInstances (name) for zone%s:”% ZONE)

for instance in INSTANCES:

print(“–>%s”% instance[’name’])

else :

print(“ \nNo instances found for zone%s”% ZONE)

Результат выполнения этого кода выглядит следующим

образом:

$ python list_instances.py

>> Project: my–experiment


Instances (name) for zone europe–west1-c

–> Instance_1

–> Instance_2

–> Instance_3

6.2.4. Код в облаке: соображения

На этом этапе, с точки зрения и запуска, и написания облачного

ПО, Саше предстоит решить, начинать ли с нуля, полностью

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

для запуска в облаке, что подразумевает следующее:

Запустить cloud native-проект: разработать системы и

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

такими как API, одновременно устраняя подводные камни

облачной среды, например, низкую производительность в

определенных ситуациях.

Сделать ПО и системы пригодными для использования в

47
облаке : перенести в облако как можно больше ПО, чтобы

воспользоваться всеми преимуществами; или, в более

ограниченном числе случаев, преобразовать ПО таким

образом, чтобы оно могло хотя бы работать в облаке.

Какой бы подход Саша ни выбрал, прежде чем приступить к

реализации проекта, ему предстоит принять во внимание

некоторые другие аспекты и ограничения, компромиссы и их

последствия.

6.2.4.1. Общие аспекты

Оборудование в большинстве своем отличается высокой

степенью абстрагированности: зачастую предоставляемая

системой информация не отражает реальность: например,

это можно сказать о вычислительных юнитах AWS EC2.


Данная особенность может осложнить точную настройку,

например, отдельные флаги компилятора.

Некоторые системы совместно используют ресурсы: т.е.

ресурсами ЦП или подсистемы IOPS могут пользоваться и

другие клиенты облака, что способно привести к

неожиданным результатам, например непрерывному

использованию ЦП или недостаточной производительности

дисков.

Всегда используйте API по умолчанию и избегайте

применения пользовательского интерфейса: некоторые

ресурсы доступны только в таком виде.

Воспользуйтесь преимуществами готовых систем и

компонентов: такие технологии, как контейнеры (Docker

или Kubernetes) и PaaS (например, Hadoop как услуга),

могут значительно сэкономить время на настройке

инфраструктуры.

6.2.4.2. Сеть

Время задержки: сетевая задержка — это один из аспектов,

оказывающий большое влияние на код, особенно научный,

использующий такие технологии, как MPI и сети с низким

значением задержки (например, InfiniBand). Большинство

поставщиков, хоть некоторые из них и заявляют о

сверхнизком значении задержки, по умолчанию предлагают

сеть, предназначенную для общих целей, что может

ощутимо снизить производительность научных

приложений. Следовательно, главная рекомендация —

рассматривать доступную оптимизацию (некоторые

поставщики предлагают оптимизированные для HPC среды

отдельно от стандартных опций) и провести

первоначальную оценку, например, проведя

предварительный запуск, чтобы определить, какое влияние

будет оказано на приложение. Кроме того, можно


пересмотреть структуру своего ПО в таком ключе, чтобы

вертикальная масштабируемость набрала вес в сравнении с

горизонтальной и коммуникациями с низким значением

задержки.

Ограниченное устранение неполадок: в облачной среде

этот процесс ограничен, что объясняется характером сетей и

их абстракцией.

Близкое взаимодействие и распределение оборудования:

по умолчанию распределение таких ресурсов, как

экземпляры, ограничено, как правило, рамками региона.

Это ограничение может стать проблемой для приложений,

требующих низких значений задержки и высокой привязки

к процессорным ядрам. Этот вопрос следует обсудить с

поставщиком: он может предложить индивидуальные

решения, например, отдельные среды, по запросу.

Частные сети: некоторые сети, которые должны быть

доступны из Сашиных систем или сервисов, могут не быть

доступны напрямую. Так, частное исследовательское

учреждение может предоставить доступ к определенным

данным, которые могут потребоваться для экспериментов,

только по своим частным сетям. Возможным решением

может стать VPN, однако поставщикам оно доступно далеко

не везде и не всегда.

6.2.4.3. Хранилище данных

Неограниченное пространство: одно из главных

преимуществ облака — высокий уровень абстракции от

ресурсов и их представления, что делает хранилище

практически бесконечным, точнее, ограниченным только

лишь бюджетом. Это можно рассматривать как

преимущество по сравнению с локальной инфраструктурой,

где для увеличения объема хранилища требуется провести


более или менее сложный набор операций, например,

монтаж или настройку нового оборудования.

Различные уровни хранения: в дополнение к предыдущему

пункту абстракция может также предоставить доступ к

различным уровням хранения — от быстрого и дорогого для

частого использования до медленного и недорогого для

резервного копирования или редкого использования.

6.3. Запуск эксперимента в облаке

На данном этапе Саша обладает достаточными знаниями для

запуска эксперимента. Повторим несколько моментов, которые

ему следует учесть.

Управление проектами: хоть это и не обязательно,

настоятельно рекомендуется использовать инструмент для

управления проектами. Более того, Саше нужно следовать

48
четко установленной рабочей методологии , что повысит

вероятность успеха.

Контроль версий: для поддержки и совместного

использования кода и документации Саше надо применять

систему контроля версий, например Git.

Выбор поставщика и технологий, которые предстоит

использовать: рекомендуется также просчитать все

зависимости и затраты.

6.3.1. Пример: эксперимент по классификации месяцев

Новый Сашин проект — простое ПО, которое классифицирует

месяцы по свойственной им облачности. Саша планирует

использовать имеющиеся средства для исследований на AWS. В


первичном подходе источником данных будет API Earth data

49
NASA . Вот какие технологии и поставщик потребуются Саше.

Поставщик облачных услуг: пусть в данном случае это

AWS.

Технологии:

— Язык программирования и библиотеки: Python 3 и

NumPy.

— Инструментарий: интерфейс командной строки AWS.

— Сторонние API: API Earth data NASA.

— Облачные технологии/сервисы: AWS EC2 (вычисления) и

S3 (хранение).

ПО будет названо classificator.py. Архитектура очень высокого

уровня и рабочий процесс показаны на рис. 6.2.

Предварительные требования:
— Этот шаг предполагает, что в AWS корректно созданы

необходимое виртуальное частное облако (VPC) и

подсеть (более подробную информацию о том, как

настроить VPC и подсеть, можно найти в официальной

50
документации ). В данном примере созданная подсеть

получает идентификатор subnet-1a2b3c4e.

— Для доступа к экземпляру через SSH может потребоваться

действительная/созданная пара ключей. Создать ее

можно в консоли AWS (UI): EC2 Manager → Key Pairs →


Create Key Pair). В данном примере парой ключей будет

nasa-experiment.

— Создается бакет S3: это можно сделать в консоли AWS

(UI) в разделе S3 → Create Bucket. Код classificator.py

расположен в бакете с открытым доступом, чтобы его

можно было загрузить из экземпляра.

Этот скрипт вызовет экземпляр t2.micro под управлением

Amazon Linux (ami-047bb4163c506cd98) в подсети subnet-

1a2b3c4e, доступ к которой осуществляется через SSH с

51
использованием ключа nasa-experiment .

Первая часть кода создает на AWS базовую инфраструктуру,

состоящую из одного экземпляра из предлагаемого бесплатного

уровня. Это простой сценарий командной оболочки, который

52
использует интерфейс командной строки AWS .

#!/ bin /bash

# AMI — идентификатор для Amazon Linux

aws ec2 run–instances ––region eu–west-1 ––image–id ami-047

bb4163c506cd98 ––count 1 ––instance–type t2.micro ––key–name nasa

— experiment ––subnet–id subnet-1a2b3c4e ––instance–initiated–

shutdown–behavior terminate ––user–data file://${PWD}/scripts/boot.sh

Содержимое загрузочного скрипта “boot.sh”,

устанавливающего зависимости и запускающего код


53
моделирования, таково :

#!/ bin /bash

yum update –y

amazon–linux–extras install python3

pip install numpy boto

# Получение кода скрипта классификатора из общедоступного URL (в данном случае

тот же бакет)

curl https://s3-eu–west-1.amazonaws.com/nasa–experiment/classifier.py –o

/tmp/ classifier.py

chmod +x /tmp/ classifier .py

/tmp/ classifier .py

# Вычисления и выгрузка завершены: экземпляр прерывает работу

shutdown –h now

Основные этапы моделирования таковы:

Получить данные об облачности в течение месяца из API

NASA.

Учитывая эти данные, рассчитать средний показатель за

месяц и наиболее типичный для этого месяца день.

Загрузить результат в объект AWS S3.

Отправить пользователю сообщение об успешном

завершении операции.

Наконец, вот как будет выглядеть код classificator.py:

import json

import numpy

import os

import requests

import tempfile

import boto

import boto.s3

from calendar import monthrange

from datetime import datetime

from boto.s3.key import Key


# Константы: ключи API и секретные ключи доступа

NASA_API_KEY = “NASA_API_KEY”

AWS_ACCESS_KEY_ID = ’XXX’

AWS_SECRET_ACCESS_KEY = ’YYY’

S3_BUCKET = ’MY_EXPERIMENT_BUCKET’

# Константы: дата в формате ГГГГ–ММ

DATE = «2016–07»

# Константы: долгота и широта

LON = «–7.8987052»

LAT = “42.3384207”

class S3(object):

def __init__ (self):

self ._conn = boto.connect_s3(AWS_ACCESS_KEY_ID,

AWS_SECRET_ACCESS_KEY)

self ._bucket = self ._conn. create_bucket (

S3_BUCKET, location=boto.s3.connection.Location.DEFAULT)

def upload(self, source_file, target_file):

k = Key(self ._bucket)

k.key = target_file

k. set_contents_from_filename (source_file)

class Month(object):

def __init__ (self, longitude, latitude, date, api_key):

self. _longitude = longitude

self. _latitude = latitude

self. _date = date

self ._api_key = api_key

self. _baseurl = “https://api. nasa.gov/ planetary / earth /imagery/”

self ._req = requests

# День месяца

self ._monthdata = {}

def _getData(self):

year, month = self. _date. split (’–’)

mrange = monthrange(int(year), int (month))

print(“> Receiving data from API … “)

for day in range(1, mrange[1] + 1):

day_date = “{}–{}”.format(self. _date, day)

day_url = “{base}?lon={lon}&lat={lat}

&date={date}&cloud_score=True
&api_key={api_key}”.format(base=self. _baseurl,

lon=self. _longitude, lat =self. _latitude,

date=day_date, api_key=self ._api_key)

# Оптимизация может заключаться в том, чтобы делать меньше запросов к API

(ближайший день от API).

# а также с целью использования многопроцессорного пула для

# параллельных запросов

day_data = self ._req. get (day_url)

day_data_json = day_data. json ()

response_date = datetime. strptime (

day_data_json[’ date ’], ’%Y–%m–%dT%H:%M:%S’)

response_simple_date = “{}–{}–{}”.format(

response_date. year, response_date.month, response_date.

day)

# Добавление данных только в случае, если их еще нет

if response_simple_date not in self ._monthdata:

self ._monthdata[response_simple_date] = day_data_json

def _getAverageDay(self):

self ._getAverageCloudScore()

closest_average_day = ’ ’

average_distance = 1

for day in self ._monthdata:

day_avg_distance = numpy.absolute(

self ._monthdata[day][’ cloud_score ’] — self.

_average_cloud_score)

if (day_avg_distance < average_distance):

# Помечаем этот день как наиболее близкий к среднему значению

average_distance = day_avg_distance

closest_average_day = day

self. _closest_average_day = closest_average_day

self ._writeTempFile()

def _getAverageCloudScore(self):

cloud_scores = []

for day in self ._monthdata:

cloud_scores.append(self ._monthdata[day][’ cloud_score ’])

self. _average_cloud_score = numpy.mean(cloud_scores)

def _writeTempFile(self):

new_file, filename = tempfile.mkstemp()

print(“> Writing local temp file:%s”% filename)

os. write (new_file, json.dumps(

self ._monthdata[self. _closest_average_day]))

os. close (new_file)


def _writeOutput(self):

print(“ “)

print(“> Month Average Cloud Score for%s:%s”% (DATE, self.

_average_cloud_score))

print(“> Average Day Date (YYYY–MM–DD):%s (avg.:%s)”%

(self. _closest_average_day, self ._monthdata[self.

_closest_average_day][’ cloud_score ’]))

def process (self):

self ._getData ()

self ._getAverageDay()

self. _writeOutput ()

self ._uploadS3()

if __name__ == “__main__”:

month = Month(LON, LAT, DATE, NASA_API_KEY)

# Обработка данных за месяц

month.process ()
ГЛАВА 7

Бессерверные эксперименты в

облаке

7.1. Саша пересматривает эксперимент

Потратив некоторое время на проведение небольшого

эксперимента в облаке с помощью EC2, т.е. прибегнув к

классическому подходу, Саша понял, что подход оказался

слишком сложным. Привлекательное решение этой проблемы

предлагают бессерверные вычисления. Как мы поняли из раздела

3.6, существует ряд примеров применения бессерверных

технологий в области научных исследований. Саша решает

изучить, может ли такой вариант упростить код, настройку и

процесс моделирования, выполняемый его командой. Давайте

рассмотрим, что такое бессерверные вычисления и как они могут

упростить реализацию облачных.

7.2. Бессерверный подход

54
Функция как услуга (FaaS), или бессерверные вычисления , —

это относительно новая модель в рамках облачной парадигмы, в

которой ПО работает в крайне абстрагированной и ограниченной

среде, а разработчик совсем мало контролирует процесс, взамен

получая автоматизированную и автономную инфраструктуру.

Бессерверные вычислительные платформы отличаются по

степени абстракции от тех платформ, которые оставляют за


разработчиками некоторую степень контроля, например App

Engine от Google, где можно выбрать тип машины и установить

сторонние пакеты, до таких FaaS, как AWS Lambda, среда

выполнения которой полностью определяется AWS, и

разработчику приходится адаптировать свой код к ограничениям.

55
Создание или переделка решения для FaaS требует

переосмысления некоторых аспектов, например, того, как

запускать функцию и как передавать данные; бессерверные

вычисления не подходят для решения любой проблемы, но весьма

выгодны для реализаций определенного типа. Если Саше

действительно нужен контроль над собственными ресурсами,

например операциями ввода-вывода, или если его проект

обладает специфическими или индивидуальными требованиями,

такими, например, как обязательное наличие функции

пользовательской библиотеки, то бессерверные вычисления не

будут наилучшим решением. Однако, если Сашино ПО

достаточно универсально, если в нем используется основной язык

со стандартными числовыми модулями, то бессерверные решения

могут оказаться оптимальными.

7.2.1. За и против

За

Упрощенный рабочий процесс: это преимущество не

только определяет, но и оправдывает использование

бессерверных вычислений вместо любой другой облачной

службы. Поставщик облачных решений располагает

необходимым опытом для поддержания инфраструктуры, а

значит разработчик может сосредоточиться на

генерировании и внедрении ПО.

Лучший контроль над затратами: в сфере бессерверных

вычислений, как правило, придерживаются схемы оплаты


по факту использования, при которой поставщик взимает

плату только за конкретные использованные ресурсы на

более детальном уровне, чем в случае с любым другим

облачным сервисом.

Против

56
Сложность с точки зрения больших задач HPC :

выделение большого объема ресурсов требует

планирования с участием поставщика облачных услуг; в

противном случае может возникнуть ситуация, при которой,

например, мощность процессора, необходимая для работы

приложения, окажется недоступна.

Чем выше уровень абстракции, тем ниже уровень

контроля: иллюстрацией может служить ситуация, при

которой Сашино ПО пострадает от недостаточной

производительности из-за использования неправильных

ресурсов. Как мы помним, Саша не контролирует многие из

них: ресурсы выделяет поставщик, и они могут не подходить

для решения Сашиной проблемы.

Специфичный код: в некоторых случаях Сашиному

приложению может потребоваться индивидуальный код,

доступный только у конкретных поставщиков, т.е.

нестандартный код, ведущий в некоторой степени к

привязке к одному поставщику. Кроме того, Саше нужно

знать, возможен ли рефакторинг кода ресурсов с целью

запуска в бессерверной среде.

7.3. Пример: Классификатор месяцев. Бессерверная версия

Пересмотрев эксперимент с классификатором, описанный в

предыдущей главе, и проанализировав текущую ситуацию с


развитием технологии и тенденций в сфере облачных

вычислений, Саша решает, что его классификатор станет

отличным проектом для бессерверной реализации, и вот по каким

причинам:

Исследователям не придется учитывать некоторые

требования и зависимости, такие как экземпляры EC2 или

VPC.

Код (Python 3) является стандартным и относительно

простым.

Дополнительные расходы, связанные с инфраструктурой,

будут сокращены благодаря использованию

вычислительных ресурсов строго по мере необходимости.

В данном случае Саша располагает финансированием для GCP,

57
поэтому выбирает Google Cloud Functions . Вот некоторые

детали:

Поставщик облачных услуг: предположим, что в данном

случае это GCP.

Технологии:

— Язык программирования и библиотеки: Python 3 и

NumPy.

— Сторонние API: Earth data API NASA.

— Облачные технологии/сервисы: Google Cloud Functions и

Google Cloud Storage (GCS).

Высокоуровневая архитектура и рабочий процесс

представлены на рис. 7.1.

Предварительные требования:
— Действительные учетные данные (учетная запись

службы) с разрешением на управление как облачными

функциями, так и облачным хранилищем. Самый

простой способ получить учетные данные —

58
использовать Google Cloud SDK и аутентифицировать

текущий сеанс с помощью следующей команды, чтобы

предоставить ссылку для открытия и проверки сеанса:

$ gcloud auth login

— Создать бакет GCS. Сделать это можно, выполнив

следующую команду:

$ gcloud mb gs:// MY_EXPERIMENT_BUCKET


Обратите внимание: данный код упрощен и не предназначен

для практического применения. Кроме того, это так называемый

синхронный запрос, используемый в качестве примера (а

длительные синхронные HTTP-запросы обычно не рекомендуется

применять). Данный код является вариацией представленного в

разделе 6.3.1 кода, адаптированного для облачных функций

Google. Вот в чем состоят его основные отличия:

Все требования обрабатываются на стороне сервера, и о

разрешении заботится Google (согласно файлу

requirements.txt).

Выходные данные и журналы, полученные облачной

платформой, отображаются в пользовательском интерфейсе

(в данном случае это Google Cloud Logs / Stackdriver).

Аутентификация и память, характерные для AWS, заменены

аналогами GCS.

Несмотря на эти различия, логика моделирования остается

неизменной:

В данном случае код запускается конечной точкой HTTP,

созданной Google Cloud Functions для этого эксперимента.

Далее следует получение оценки облачности за месяц

(ежедневные значения) из API NASA.

С учетом этих данных производится расчет: определяется

средний показатель облачности за месяц и наиболее

типичный день для этого месяца (ближайший к среднему

значению).

Результаты загружаются в объект облачного хранилища

Google.

Пользователю отправляется сообщение об успешном

завершении задачи.
Для запуска этой программы требуются два файла:

содержащий требования (requirements.txt, используемый для

разрешения зависимостей) и собственно код моделирования

main.py).

Содержимое файла requirements.txt выглядит так:

numpy

google–cloud–storage

Содержимое файла main.py выглядит следующим образом:

import json

import numpy

import os

import requests

from calendar import monthrange

from datetime import datetime

from google.cloud import storage

# Константы: ключи API и секретные ключи доступа

NASA_API_KEY = “NASA_API_KEY”

AWS_ACCESS_KEY_ID = ’XXX’

AWS_SECRET_ACCESS_KEY = ’YYY’

GCS_BUCKET = ’MY EXPERIMENT BUCKET’

# Константы: дата в формате ГГГГ–ММ

DATE = «2016–07»

# Константы: долгота и широта

LON = «–7.8987052»

LAT = “42.3384207”

class Month(object):

def __init__ (self, longitude, latitude, date, api_key):

self. _longitude = longitude

self. _latitude = latitude

self. _date = date

self ._api_key = api_key

self. _baseurl = “https://api. nasa.gov/planetary/earth/imagery/”

self ._req = requests

# Данные за месяц

self ._monthdata = {}
def _getData(self):

year, month = self. _date. split (’–’)

mrange = monthrange(int(year), int (month))

print(“> Receiving data from API … “)

for day in range(1, mrange[1] + 1):

day_date = “{}–{}”.format(self. _date, day)

day_url = “{base}?lon={lon}&lat={lat}&date={date}&

cloud_score=True&api_key={api_key}”

. format(base=self. _baseurl, lon=self. _longitude,

lat =self. _latitude,

date=day_date, api_key=self ._api_key)

# Оптимизация может заключаться в том, чтобы делать меньше запросов к API

(ближайший день от API).

# а также с целью использования многопроцессорного пула для

# параллельных запросов

day_data = self ._req. get (day_url)

day_data_json = day_data. json ()

response_date = datetime. strptime (

day_data_json[’ date ’], ’%Y–%m–%dT%H:%M:%S’)

response_simple_date = “{}–{}–{}”.format(

response_date. year, response_date.month, response_date.

day)

# Добавляем данные только если их еще нет

if response_simple_date not in self ._monthdata:

self ._monthdata[response_simple_date] = day_data_json

def _getAverageDay(self):

self ._getAverageCloudScore()

closest_average_day = ’ ’

average_distance = 1

for day in self ._monthdata:

day_avg_distance = numpy.absolute(

self ._monthdata[day][’ cloud_score ’] — self.

_average_cloud_score)

if (day_avg_distance < average_distance):

# Отмечаем текущий день как наиболее близкий к среднему

average_distance = day_avg_distance

closest_average_day = day

self. _closest_average_day = closest_average_day

def _getAverageCloudScore(self):

cloud_scores = []

for day in self ._monthdata:


cloud_scores.append(self ._monthdata[day][’ cloud_score ’])

self. _average_cloud_score = numpy.mean(cloud_scores)

def _writeResultFile (self, filename, file_content):

# Записываем файл результатов в бакет GCS

client = storage. Client ()

bucket = client. get_bucket (GCS_BUCKET)

blob = bucket.blob(filename)

blob. upload_from_string (str (file_content))

def _writeOutput(self):

# Эти данные будут записаны в журнал выполнения функции

print(“ “)

print(“> Month Average Cloud Score for%s:%s”% (DATE, self.

_average_cloud_score))

print(“> Average Day Date (YYYY–MM–DD):%s (avg.:%s)”% (

self._closest_average_day, self._monthdata[self.

_closest_average_day][’ cloud_score ’]))

def process (self):

self ._getData ()

self ._getAverageDay()

self. _writeOutput ()

# Запись среднемесячного значения в хранилище

self. _writeResultFile (“%s_%s”% (DATE, “month_average”), self.

_average_cloud_score)

# Запись наиболее типичных данных для дня (усредненных) в хранилище

self. _writeResultFile (“%s_%s”% (DATE, “day_average”), self.

_closest_average_day)

def classifier (request):

month = Month(LON, LAT, DATE, NASA_API_KEY)

# Обработка данных за месяц

month.process ()

return f”Computation completed! Results available on the GCS Bucket.”

Как только код будет готов, его можно развернуть в облачную

функцию с помощью простой команды:

$ gcloud functions deploy start_simulation ––runtime python37 ––trigger

— http
Эта команда вернет информацию о нашей функции, например

о ее конечной точке (httpsTrigger url), которая будет

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

функция выглядит так: https://us-central1-OUR-

EXPERIMENT.cloudfunctions.net/simulation. Команда для запуска

моделирования выглядит следующим образом:

Рамка открывается.

$ curl «https://us–central1–OUR–EXPERIMENT.cloudfunctions.net/

simulation»

Как только моделирование будет завершено, его можно

удалить с помощью команды gcloud:

$ gcloud functions delete simulation

7.4. Пример: Бессерверный сбор данных с датчиков

После успешного запуска классификатора в облаке Google

Сашина команда рассматривала возможность использовать новые

знания для решения другой проблемы, которая беспокоит их уже

продолжительное время: данные API NASA — это прекрасно, но

все же не совсем то, что им требуется. Сашина команда больше

заинтересована в данных по конкретному региону: для этого они

развернули сеть высокочувствительных датчиков, с которых

можно получать данные в режиме реального времени. И теперь

исследователям нужен легкий способ сбора этих данных.

Поскольку команда уже знает, как запустить бессерверный

код, Саша предлагает простую функцию, которая будет заносить

данные с датчика в файл; а команда в свою очередь сможет

считывать результаты непосредственно из своего бакета GCS.

Вероятнее всего, Саша начнет с использования программы вроде

Datastore. Рабочий процесс схематично показан на рис. 7.2.


59
Вот как это будет реализовано :

Содержимое файла requirements.txt:

google–cloud–storage

Содержимое файла main.py:

import time

import json

from google.cloud import storage

# Константы

GCS_BUCKET = ’MY_EXPERIMENT_BUCKET’

def writeSensorData(sensor_id, sensor_value):

# Запись файла результата в бакет GCS

timestamp = int (time. time ())

filename = “sensor_%s_%s”%(sensor_id, timestamp)

client = storage. Client ()

bucket = client. get_bucket (GCS_BUCKET)


blob = bucket.blob(filename)

blob. upload_from_string (str (sensor_value))

def sensor (request):

# sensor_id и sensor_value являются обязательными аргументами

request_json = request. get_json ()

if request. args and ’ sensor_id ’ in request. args and ’ sensor_value ’ in

request. args:

args = request. args. to_dict ()

writeSensorData(args [’ sensor_id ’], args [’ sensor_value ’])

return f ’OK’

return f ’Missing Arguments!’

Код разворачивается с помощью следующей команды:

$ gcloud functions deploy sensor ––runtime python37 ––trigger–http

Рамка закрывается.

Теперь для начала передачи данных бессерверному

микросервису сенсорам просто нужно вызвать URL-адрес:

curl «https:///us–central1–OUR–EXPERIMENT.cloudfunctions.net/sensor?

sensor_id=<SENSOR_ID>&sensor_value=<SENSOR_VALUE>”
ГЛАВА 8

Этические и юридические аспекты

облачных технологий

Рассмотрение этических и правовых вопросов в рамках этой

книги оказалось более сложным, чем казалось изначально. Во-

первых, Саша должен понимать: и научные исследования, и

информационные технологии являются обособленными сферами

деятельности. При проведении эксперимента Саше в зависимости

от конкретного проекта может потребоваться одобрение

комитета по этике. Кроме того, он должен следовать научной

методике, чтобы позаботиться о воспроизводимости и сделать

свою работу полезной для других.

Этика в области ИТ не очень отличается от этики в остальных

сферах жизни. Учитывая, что Саша, скорее всего, не

разрабатывает большую часть своего программного и

аппаратного обеспечения самостоятельно, ему следует

учитывать, какое ПО он использует и как оно было разработано.

Несколько десятилетий назад на этот факт обратил внимание

Ричард Столлман, инициировавший Движение за свободное ПО.

Это движение является частью деятельности таких организаций,

как Фонд свободного ПО и Фонд электронных границ.

Популяризация интернета превратила вопрос защиты данных

в новую острую проблему. В некотором смысле использование

облачных вычислений сопряжено с теми же юридическими

проблемами, что и работа с многими другими сервисами в

интернете. Например, Саше нужно знать, работает ли выбранная


60
им SaaS под лицензией типа Affero GPL (AGPL) и разработана ли

она специально для облака. Это гарантировало бы, что

запущенное в облаке ПО является бесплатным и Саша может

получить доступ к исходному коду.

Компании, продающие услуги облачных вычислений, должны

первыми обеспечить максимальную прозрачность и соответствие

высочайшим стандартам. Среди пользователей этих сервисов есть

национальные ведомства, например военное, что требует

предельного уровня безопасности. К счастью, компании,

предоставляющие облачные сервисы, должны соблюдать

строжайшие стандарты качества ISO, что обеспечивает высокий

уровень их ответственности.

Около 10 лет назад была выдвинута инициатива по разработке

«Манифеста облачных вычислений»: он должен был вытекать из

сотрудничества, основанного на бесплатных инструментах с

участием индустрии. Это был следующий шаг после «Билля о

правах на облачные вычисления»; однако ключевые игроки в

конечном итоге решили его все же не подписывать, и в 2012 г.

идея провалилась. Проекты манифеста были сугубо техническими

и ориентированными на разработку бизнес-модели облачных

вычислений. Однако они также включали идею возможности

61
взаимодействия «облаков». В недавней работе этические

вопросы облачных вычислений классифицируются по четырем

категориям: приватность и безопасность, соответствие

требованиям, функциональная этика и воздействие на

окружающую среду, что мы уже обсуждали в разделе 3.5. Первая

категория касается типичного для нас беспокойства о

конфиденциальности данных, вторая — правильного уровня

стандартов. Функциональная этика относится к предоставлению

услуг, обещанных по контракту. Фактически эти три проблемы

связаны с общей «деловой этикой» и применимы независимо от

того, используется облако или нет. Последствия использования

облачных вычислений в этой области привели к появлению таких


62
относительно недавних проектов, как SafeCloud ,

финансируемый Европейским союзом.

На этом этапе Саша может использовать облачные ресурсы для

исследований на любом уровне реализации или в любой

комбинации, представленной в предыдущих главах.

Обеспокоенность в этой связи вызывают лишь данные. Передача

собственной информации другим всегда поднимает юридические

и этические вопросы, которые нельзя не принимать во внимание.

Этические вопросы, связанные с возможным извлечением

информации из сохраненных данных, могут и не представлять

особой проблемы, если речь идет о личных фото или электронных

письмах; но все будет иначе, если сохраненные данные включают

записи о пациентах, участвующих в клинических испытаниях.

Так, для решения последнего вопроса AWS реализует меры по

защите медицинских данных и соблюдению таких законов, как

63
Закон США о HIPAA . Однако зачастую хранение данных может

вызывать серьезные затруднения, скажем, при использовании

данных, переданных третьей стороной, например, частной

компанией. В таких случаях количество копий данных и место их

хранения могут быть установлены предыдущим контрактом,

вступающим в противоречие с новым, подписанным с вашим

поставщиком облачных услуг. Ярким примером является

прецедент, когда Google получил доступ к медицинским записям

64
американцев .

Более того, все детали, связанные с используемым в научных

исследованиях ПО, включая данные о версиях и лицензии,

65
которая должна быть свободной , должны быть доступны и

известны, поскольку это является обязательным условием для

обеспечения научной воспроизводимости результатов. Повышать

воспроизводимость научных вычислений действительно

необходимо; а значит, нужно обеспечить соответствие облачных

вычислений требованиям. Это соображение также поможет


избежать привязки к одному поставщику. Например, вам может

понадобиться перенести свои операции и данные, совершив

переход от одного поставщика к другому. С технической точки

зрения этот процесс будет намного проще, если вы будете

обладать полной информацией о вашей текущей инфраструктуре.

Таким образом, используя облачные технологии, Саша должен

понимать, что не будет обладать полным контролем над тем, чем

делится. Например, государственные органы могут принудить

поставщика раскрыть Сашины данные из-за юридических

проблем. Таких сценариев известно немало, среди них

66
подписанный в октябре 2019 г. Cloud Act . Данный сценарий

применим только к незначительной части научных исследований;

порой выявляется и некая противозаконная деятельность. Однако

важнее всего то, что, используя облачные решения, Саша теряет

право принимать окончательное решение о том, делиться ли ему

своими данными — хотя здесь существуют дополнительные

возможности, например, использование зашифрованного

облачного хранилища. Кроме того, Саша должен отдавать себе

отчет: данные, хранящиеся в облаке, могут не подпадать под те

же законы и правила, что действуют в его стране или

юридической сфере, поскольку инфраструктура,

предоставляющая облачный сервис, может быть расположена в

нескольких странах, а компания может располагаться в другом

государстве. Таким образом, данные могут существовать в

потенциально совершенно разных правовых условиях. Точные

условия в некоторой степени зависят от контракта, который

пользователь подписывает с поставщиком (а они могут быть

самыми разными), и от того, как поставщик применяет

67
контракт . В других случаях местные законы, например, правила

Европейского союза, могут оказаться несовместимыми с

законами других регионов. Вы должны понимать: возможно, вам

придется отдельно выбирать, проводить ли исследование и

хранить ли данные в дата-центрах в том же регионе, где


располагается ваше учреждение или финансирующий орган. Дело

не только в законах, применяемых к данным, но и в праве членов

Сашиной команды получать доступ и к ним, и к ресурсам, порой

доступным только определенному кругу лиц, получивших допуск

или обладающих «правильным» паспортом.


ГЛАВА 9

Вы отстаете от жизни: мы уже

обновляем эту книгу

Прошу прощения, вы что, из прошлого?

Рой, «Компьютерщики»

Инновации происходят постоянно, и их скорость никогда не была

равномерной — и то, и другое не вызывает сомнений. За

прошедшее столетие темпы прогресса возросли как никогда. В

таких сферах, как ИТ, инновации являются важнейшим

фактором. Облачные вычисления в последние годы стали

доминирующей технологией, стимулирующей процесс

обновления и рост доходов в бизнесе. Облачные технологии

развиваются и адаптируются, реагируя на желания и потребности

людей управлять данными и устройствами такими способами,

которые выходят за рамки чисто технологических, а значит, есть

все основания в ближайшие несколько лет ожидать значительных

улучшений.

Очевидно, стратегии некоторых поставщиков облачных

сервисов будут включать более сложные решения и расширение

набора услуг, традиционно используемых в локальных

вычислительных системах, в облаке. Так, Google не так давно

объявила, что делает несколько блокчейн-технологий

доступными в своих облачных сервисах. Помимо этого, четко

просматривается курс на интеграцию искусственного интеллекта

как дополнительной услуги, которую можно предложить вместе с


облачными решениями для разных целей, например, для

датамайнинга. У данного вида услуг большой потенциал, т.к. в

ряде случаев вам нужно всего лишь разрешить доступ к данным,

уже хранящимся в облаке: так, не прикладывая никаких

дополнительных усилий, вы получите последующий анализ,

соображения или рекомендации, которые в конце концов могут

привести к новым идеям и результатам, совершенствованию

управления или других практик.

Поскольку использование облачных сервисов продолжает

набирать обороты, можно ожидать значительного развития такой

сферы бизнеса, как консалтинг по вопросам адаптации

существующих рабочих сред — лабораторий, компаний и т.д. — к

облачным вычислениям, как и по оценке и выполнению перехода.

Другая развивающаяся область — квантовые вычисления,

технология, явно не подходящая пользователям ПК. Невозможно

себе представить, чтобы квантовый компьютер мог

функционировать вне лаборатории, где созданы особые условия

вроде поддержания самых немыслимых низких температур.

Следовательно, квантовые вычисления, скорее всего, будут

работать как облачный сервис — нечто подобное уже предлагает

IBM через свой IBM Q Experience (https://www.ibm.com/quantum-

computing/technology/experience/): единственное, что меняется в

этой технологии — это оборудование, используемое для

предоставления услуги. Из этого мы можем сделать вывод, что в

будущем любая попытка развивать квантовые вычисления будет

следовать облачной парадигме. Хоть такого рода утверждения в

ИТ могут устареть всего за несколько лет, мы можем утверждать:

никто не ожидает в обозримом будущем продажи первого

физического квантового компьютера.

Предполагается, что повсеместное внедрение облачных

технологий повлечет за собой инвестиции в улучшение качества

интернет-соединений по всему миру. По некоторым прогнозам, к

концу следующего десятилетия мы не будем говорить ни о


подключении, ни об использовании облака: все будет

взаимосвязано, в том числе такие технологии, как интернет

вещей. Кроме того, одним из развивающихся направлений

исследований, связанным с сетями в облачных вычислениях,

является изучение подобных технологий для укрепления

кибербезопасности, например, для повышения устойчивости к

DDoS-атакам.

Как ученый, Саша подает заявки на финансирование и

управляет выделенными средствами. Возможно, он задумывается

о новом компьютере, который нужно приобрести для следующего

исследовательского проекта. Если Саша не рассматривает более-

менее портативное устройство вроде ноутбука или компактного

ПК, то он застрял в прошлом. Помимо приватности и наличия

постоянного доступа к наиболее релевантным данным,

необходимым ежедневно или в течение нескольких дней, нет

никаких причин хранить данные на большой машине. Если вам

знакомо выражение «рабочая станция» и вы привыкли так

работать, загляните в Википедию: она говорит о компьютерах

такого типа в основном в прошедшем времени.

Вас может беспокоить вопрос: что будет, если я отправлюсь

куда-то, где нет интернета, и не смогу получить доступ к своим

данным? Что ж, полностью эта проблема не исчезнет, но в

некоторых регионах мира такое опасение сродни беспокойству о

наличии электросети. А есть и такие места, где ваши шансы

получить доступ в интернет будут выше, чем найти выключатель.


Глоссарий

Agile (или Agile software development) — термин,

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

основанные на кросс-функциональных самоорганизованных

командах, цель которых — предоставлять продукты и услуги,

постоянно совершенствуя и ускоряя процессы. Примеры

применения Agile-подхода — деятельность Scrum, Kanban и

DevOps.

Alexa — разработка Amazon; устройство, исполняющее через

подключение к облаку функции персонального помощника.

Apache (или Apache HTTP Server) — один из самых

популярных веб-серверов.

API (или API-интерфейсы) — программные интерфейсы,

представляющие собой абстракции (очень) высокого уровня,

обеспечивающие стандартный способ взаимодействия с

программным обеспечением или инфраструктурой.

AWS (сокр. от Amazon Web Services) — платформа облачных

вычислений от Amazon.

AWS Lambda — бессерверный вычислительный сервис,

пример FaaS.

Azure — платформа облачных вычислений от Microsoft.

BOINC — свободное промежуточное программное

обеспечение для грид-вычислений, разработанное

Калифорнийским университетом (Беркли) и широко

применяемое для добровольных вычислений.

Cloud native — программное обеспечение или система,

разработанные для использования всех возможностей, которые

предлагает облачная среда. Как правило, Cloud native ПО не


может работать или теряет многие свои функции вне облачной

среды.

CNCF (сокр. от Cloud Native Computing Foundation) — часть

Linux Foundation, созданная для продвижения концепции

облачных вычислений, а также содействия созданию и развитию

экосистемы.

cPanel — онлайн-панель управления веб-хостингом на базе

Linux.

DDoS (сокр. от Distributed denial of service — распределенный

отказ в обслуживании) — атака, вызывающая отказ в

обслуживании в системе или сервисе.

Docker — наиболее часто используемая PaaS для запуска

контейнеров.

EC2 — разработка AWS для запуска контекстуализированных

виртуальных машин (инстансов) в облаке.

ERP — интегрированный пакет для управления бизнесом.

FaaS — способ использования облачных вычислений,

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

реализации функций без учета базовой инфраструктуры.

GAE (сокр. от Google App Engine) — высокоабстрагированная

и изолированная PaaS от GCP.

GCP (сокр. от Google Cloud Platform) — платформа облачных

вычислений Google.

Git — распределенная версия системы управления, широко

используемая при разработке программного обеспечения.

GNU — операционная система, относящаяся к свободному

программному обеспечению. GNU — рекурсивная аббревиатура

от «GNU’s not UNIX»: «GNU — это не UNIX». Самые расширенные

версии операционной системы работают с ядром Linux, хотя

доступны и другие версии.

Google Cloud Functions — FaaS от GCP.

GraphQL — язык запросов и обработки данных для API с

открытым исходным кодом, разработанный Facebook.


Альтернатива REST.

Hadoop — платформа больших данных Apache, основанная на

основе модели массового распределенного программирования

MapReduce.

InfiniBand — стандарт связи, используемый в

высокопроизводительных вычислениях.

IOPS — измерение производительности, указывающее

количество операций ввода/вывода в секунду.

IRC — протокол текстового чата, созданный в конце 1980-х гг.

и ставший чрезвычайно популярным в 1990-х.

JSON (сокр. от JavaScript object notation) — формат файла

открытого стандарта, использующий читабельный для человека

текст для передачи объектов данных.

Kubernetes — cистема оркестровки свободного программного

обеспечения (контейнера), созданная Google.

LaTeX — cистема подготовки документов, обычно

используемая в научной среде.

Linux — сверхпопулярное ядро для операционных систем.

MPI — стандарт для распараллеливания задач, обычно в

средах HPC.

NAS — хранилище, подключенное и совместно используемое

по сети.

NumPy — числовая библиотека (а также расширения) для

Python.

PHP — язык программирования высокого уровня, очень

популярный при веб-разработке.

POSIX — серия стандартов, направленных на обеспечение

совместимости между различными операционными системами.

PUE (сокр. от Power usage effectiveness, эффективность

энергопотребления) — метод (или коэффициент) расчета

эффективности дата-центра с точки зрения потребления энергии.

Python — язык программирования высокого уровня, весьма

популярный во многих сферах, и особенно в науке, анализе


данных и разработке систем.

REST (сокр. от Representational state transfer) —

архитектурный стиль, используемый для разработки REST API.

S3 — облачное хранилище от AWS.

SDK — пакет связанных инструментов от разработчика

программного обеспечения.

SEO — методы, используемые для повышения рейтинга сайтов

в поисковых системах, таких как Google, Bing и Yahoo Search.

Spark — платформа кластерных вычислений, созданная после

Hadoop. Базовая архитектура Apache Spark основана на

устойчивом распределенном наборе данных (RDD) — структуре

данных, позволяющей выполнять быстрые вычисления.

SSD (сокр. от Solid state disk) — жесткий диск, как правило —

флеш-память, используемая для снижения задержки и повышения

производительности.

SSL — см. TLS.

TLS (сокр. от Transport layer security) — серия

криптографических протоколов, направленных на обеспечение

безопасной связи по сети; не поддерживает SSL.

VPC (сокр. от Virtual private cloud) — изолированная облачная

среда (ее сеть не подключена к общедоступной), доступная, как

правило, только через VPN.

VPN (сокр. от Virtual private network, виртуальная частная

сеть) — это концепция, указывающая на то, что частная сеть

распространяется на общедоступную, т.е. две или более частных

сети (к которым не подключиться через общедоступные сети)

могут видеть друг друга и использовать общедоступные сети в

качестве канала связи, как правило, зашифрованного и

безопасного.

VPS (сокр. от Virtual private server) — виртуальный частный

сервер, продаваемый провайдером. VPS находятся на более

низком уровне абстракции, нежели облачные инстансы, и


продаются как предустановленные (как есть) системы;

самообслуживание VPS не допускается провайдерами.

Бакет — наивысший уровень иерархии облачных систем

хранения, таких как S3 или GCS, своего ролда контейнер для

объектов файловой системы.

Бессерверный — см. FaaS.

Блокчейн — технологии, обеспечивающие агрегирование

(добавление) набора записей, связанных методами

криптографии. Обычно блокчейн применяется в электронных

кошельках и смарт-контрактах.

Большие данные — область компьютерной науки,

обрабатывающая и анализирующая большие наборы данных в

разных целях, например для прогнозирования или извлечения

значимой информации.

Виртуализация — в контексте данной книги этот термин

означает создание или использование инстанса или контейнера,

функционирующего как настоящая операционная система.

Виртуальная машина — см. инстанс.

Гражданская наука — деятельность, осуществляемая

обществом в сотрудничестве или под наблюдением

профессиональных ученых, обычно вносящая вклад в основы

исследовательского процесса.

Дата-майнинг — процессы и методики, направленные на

обнаружение и выявление закономерностей в данных.

Инстанс — виртуальная машина с контекстом (определение

процессора, объем памяти, образ диска и т.д.), работающая в

среде облачных вычислений. В контексте данной книги термины

«виртуальная машина» и «инстанс» взаимозаменяемы.

Контейнер — виртуальная среда, работающая поверх ядра

одной операционной системы и эмулирующая ОС, а не базовое

оборудование.

Машинное обучение — междисциплинарная область (прочно

базирующаяся в области компьютерных наук и статистики),


направленная на извлечение и вывод закономерностей в

массивах (априори) неструктурированных данных.

Микросервис — архитектура, состоящая из изолированных,

небольших и независимых сервисов.

Наблюдаемость — атрибут систем и служб, которые можно

просматривать (например, исторические данные или сводки

прогнозов) с помощью метрики и журналов.

Нулевая загрузка — сценарий, при котором данные хранятся

на внешних серверах (в облаке), где и выполняются

вычислительные задачи, в противоположность сценарию, при

котором вычисления выполняются в собственных или локальных

системах.

Облачный — ПО или система, необязательно изначально

созданная для работы в облаке, но способная работать в облачной

среде, возможно, с некоторыми изменениями. Чаще всего

облачное ПО позволяет использовать все функции, предлагаемые

облачными вычислениями.

Публичное облако — модель, при которой серверы дата-

центра могут при необходимости совместно использовать

несколько пользователей. Ресурсы являются общими и доступны

всем.

Регион — с точки зрения облачных вычислений это способ

представления географического расположения дата-центров

провайдерами. Регионы делятся на зоны.

Свободное программное обеспечение — ПО, которое

соответствует определению фонда свободного программного

обеспечения (https://www.gnu.org/philosophy/free-sw.en.html) и

подразумевает свободу использования, получения доступа к коду,

а также возможность изменять его, распространять как саму

программу, так и ее измененные версии.

Частная сеть — персональная сеть организации или

инфраструктуры, т.е. недоступная для общественности.


Частное облако — модель, при которой инфраструктурой в

зависимости от потребностей может управлять непосредственно

ИТ-отдел клиента или поставщик.

Чат-бот — ПО, выполняющее функцию разговора.

Ядра — независимые блоки обработки, которые можно

сгруппировать в несколько интегральных схем.

Ядро — компьютерная программа, основа операционной

системы компьютера.
1. Feldman M. (2018) Cloud computing in HPC surges. https://w

ww.top500.org/news/cloudcomputing-in-hpc-surges/. По

состоянию на 29 ноября 2019 г.

2. The Economist Intelligence Unit (2016) Trust in cloud

technology and business performance: reaping benefits from the

cloud, 26 pp.

3. Kaminska M., Smihily M. (2018) Cloud computing — statistics

on the use by enterprises. https://ec.europa.eu/eurostat/statistics-ex

plained/index.php?title=Cloud_computing_-_statistics_on_the_use_b

y_enterprises&oldid=416727. По состоянию на 9 апреля 2019 г.

4. Barua H.B., Mondal K.C. (2019) A comprehensive survey on

cloud data mining (CDM) frameworks and algorithms. ACM Comput

Surv 52(5): 104. https://doi.org/10.1145/3349265.

5. Перечисленные технологии — всего лишь некоторые из

существующих вариантов; расчетная стоимость указана по

состоянию на октябрь 2019 г. и может меняться в зависимости от

страны, где проживает клиент.

6. Схемы IaaS, PaaS и SaaS мы подробнее рассмотрим в разделе

3.2.3.

7. Mailchimp (2019) https://mailchimp.com/. По состоянию на

30 октября 2019 г.
8. Hayes B. (2008) Cloud computing. Commun ACM 51(7): 9-11. h

ttps://doi.org/10.1145/1364782.1364786.

9. Distefano S, Puliafito A (2012) Cloud@Home: toward a

volunteer cloud. IT Prof 14: 27-31. https://doi.org/10.1109/MITP.20

11.111.

10. Это не зависит от того, кому принадлежит дата-центр —

поставщику, частному лицу или государственному органу.

11. На момент написания этой книги AWS сообщила, что будет

оспаривать решение Министерства обороны США о

предоставлении контракта Azure.

12. Zimmermann O. (2017) Microservices tenets. Comput Sci Res

Dev 32(3): 301-310. https://doi.org/10.1007/s00450-016-0337-0.

13. Graphite (2019) Graphite. https://graphiteapp.org. По

состоянию на 6 ноября 2019 г.

14. Grafana (2019) Grafana. https://grafana.com/. По

состоянию на 6 ноября 2019 г.

15. Firesmith D. (2017) Virtualization via containers. https://insig

hts.sei.cmu.edu/sei_blog/2017/09/virtualization-via-

containers.html. По состоянию на 6 ноября 2019 г.


16. Docker (2019) Docker. https://www.docker.com/. По

состоянию на 6 ноября 2019 г.

17. Añel J.A. (2011) The importance of reviewing the code.

Commun ACM 54(5): 40-41. https://doi.org/10.1145/1941487.1941

502;

Añel J.A. (2017) Comment on “Most computational hydrology is not

reproducible, so is it really science?” by Christopher Hutton et al.

Water Resour Res 53(3): 2572-2574. https://doi.org/10.1002/2016

WR020190;

Stodden V., Seiler J., Ma Z. (2018) An empirical analysis of journal

policy effectiveness for computational reproducibility. Proc Natl Acad

Sci 115(11): 2584-2589. https://doi.org/10.1073/pnas.1708290115.

18. Boettiger C. (2015) An introduction to Docker for reproducible

research. SIGOPS Oper Syst Rev 49(1): 71-79. https://doi.org/10.114

5/2723872.2723882;

Kurtzen G.M., Sochat V., Bauer M.W. (2017) Singularity: scientific

containers for mobility of compute. PLoS One 12(5): e0177459. http

s://doi.org/10.1371/journal.pone.0177459;

Kim Y.M., Poline J.B., Dumas G. (2018) Experimenting with

reproducibility: a case study of robustness in bioinformatics.

GigaScience 7(7). https://doi.org/10.1093/gigascience/giy077.

19. Baliga J., Ayre R.W.A., Hinton K., Tucker R.S. (2011) Green

cloud computing: balancing energy in processing, storage, and

transport. Proc IEEE99(1): 149-167. https://doi.org/10.1109/JPROC.

2010.2060451.

20. Microsoft (2018) The carbon benefits of cloud computing: a

study on the Microsoft Cloud, 25 p. https://www.microsoft.com/en-u


s/download/details.aspx?id=56950.

21. Wu Y., Lin S., Peng F., Li Q. (2019) Methods and application of

archeological cloud platform for grand sites based on spatio-temporal

big data. ISPRS Int J Geo-Inf 8(9): 377. https://doi.org/10.3390/ijgi8

090377.

22. Goodess C.M., Troccoli A., Acton C., Añel J.A., Bett P.E.,

Brayshaw D.J., De Felice M., Dorling S.E., Dubus L., Penny L., Percy B.,

Ranchin T., Thomas C., Trolliet M., Wald L. (2019) Advancing climate

services for the European renewable energy sector through capacity

building and user engagement. Clim Serv 16: 100139.

23. Vance T.F., Merati N., Yang C., Yuan M. (2016) Cloud

computing in ocean and atmospheric sciences. Academic, San Diego. h

ttps://doi.org/10.1016/C2014-0-04015-4;

Zhuang J., Jacob D.J., Gaya J.F., Yantosca R.M., Lundgren E.W.,

Sulprizio M.P., Eastham S.D. (2019) Enabling immediate access to

earth science models through cloud computing: application to the

GEOS-Chem Model. Bull Am Meteorol Soc 100: 1943-1960. https://d

oi.org/10.1175/BAMSD-18-0243.1;

Añel J.A. et al (submitted) Evaluation and intercomparison of cloud

computing solutions for climate modelling.

24. Montes D., Añel J.A., Pena T.F., Uhe P., Wallom D.C.H. (2017)

Enabling BOINC in infrastructure as a service cloud systems. Geosci

Model Dev 10: 811-826. https://doi.org/10.5194/gmd-10-811-2017.

25. CoCalc (2019) CoCalc. https://cocalc.com/. По состоянию на

6 ноября 2019 г.
26. Malawski M., Gajek A., Zima A., Balis B., Figiela K. (2019)

Serverless execution of scientific workflows: experiments with

HyperFlow, AWS Lambda and Google Cloud Functions. Future Gener

Comput Syst. https://doi.org/10.1016/j.future.2017.10.029.

27. Misra S.C., Mondal A. (2011) Identification of a company’s

suitability for the adoption of cloud computing and modelling its

corresponding return on investment. Math Comput Model 53(3-4):

504-521. https://doi.org/10.1016/j.mcm.2010.03.037.

28. Bildosola I., Río-Belver R., Cilleruelo E., Garechana G. (2015)

Design and implementation of a cloud computing adoption decision

tool: generating a cloud road. PLoS ONE10(7): e0134563. https://do

i.org/10.1371/journal.pone.0134563;

Etsy (2018) Selecting a cloud provider (code as craft post). https://co

deascraft.com/2018/01/04/selecting-a-cloud-provider/. По

состоянию на 10 июня 2019 г.

29. Repschläger J., Wind S., Zarnekow R., Turowski K. (2011)

Developing a cloud provider selection model. Paper presented at the

enterprise modelling and information systems architectures:

proceedings of the 4th international workshop on enterprise

modelling and information systems, EMISA 2011, Hamburg,

September 22-23, 2011.

30. Nature (2018) Microsoft’s purchase of GitHub leaves some

scientists uneasy. Nature 558: 353 https://doi.org/10.1038/d41586-0

18-05426-0.
31. Git gittutorial — A tutorial introduction to Git. https://git-scm.

com/docs/gittutorial. По состоянию на 20 января 2019 г.

32. Lancaster University (2019) Lancaster University launch

pioneering chatbot companion for students. https://www.lancaster.a

c.uk/news/lancaster-university-launch-pioneering-chatbotcompanion

-for-students. По состоянию на 10 марта 2019 г.; AWS (2019)

Building a multi-channel Q&A chatbot at Saint Louis University using

the open source QnABot. https://aws.amazon.com/es/blogs/publicse

ctor/building-a-multi-channel-qa-chatbot-at-saint-louis-university-usi

ng-the-open-source-qnabot/. По состоянию на 17 октября 2019 г.

33. Mell P., Grance T. (2011) SP 800-145. The NIST definition of

cloud computing. National Institute of Standards & Technology,

Gaithersburg.

34. Reuther A., Byun C., Arcand W., Bestor D., Bergeron B.,

Hubbell M., Jones M., Michaleas P., Prout A., Rosa A., Kepner J.(2018)

Scalable system scheduling for HPC and big data. J Parall Distr Com

111: 76-92.

35. Wagstaff K. (2012) What, exactly, is a supercomputer? Time. ht

tp://techland.time.com/2012/06/19/what-exactly-is-a-supercomput

er/. По состоянию на 9 августа 2018 г.

36. Andrikopoulos V., Binz T., Leymann F., et al (2013) How to

adapt applications for the cloud environment. Computing 95: 493. htt

ps://doi.org/10.1007/s00607-012-0248-2.
37. Eizinger T. (2017) API design in distributed systems: a

comparison between GraphQL and REST. Master Thesis, University of

Applied Sciences Technikum Wien.

38. NASA (2019) Earthdata Developer Portal. https://earthdata.n

asa.gov/collaborate/open-dataservices-and-software/api. По

состоянию на 5 ноября 2019 г.

39. Google (2019) Google API explorer. https://developers.google.

com/apis-explorer/. По состоянию на 20 мая 2019 г.

40. Microsoft (2019) Azure REST API reference. https://docs.micr

osoft.com/en-us/rest/api/azure/. По состоянию на 22 мая 2019 г.

41. Amazon (2019) AWS documentation. https://docs.aws.amazo

n.com/#lang/en_us. По состоянию на 10 апреля 2019 г.

42. Google (2019) Google cloud APIs. https://cloud.google.com/a

pis/docs/overview. По состоянию на 20 мая 2019 г.

43. Amazon (2019) AWS SDK. https://aws.amazon.com/tools/#S

DKs. По состоянию на 10 апреля 2019 г.

44. Google (2019) Cloud SDK. https://cloud.google.com/sdk/. По

состоянию на 20 мая 2019 г.

45. Microsoft (2019) Azure tools. https://azure.microsoft.com/en-

us/tools/. По состоянию на 22 мая 2019 г.


46. Здесь следует отметить, что названия и регионы меняются,

а значит, эти обозначения могут не соответствовать регионам

Google Cloud, доступным в то время, когда вы читаете эту книгу.

47. Andrikopoulos V., Binz T., Leymann F., et al (2013) How to

adapt applications for the cloud environment. Computing 95: 493. htt

ps://doi.org/10.1007/s00607-012-0248-2.

48. Vijayasarathy L., Butler C. (2016) Choice of software

development methodologies: do organizational, project, and team

characteristics matter? IEEE Softw 33(5): 86-94. https://doi.org/10.1

109/MS.2015.26.

49. NASA (2019) Earthdata Developer Portal. https://earthdata.n

asa.gov/collaborate/open-dataservices-and-software/api. По

состоянию на 5 ноября 2019 г.

50. Amazon (2019) AWS VPC documentation. https://docs.aws.a

mazon.com/vpc/index.html. По состоянию на 10 апреля 2019 г.

51. Обратите внимание: этот код значительно упрощен в

иллюстративных целях и подлежит оптимизации, например

введению аргументов вместо констант в многопроцессные

запросы.

52. Описание этапов установки можно найти здесь: https://do

cs.aws.amazon.com/cli/latest/userguide/installing.html.
53. Обратите внимание: как упоминалось ранее, код

классификатора должен быть общедоступным по URL-адресу, в

который свертывается скрипт.

54. Baldini I. et al (2017) Serverless computing: current trends and

open problems. Research advances in cloud computing. Springer,

Singapore, pp 1-20. https://doi.org/10.1007/978-981-10-5026-8_1.

55. Hong S. (2018) Go Serverless: securing cloud via serverless

design patterns. In: 10th USENIX workshop on hot topics in cloud

computing (HotCloud 18), Boston.

56. Kleppmann M. (2017) Designing data-intensive applications,

Chapter 8. O’Reilly, Sebastopol;

Montes D. et al (2017) Views on the potential of Cloud computing and

IaaS/HPCaaS for meteorology and climatology. In: EMS Annual

Meeting Abstracts (EMS2017), Vienna, vol 14, p 639.

57. Google (2019) Google cloud functions. https://cloud.google.c

om/functions/docs/concepts/python-runtime. По состоянию на 10

мая 2019 г.

58. Google (2019) Cloud SDK. https://cloud.google.com/sdk/. По

состоянию на 10 мая 2019 г.

59. Обратите внимание: в данной разработке не

затрагиваются вопросы безопасности или аутентификации; она

служит лишь доказательством концепции: любой, у кого есть

URL-адрес, может сделать GET-запрос и внести данные в GCS-

бакет.
60. GNU (2007) GNU Affero General Public License. https://www.

gnu.org/licenses/agpl-3.0.html. По состоянию на 10 февраля 2019

г.

61. Faragardi H. (2017) Ethical considerations in cloud computing

systems. Proceedings 1: 166. https://doi.org/10.3390/IS4SI-2017-04

016.

62. EASA (2016) SafeClouds.eu Data-driven research addressing

aviation safety intelligence. https://ec.europa.eu/inea/en/horizon-2

020/projects/h2020-transport/aviation/safeclouds.eu. По

состоянию на 05 апреля 2019 г.

63. Amazon (2019) HIPAA compliance. https://aws.amazon.com/

compliance/hipaa-compliance/. По состоянию на 06 апреля 2019 г.

64. Copeland R. (2019) Google’s ‘Project Nightingale’ gathers

personal health data on millions of Americans. Wall Street J. https://

www.wsj.com/articles/google-s-secret-project-nightingalegathers-per

sonal-health-data-on-millions-of-americans-11573496790.

65. Añel J.A. (2011) The importance of reviewing the code.

Commun ACM 54(5): 40-41. https://doi.org/10.1145/1941487.1941

502.

66. Department of Justice of the United States (2019) Cloud act

resources. https://www.justice.gov/dag/cloudact. По состоянию на

15 апреля 2019 г.
67. Srinivasan S. (2014) Cloud computing basics. Springer, New

York.
Издано при содействии SberCloud

Руководитель проекта И. Позина

Научный редактор В. Яценков

Дизайнер А. Маркович

Корректор Е. Жукова

Компьютерная верстка Б. Руссо

First published in English under the title Cloud and Serverless

Computing for Scientists; A Primer by Juan A. Añel, Diego P Montes

and Javier Rodeiro Iglesias, edition: 1

Copyright © Springer Nature Switzerland AG, 2020 *

This edition has been translated and published under licence from

Springer Nature Switzerland AG.

Springer Nature Switzerland AG takes no responsibility and shall

not be made liable for the accuracy of the translation.

© Перевод. Смилевска Л., 2022

© Оформление, издание на русском языке. ООО «Альпина

ПРО», 2022

© Электронное издание. ООО «Альпина Диджитал», 2022

Аньель Х. и др.

Переход в облако: Практическое руководство по организации

облачных вычислений для ученых и IT-специалистов / Хуан

Аньель, Диего Монтес, Хавьер Родейро Иглесиа. — М.: Альпина

ПРО, 2022.

ISBN 978-5-9074-7071-2

Вам также может понравиться