Облачные сервисы (Облачные услуги)

Содержание:

Введение

21 век обозначился как век информационных технологий. Потребности бизнеса диктуют потребность во всё больших вычислениях и распределённых нагрузок. Появилось такое явление как Digital технологии: когда и входными данными и результатом деятельности бизнеса является информация. Информацию необходимо хранить, перерабатывать, обмениваться и делать легкодоступной.

До недавнего времени инфраструктурой внутри компаний занимались системные инженеры и системные администраторы, которые настраивали сети и средства обработки данных внутри компаний. С ростом потребностей бизнеса в количестве обработки данных часть вычислений перекочевала в дата-центры, - системы серверов, предоставляемые специальными организациями – провайдерами. Первоначально на этих серверах были расположены сайты компаний, затем появились порталы для внутреннего документооборота.

Сегодня дата-центры предоставляют целый спектр информационных услуг. Такие услуги называются облачными технологиями. И, если первоначально они были направлены на удовлетворение потребностей бизнеса, то сегодня облачные услуги стали доступны самым простым пользователям разного возраста. И, если вчера мы только что-то о них только слышали, то на сегодняшний момент облачные технологии вошли не только в домашние компьютеры, но и в мобильные устройства: в телефоны, планшеты, в бытовую технику, в программное обеспечение умных домов.

1. Облачные технологии с точки зрения клиента

1.1. Облачные услуги

Итак, что же такое облачные технологии и облачные вычисления?

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

Само понятие облачных технологий к нам пришло в 2006 году, и с тех пор этот принцип занимает всё более твёрдые позиции в сфере ИТ. В 2014 году затраты организаций на облачные услуги оцениваются в $175 млрд.

Концепция распределённых вычислений по принципу коммунального хозяйства появилась ещё в 60-х годах прошлого века. Она была предложена Джоном Маккарти, - автором языка Лисп а также таких понятий, как искусственный интеллект и функциональные языки программирования.

Следующим шагом в 1999 году было появление CRM-системы от salesforce.com, предоставляемой по подписке через веб-сайт. Amazon.com в 2002 году представила доступ к книжному интернет-магазину. В последствие Amazon стала технологичной компанией, которая стала развивать идею вычислительной эластичности, и в августе 2006 года представила миру проект Elastic Computing Cloud (Amazon EC2). В том же году упоминание о cloud и cloud computing прозвучали в одном из выступлений главы Google Эрика Шмидта.

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

Рисунок 1.1

В 2009 году появился сервис Google Apps, который привёл к популяризации и осмыслению облачных вычислений.

В 2009—2011 годы были сформулированы несколько важных обобщений представлений об облачных вычислениях, в частности, выдвинута модель частных облачных вычислений, актуальная для применения внутри организаций, выделены различные модели обслуживания (SaaS, PaaS, IaaS).

1.2. Обязательные признаки облачных сервисов

В 2011 году Национальный институт стандартов и технологий сформировал определение, которое структурировало и зафиксировало все возникшие к этому времени трактовки и вариации относительно облачных вычислений в едином понятии:

• Самообслуживание по требованию (англ. self service on demand) — потребитель самостоятельно определяет и изменяет вычислительные потребности, такие как серверное время, скорости доступа и обработки данных, объём хранимых данных без взаимодействия с представителем поставщика услуг;
• Универсальный доступ по сети — услуги доступны потребителям по сети передачи данных вне зависимости от используемого терминального устройства;
• Объединение ресурсов (англ. resource pooling) — поставщик услуг объединяет ресурсы для обслуживания большого числа потребителей в единый пул для динамического перераспределения мощностей между потребителями в условиях постоянного изменения спроса на мощности; при этом потребители контролируют только основные параметры услуги (например, объём данных, скорость доступа), но фактическое распределение ресурсов, предоставляемых потребителю, осуществляет поставщик (в некоторых случаях потребители всё-таки могут управлять некоторыми физическими параметрами перераспределения, например, указывать желаемый центр обработки данных из соображений географической близости);
• Эластичность — услуги могут быть предоставлены, расширены, сужены в любой момент времени, без дополнительных издержек на взаимодействие с поставщиком, как правило, в автоматическом режиме;
• Учёт потребления — поставщик услуг автоматически исчисляет потреблённые ресурсы на определённом уровне абстракции (например, объём хранимых данных, пропускная способность, количество пользователей, количество транзакций), и на основе этих данных оценивает объём предоставленных потребителям услуг.

1.3. Модели услуг

Давайте рассмотрим три основные модели обслуживания облачных сервисов:

Программное обеспечение как услуга (SaaS, англ. Software-as-a-Service) — модель, в которой потребитель использует прикладное программное обеспечение провайдера, работающего в облачной инфраструктуре и доступного с разных устройств посредством тонкого клиента, - например, из браузера (как то, веб-почта), - или через интерфейс программы. Основная физическая и виртуальная инфраструктура облака находится под управлением и влиянием облачного провайдера, - в том числе сети, серверы, операционные системы, хранение, или даже индивидуальные возможности приложения (за исключением ограниченного набора пользовательских настроек конфигурации приложения).

Платформа как услуга (PaaS, англ. Platform-as-a-Service) — модель, когда потребитель может использовать облачную инфраструктуру для размещения базового программного обеспечения с последующим размещением на нём новых или существующих приложений (собственных, разработанных на заказ или приобретённых тиражируемых приложений). В состав таких платформ входят инструментальные средства создания, тестирования и выполнения прикладного программного обеспечения — системы управления базами данных, связующее программное обеспечение, среды исполнения языков программирования — предоставляемые облачным провайдером.

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

Инфраструктура как услуга (IaaS, англ. Infrastructure-as-a-Service) предоставляется как возможность использования облачной инфраструктуры для самостоятельного управления ресурсами обработки, хранения, сетями и другими фундаментальными вычислительными ресурсами, например, потребитель может устанавливать и запускать произвольное программное обеспечение, которое может включать в себя операционные системы, платформенное и прикладное программное обеспечение. Потребитель может контролировать операционные системы, виртуальные системы хранения данных и установленные приложения, а также обладать ограниченным контролем за набором доступных сетевых сервисов (например, межсетевым экраном, DNS). Контроль и управление основной физической и виртуальной инфраструктурой облака, в том числе сети, серверов, типов используемых операционных систем, систем хранения осуществляется облачным провайдером.

Эти три термина дают понимание принципов работы облаков. Они замещают для пользователей и организаций собственную инфраструктуру, позволяя пользоваться ими без дополнительных издержек на собственное оборудование и сократить штат ИТ-отдела.

1.4 Крупнейшие поставщики облачной инфраструктуры

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

Самыми большими поставщиками облачной инфраструктуры IaaS на сегодня являются Microsoft Azure, Google Cloud Platform и Amazon Web Services.

1.5. Облако от Microsoft

Microsoft Azure (Windows Azure) — название облачной платформы Microsoft. Предоставляет возможность разработки и выполнения приложений и хранения данных на серверах, расположенных в распределённых дата-центрах. Первоначально называлась Windows Azure. В 2014 году платформа была переименована в Microsoft Azure.

Microsoft Azure реализует две облачные модели — платформы как сервиса (PaaS) и инфраструктуры как сервиса (IaaS). Работоспособность платформы Microsoft Azure обеспечивает сеть глобальных дата-центров Microsoft.

Основные особенности данной модели:

• оплата только потреблённых ресурсов;
• общая, многопоточная структура вычислений;
• абстракция от инфраструктуры.

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

Microsoft Azure как PaaS обеспечит не только все базовые функции операционной системы, но и дополнительные: выделение ресурсов по требованию для неограниченного масштабирования, автоматическую синхронную репликацию данных для повышения отказоустойчивости, обработку отказов инфраструктуры для обеспечения постоянной доступности и многое другое.

Microsoft Azure также реализует другой тип сервиса — инфраструктуру как сервис. Модель предоставления инфраструктуры (аппаратных ресурсов) реализует возможность аренды таких ресурсов, как серверы, устройства хранения данных и сетевое оборудование. Управление всей инфраструктурой осуществляется поставщиком, потребитель управляет только операционной системой и установленными приложениями.

В галерее образов доступны образы следующих операционных систем: Windows Server (2008, 2012, Technical Preview), CoreOS, Ubuntu Server, CentOS, openSUSE, SUSE Linux Enterprise Server, Oracle Linux.

В 2013 году было представлено новое хранилище образцов виртуальных машин — VM Depot — это проект для сообщества Windows Azure, запущенный командой Microsoft Open Technologies. Содержимое портала, а также настроенные для разных задач виртуальные машины, будут создаваться и публиковаться силами сообщества.

Microsoft Azure состоит из:

Compute — компонент, реализующий вычисления на платформе Windows Azure.

Storage — компонент хранилища предоставляет масштабируемое хранилище. Хранилище не имеет возможности использовать реляционную модель и является альтернативной, «облачной» версией SQL Server.

Fabric — Windows Azure Fabric по своему назначению является «контролёром» и ядром платформы, выполняя функции мониторинга в реальном времени, обеспечения отказоустойчивости, выделении мощностей, развертывания серверов, виртуальных машин и приложений, балансировки нагрузки и управления оборудованием.

Практически все сервисы Microsoft Azure имеют интерфейс взаимодействия API, построенный на основе ограничений для распределённых гипер-систем REST, что позволяет разработчикам использовать «облачные» сервисы с любой операционной системы, устройства и платформы.

Microsoft Azure предоставляет набор сервисов, покрывающих широкий спектр сценариев:

Cloud Services:

Web-роль — веб-роли в Microsoft Azure имеют особое назначение: предоставление выделенного веб-сервера служб IIS для размещения интерфейсных веб-приложений. Веб-роли позволяют развертывать веб-приложения с последующим масштабированием вычислительных ресурсов.

Worker-роль — приложения, размещенные в рабочих ролях, могут выполнять асинхронные, продолжительные или непрерывные задачи независимо от действий пользователей. Изоляция фоновых процессов приложения в рабочей роли и размещение интерфейсной части в веб-роли позволяет распределить логику приложения и управлять масштабированием приложения.

Web Sites — веб-сайты поддерживают ASP.NET, Java, Node.js или PHP (либо CMS — WebMatrix, Joomla, Drupal, WordPress, DotNetNuke, Umbraco и др.) и разворачивать за секунды с использованием FTP, Git, TFS, Mercurial и Dropbox. Использование в режиме Free бесплатно (однако накладываются серьёзные ограничения). По умолчанию веб-сайты находятся в состоянии Free, то есть мощности делятся между веб-сайтами, но при необходимости можно увеличить количество экземпляров и перевести веб-сайт в режим резервирования ресурсов. С июня 2013 года сервис Web Sites официально поддерживает пользовательские сертификаты SSL (ранее поддерживались только сертификаты, предлагаемые Microsoft) как по IP-адресу, так и на базе SNI.

Data Management — нереляционные хранилища данных: таблицы, диски, очереди, хранение двоичных объектов + реляционное хранилище данных в виде SQL Database.

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

Очереди — очереди обеспечивают надежный и непрерывный обмен сообщениями между приложениями.

Блобы — хранилище BLOB-объектов — это простейший способ хранения больших объёмов неструктурированных текстовых или двоичных данных, таких как видео, музыкальные файлы и изображения.

SQL Database — реляционная база данных — это высокодоступная масштабируемая облачная служба базы данных, построенная на основе технологий SQL Server.

SQL DataSync — облачная служба синхронизации данных, обеспечивающая как однонаправленную, так и двунаправленную синхронизацию. Служба Data Sync позволяет легко обмениваться данными между SQL в Azure и локальными базами данных SQL Server, а также между несколькими базами данных SQL Databases (SQL Azure);

SQL Reporting — служба Microsoft SQL Reporting позволяет легко встроить в приложение Windows Azure возможности работы с отчётами. Данная служба более не поддерживается и не разрабатывается.

SQL Federations — федерация SQL в Azure значительно упрощает масштабирование множества баз данных, размещенных на сотнях узлов, что позволяет клиентам платить только за реально используемые ресурсы. Данная служба более не поддерживается и не разрабатывается.

Backup — этот сервис предлагает возможность организации защищённой инфраструктуры сохранения бэкапов Windows Server в облаке. Windows Azure Backup осуществляет поддержку бэкапов информации из систем на базе Windows Server 2008 R2 SP1 и Windows Server 2012, Windows Server 2012 Essentials и System Center Data Protection Manager 2012 SP1 в Windows Azure. Поддерживаются инкрементальные бэкапы. Поддерживаются политики и все стандартные средства бэкапов Windows Server для организации сжатия данных и шифрования.

Azure Files - этот сервис дает возможность обращаться к данным хранилища Azure Storage как к сетевому ресурсу по протоколу SMB, что позволяет осуществлять привычный доступ к данным из виртуальных машин через сетевое взаимодействие.

Performance and mobile:

Content Delivery Network — сеть кэширующих серверов (сеть CDN) повышает производительность приложений путём кэширования контента ближе к клиентам и пользователям, например, сеть CDN позволяет доставлять фрагменты мультимедийных файлов для динамического адаптивного воспроизведения мультимедиа поверх HTTP-контента.

Caching — распределённый кэш — распределённый кэш в памяти, с помощью которого вместо медленного дискового хранилища приложения получают высокоскоростной доступ к данным, хранящимся в оперативной памяти, с возможностью масштабирования;

Кэш на базе Redis — сервис Azure Redis Cache представляет собой готовое redis-хранилище с требуемым размером для задач кеширования данных

Media Services — службы мультимедиа включают в себя облачные версии многих существующих технологий платформы мультимедиа Microsoft и многих партнёров, в том числе для просмотра, кодирования, преобразования формата и защиты контента, а также потоковой передачи по запросу и в реальном времени.

Mobile Services — предлагает облачную инфраструктуру для всех популярных мобильных платформ: Windows 8, Windows Phone, iOS и Android. На основе сервиса можно построить облачный бэкенд, на который перенести задачи по хранению данных, аутентификации и Push-уведомлений. Поддерживается Xamarin.

Identity — служба идентификации обеспечивает управление удостоверениями и доступом к приложениям, с помощью службы Microsoft Azure Active Directory (бывший Access Control Service) можно обеспечить единый вход, повышенную безопасность и простое взаимодействие с уже развернутыми в Active Directory приложениями, а также выполнить интеграцию с другими провайдерами аутентификации (Live ID, Google, Facebook и т. п.). Windows Azure Active Directory позволяет решать задачи единой авторизации пользователей для множества сервисов (Single Sign On), вести единый каталог пользователей, синхронизировать данные каталога с Active Directory на предприятии и т. д. Microsoft Azure Active Directory — это полноценная реализация каталога в облаке. Сервис поддерживает популярные открытые стандарты обеспечения федераций: SAML 2.0, OData, WS-FED, OAuth 2.0/OpenID.

Connectivity:

Messaging:

Service Bus — интеграционная шина предоставляет возможности ретрансляции и безопасного обмена сообщениями и позволяет создавать распределённые и слабосвязанные приложения в облаке, а также гибридные приложения, размещенные одновременно в частных и общедоступных облачных службах. Оперирует терминами Relay, Topics, Queues, Notification Hubs. С июня 2013 года в Service Bus была внедрена глобальная доступность поддержки открытого стандарта AMQP.

BizTalk Services — сервис, который предназначен для решения задач интеграции разнородных окружений на уровне предприятия и облака, предлагая возможности Business-to-Business (B2B) и Enterprise Application Integration (EAI) взаимодействий.

Networking:

Virtual Network — сервис для соединения облачных инфраструктур с локальными методом Site-To-Site VPN и Point-To-Site VPN.

Connect — сервис более не поддерживается (заменен Virtual Network).

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

RemoteApp - Azure RemoteApp, который позволяет размещать в облаке Azure существующие клиентские Windows-приложения и получать к ним доступ с любых компьютеров, планшетов, ноутбуков или телефонов через RDP-клиент (Windows, Mac OS X, iOS и Android).

ExpressRoute — сервис Azure ExpressRoute предлагает пользователям возможность подключить собственную инфраструктуру напрямую к датацентрам Microsoft Azure минуя сеть интернет как промежуточное звено.

Store — Windows Azure Store предлагает унифицированный доступ к сервисам (не Microsoft) для проектов Microsoft Azure с единым биллингом и панелью управления.

Marketplace — это магазин облачных сервисов и данных для организаций. В настоящий момент в Marketplace доступно более 600 облачных решений и 170 источников данных.

HPC и Big Data — параллельные вычисления или планировщик HPC позволяет разрабатывать на платформе Microsoft Azure параллельные приложения, требующие больших вычислительных мощностей, кроме того, это средство позволяет по требованию запускать в облаке виртуальные узлы, предоставляя таким образом доступ к вычислительным ресурсам, необходимым для обработки пиковых или непредсказуемых нагрузок. Это позволяет использовать малые локальные кластеры и подключаться к Microsoft Azure, когда требуются дополнительные ресурсы. Кроме этого, в Microsoft Azure доступен сервис Microsoft Azure HDInsight (Hadoop). HDInsight — это облачный сервис, предлагающий экосистему и кластеры Hadoop по запросу. С помощью портала Microsoft Azure можно создавать кластеры Hadoop с размером до 32 узлов. Кроме создания задач MapReduce, можно получить доступ к интерактивной консоли, которая позволяет писать запросы к данным на JavaScript и Hive.

API Management - этот сервис предлагает разработчикам собственных API возможность получить окружение по управлению, мониторингу и администрированию своего API, размещенного в любом месте, как в облаке, так и на любом хостинге, включая собственную инфраструктуру. [1]

Для удобства приведём таблицу соответствий сервисов трёх гигантов:

Google Cloud Platform	Amazon Web Services	Microsoft Azure
Google Compute Engine	Amazon EC2	Azure Virtual Machines
Google App Engine	AWS Elastic Beanstalk	Azure Cloud Services
Google Container Engine	Amazon EC2 Container Service	Azure Container Service
Google Cloud Bigtable	Amazon DynamoDB	Azure Cosmos DB
Google BigQuery	Amazon Redshift	Microsoft Azure SQL Database
Google Cloud Functions	Amazon Lambda	Azure Functions
Google Cloud Datastore	Amazon DynamoDB	Cosmos DB
Google Storage	Amazon S3	Azure Blob Storage

2. Принципы обслуживания облачных ресурсов с точки зрения поставщика

2.1. DevOps

DevOps (акроним от англ. development и operations) — набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга. (Википедия)

Термин "DevOps" был популяризирован на конференции «Дни DevOps» ("DevOps Days") в 2009 году в Бельгии. После этого «Дни DevOps» проводились в Индии, США, Бразилии, Австралии, Германии, Швеции и даже в Росси, - где сумел побывать в 2017 году и я.

В производственной системе Toyota, например, роль профессионала DevOps схожа с должностью главного инженера. Этот сотрудник отвечает за успех проекта, но формально не руководит различным командами, задействованными на данном проекте. Деятельность специалиста DevOps требует знания используемых технологий и управленческой модели, чтобы убеждать менеджеров проектов принимать эффективные решения. Этому способствует авторитет «главного инженера», признанный руководством предприятия.

Большинство идей для DevOps взяты из методологии управления системами предприятия и движения Agile (операции и инфраструктура). [2]

2.2 Agile

Agile - Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративно-инкрементной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. На каждой итерации Agile-евангелист решает, кто из разработчиков при разработке в данный момент является самым компетентным. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum, FDD.

Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с управлением ими комбинированным (либеральным и демократическим) методом.

Большинство гибких методологий нацелены на минимизацию рисков разрастания проектов в невыгодные затянувшиеся проекты путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.

Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом англ. bullpen. Как минимум, она включает и «заказчиков» (англ. product owner — заказчик или его полномочный представитель, - бизнес-аналитик, системный аналитик или сам клиент, определяющий требования к продукту). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.

Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами. Это привело к критике этих методов как недисциплинированных. [3]

2.3 Ценности Agile

Манифест практики agile был придуман и объявлен 11-13 февраля 2001 года на съезде величайших системных аналитиков, архитекторов и разработчиков:

1. Люди и взаимодействие важнее процессов и инструментов
2. Работающий продукт важнее исчерпывающей документации
3. Сотрудничество с заказчиком важнее согласования условий контракта
4. Готовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

2.4 Основные принципы Agile

1. Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения;
2. Изменение требований приветствуется, даже на поздних стадиях разработки;
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев;
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе;
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им;
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды;
7. Работающий продукт — основной показатель прогресса;
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно;
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта;
10. Простота — искусство минимизации лишней работы — крайне необходима;
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд;
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

2.5 NoOps

NoOps (акроним от англ. no и operations) – набор практик, призванный к тому, чтобы в компании совсем избавиться от специалистов сопровождения за счёт использования PaaS или полной автоматизации внутренних процессов в инфраструктуре организации. Платформа как сервис подразумевает скрытие внутренних процессов в инфраструктуре от глаз разработчиков и бизнеса.

2.6 BizOps

BizOps (акроним от англ. buziness и operations) – набор практик, которые позволяют представителям бизнеса напрямую обращаться с облачными технологиями и прибегать к их услугам. В большинстве случаев под этим понимается программное обеспечение как услуга. Бизнесу необходимы CRM системы, системы документооборота, различные коммерческие порталы и взаимодействие различных структур облачных технологий.

2.7. LXC

Начиная с версии ядра 2.6.29, Linux стал поддерживать систему виртуализации на уровне операционной системы для запуска нескольких изолированных экземпляров операционной системы Linux на одном узле. Эта технология получила название LXC (англ. Linux Containers) . Она не использует виртуальные машины, создавая виртуальное окружение с собственным пространством процессов и сетевым стеком. Все экземпляры LXC используют один экземпляр ядра операционной системы.

2.8. Docker

На смену LXC пришёл Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы. Изначально использовал возможности LXC, но с 2015 года разработал собственную библиотеку, абстрагирующую виртуализационные возможности ядра Linux — libcontainer. С появлением ​Open Container Initiative начался переход от монолитной к модульной архитектуре, - это открыло новую облачную эру микросервисов. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет среду по управлению контейнерами..

Разрабатывается и поддерживается одноимённой компанией-стартапом, распространяется в двух редакциях — общественной (Community Edition) по лицензии Apache 2.0 и для организаций (Enterprise Edition по проприетарной лицензии. Написан на языке Go. [4]

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

Сервис-ориентированная архитектура (SOA, англ. service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.

Программные комплексы, разработанные в соответствии с сервис-ориентированной архитектурой, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например, на базе jini, CORBA, на основе REST).

Интерфейсы компонентов в сервис-ориентированной архитектуре инкапсулируют детали реализации (операционную систему, платформу, язык программирования) от остальных компонентов, таким образом обеспечивая комбинирование и многократное использование компонентов для построения сложных распределённых программных комплексов, обеспечивая независимость от используемых платформ и инструментов разработки, способствуя масштабируемости и управляемости создаваемых систем.

Такая архитектура позволяет поддерживать DevOps, BizOps и NoOps подходы.

Главное, что отличает SOA — это использование независимых сервисов с чётко определёнными интерфейсами, которые для выполнения своих задач могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу.

SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путём комбинации слабосвязанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определённого платформенно-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса.

Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах .Net и сервисы на Java, работающие на платформах Java EE, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.

SOA может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако SOA не определяет и не предоставляет методологий или фреймворков для документирования сервисов.

Микросервисы — современное представление сервис-ориентированной архитектуры (SOA), используемое для создания распределенных программных систем. Как и в SOA, модули в архитектуре микросервисов взаимодействуют по сети друг с другом для выполнения цели. Ещё одно сходство в том, что микросервисы используют протоколо-независимую технологию. Данная архитектура является первой реализацией SOA, появившейся после внедрения DevOps, и она постепенно становится стандартом для непрерывно развивающихся систем.

Микросервисная архитектура — это подход к созданию приложения, подразумевающий отказ от единой, монолитной структуры. То есть вместо того чтобы исполнять все ограниченные контексты приложения на сервере с помощью внутрипроцессных взаимодействий, мы используем несколько небольших приложений, каждое из которых соответствует какому-то ограниченному контексту. Причём эти приложения работают на разных серверах и взаимодействуют друг с другом по сети, например, посредством HTTP.

Иными словами, инкапсулируются определённые контексты приложения в микросервисы, по одному на каждый, а сами микросервисы располагаются на разных серверах, - по большей части под управлением Docker.

Свойства, характерные для архитектуры микросервисов:

• Модули можно легко заменить в любое время.
• Модули организованы вокруг функций, например, пользовательский интерфейс, логистика, выставление счета и т. д.
• Модули могут быть реализованы с использованием различных языков программирования, баз данных, аппаратных средств и программного обеспечения, в зависимости от того, что подходит лучше всего.
• Архитектура симметричная, а не иерархическая (производитель — потребитель). [5]

2.10. Системы управления конфигурациями

Chef — система управления конфигурациями, написанная на Ruby (клиентская часть) и Erlang (серверная часть), с использованием предметно-ориентированного языка для описания конфигураций. Используется для упрощения задач настройки и поддержки множества серверов и может интегрироваться в облачные платформы, такие как Rackspace и Amazon EC2, для автоматизации управления текущими и автоматизации процесса настройки новых серверов.

Пользователь Chef создаёт определенные «рецепты» с описанием того, как управлять серверными приложениями (например, Apache, MySQL или Hadoop) и их настроек.

«Рецепт» — это описание состояния ресурсов системы, в котором она должна находиться в конкретный момент времени, включая установленные пакеты, запущенные службы, созданные файлы. Chef проверяет, что каждый из ресурсов системы настроен правильно и пытается исправить состояние ресурса, если оно не соответствует ожидаемому.

Chef может работать как в режиме клиент-сервер, так и в режиме автономной конфигурации, называемом «chef-solo». В режиме клиент-сервер клиент посылает на сервер различные свойства хоста, на котором он расположен. На стороне сервера используется Solr для индексирования свойств и предоставления API для запроса информации клиентом. «Рецепты» могут запрашивать эти свойства и использовать полученные данные для настройки хоста.

Обычно используется для управления Linux-узлами, но последние версии поддерживают Windows. [6]

Ansible - это очень гибкий и легкий инструмент для написания сценариев автоматизации любой сложности. Можно описать в нем как простое окружение разработчика так сложную структуру крупного проекта с несколькими окружениями. Он работает со встроенными в bash командами. Позволяет решать следующие задачи:

• Установка/удаление ПО;
• Конфигурирование ПО;
• Создание/удаление пользователей;
• Контроль пользовательских паролей/ключей;
• Создание/удаление контейнеров/виртуальных машин;
• Деплой кода вашего ПО;
• Запуск различных скриптов/тестов. [7]

Puppet — кроссплатформенное клиент-серверное приложение, которое позволяет централизованно управлять конфигурацией операционных систем и программ, установленных на нескольких компьютерах. Написано на языке программирования Ruby. Наряду с Chef отмечается как одно из самых актуальных средств конфигурационного управления по состоянию на 2013 год.

Puppet позволяет просто настроить и впоследствии быстро управлять практически любой сетью на базе любой операционной системы Red Hat Enterprise Linux, CentOS, Fedora, Debian, Ubuntu, OpenSUSE, Solaris, BSD, Mac OS X и Microsoft Windows (через cygwin).

Система Puppet достаточно популярна в среде IT-компаний, в частности, её используют Google, Яндекс, Fedora Project, Стэнфордский университет, Red Hat, Siemens IT Solution, SugarCRM, Mail.Ru.

Узлы сети, управляемые с помощью Puppet, периодически опрашивают сервер, получают и применяют внесённые администратором изменения в конфигурацию. Конфигурация описывается на специальном декларативном предметно-ориентированном языке.

2.11. Управление контейнерами

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

Оркестровка описывает то, как сервисы должны взаимодействовать между собой, используя для этого обмен сообщениями, включая бизнес-логику и последовательность действий. Оркестровка подчинена какому-то одному из участников бизнес-процесса. В сервис-ориентированной архитектуре оркестровка сервисов реализуется согласно стандарту Business Process Execution Language. Познакомимся с основными инструментами для инженеров DevOps – оркестраторами, которые позволяют автоматизировать процесс деплоя на распределённые системы.

К примеру оркестраторов относятся такие программы, как Docker Swarm, Apache Mesos, Nomad, Kubrenetes. Рассмотрим функционал оркестратора на примере последнего.

Kubernetes предназначен для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а также обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат Google и теперь поддерживается многими компаниями, среди которых Microsoft, RedHat, IBM и Docker.

Компания Google пользуется контейнерной технологией уже более десяти лет. Она начинала с запуска более 2 млрд контейнеров в течение одной недели. С помощью проекта Kubernetes компания делится своим опытом создания открытой платформы, предназначенной для масштабируемого запуска контейнеров.

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

Работающий кластер Kubernetes включает в себя агента, запущенного на нодах (kubelet) и компоненты мастера (APIs, scheduler, etc), поверх решения с распределённым хранилищем. Приведённая схема показывает желаемое, в конечном итоге, состояние, хотя все ещё ведётся работа над некоторыми вещами, например: как сделать так, чтобы kubelet (все компоненты, на самом деле) самостоятельно запускался в контейнере, что сделает планировщик на 100% подключаемым.

Нода Kubernetes

При взгляде на архитектуру системы мы можем разбить его на сервисы, которые работают на каждой ноде и сервисы уровня управления кластера. На каждой ноде Kubernetes запускаются сервисы, необходимые для управления нодой со стороны мастера и для запуска приложений. Конечно, на каждой ноде запускается Docker. Docker обеспечивает загрузку образов и запуск контейнеров.

Kubelet - управляет pod'ами их контейнерами, образами, разделами, etc.

Kube-Proxy Также на каждой ноде запускается простой proxy-балансировщик. Этот сервис запускается на каждой ноде и настраивается в Kubernetes API. Kube-Proxy может выполнять простейшее перенаправление потоков TCP и UDP (round robin) между набором бэкендов.

Система управления Kubernetes разделена на несколько компонентов. В данный момент все они запускаются на мастер-ноде, но в скором времени это будет изменено для возможности создания отказоустойчивого кластера. Эти компоненты работают вместе, чтобы обеспечить единое представление кластера.

Состояние мастера хранится в экземпляре etcd. Это обеспечивает надёжное хранение конфигурационных данных и своевременное оповещение прочих компонентов об изменении состояния.

Kubernetes API обеспечивает работу api-сервера. Он предназначен для того, чтобы быть CRUD сервером со встроенной бизнес-логикой, реализованной в отдельных компонентах или в плагинах. Он, в основном, обрабатывает REST операции, проверяя их и обновляя соответствующие объекты в etcd (и событийно в других хранилищах).

Scheduler привязывает незапущенные pod'ы к нодам через вызов /binding API. Scheduler подключаем; планируется поддержка множественных scheduler'ов и пользовательских scheduler'ов.

Все остальные функции уровня кластера представлены в Kubernetes Controller Manager Server. Например, ноды обнаруживаются, управляются и контролируются средствами node controller. Эта сущность в итоге может быть разделена на отдельные компоненты, чтобы сделать их независимо подключаемыми.

ReplicationController — это механизм, основывающийся на pod API. В конечном счете планируется перевести её на общий механизм plug-in, когда он будет реализован. [9]

Заключение

При современных потребностях бизнеса и клиентов необходимы огромные вычислительные мощности при распределённых серверных системах, где необходимо, чтобы системы были по всей территории масштабирования совершенно идентичны. Такие структуры называются immutable. Необходимо совершать частый деплой и частые релизы ПО при том, чтобы клиент не заметил технологических работ. Деплой и откат должны происходить бесшовно для клиента. Серверы обмениваются информаций одновременно с миллионами клиентов, поэтому облачные услуги и способы обеспечения работоспособности высоконагруженных приложений вышли на передний уровень и прочно вошли в инфраструктуры организаций и DevOps-практики.

Оценка показала, что уже в 2006 году облачные службы занимали 5% ИТ-рынка, и на сегодня их доля вырвалась вперёд под влиянием облачных гигантов, таких как Google, Yandex или Microsoft.

В курсовой работе рассмотрены методологии разработки программного обеспечения и способы автоматизации выгрузки приложений в продакшен для обеспечения потребностей бизнеса. Были даны инструменты для изоляции приложений в контейнерах Docker, способы настройки ПО внутри них с помощью Ansible, Puppett или Cheff, управления сетями и взаимодействия между ними в больших распределённых сетях и кластерах с помощью оркестратора Kubernetes.

Даны определения микросервисов и методики их использования в рамках современного представления сервис-ориентированной архитектуры (SOA).

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

1. Марк Аггар. Создание эластичных и устойчивых облачных приложений: руководство разработчика по пакету интеграции Enterprise Library для Microsoft Azure, 2015. – 33 – 73 с.
2. Джес Хамбл; Дэвид Фарли (2011). Непрерывная доставка: надёжные версии программного обеспечения через автоматизацию сборки, тестирования и развертывания. Pearson Education Inc. 
3. Роберт С. Мартин, Джеймс В. Ньюкирк, Роберт С. Косс. Быстрая разработка программ. Принципы, примеры, практика. = Agile software development. Principles, Patterns, and Practices. — Вильямс, 2004. — 752 с.
4. Эдриен Моуэн. Использование Docker, 2016. – 56--73с.
5. А. Балабайе (2016-05-01). Микросервисные архитектуры применяемые в ДевОпс: миграция в облака – нативная архитектура. = Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture. IEEE Software 33 (3): 42–52 с. 
6. Маттиас Маршалл, Книга приготовлений автоматизации инфраструктуры с помощью Chef. = Chef Infrastructure Automation Cookbook, 2016. – 25-37с.
7. Джесс Китинг. Полное руководство Ansible = Ansible Cookbook. 05.2017. = 19c.
8. Джон Орундел. Puppett 3.0 для начинающих = Puppet 3.0 Beginner's Guide, 2015. 67с.
9. Сайто Хайдето. Книга приготовлений Kubernetes = Kubernetes Cookbook, 2017. – 12, 17, 25, 45-47с.