Жизнь в облаках: краткое введение в Amazon Web Services

Историю Amazon Web Services (AWS) принято отсчитывать от 2002 года. Именно тогда гигант розничной интернет-торговли Amazon.com начал прорабатывать возможность предоставлять заказчикам доступ к своей вычислительной инфраструктуре и некоторым программным продуктам, разработанным для внутреннего использования.

Первой из служб, которые впоследствии составили основу AWS, стал сервис управления очередями сообщений Amazon SQS (Simple Queue Service). Его тестовый запуск состоялся в 2004 году. Двумя годами позже миру уже были официально представлены Amazon Web Services, в которые на тот момент вошли три продукта: Amazon SQS, облачное объектное хранилище Amazon S3 (Simple Storage Service) и виртуальный хостинг Amazon EC2 (Elastic Compute Cloud).

Последующие годы в состав AWS входили все новые и новые продукты, включая несколько СУБД (SimpleDB, Amazon RDS, RedShift, Aurora и пр.). К 2009 году появилась возможность аренды Hadoop-кластеров, а позднее и платформы оркестрации микросервисов Kubernetes.

К настоящему времени в состав услуг AWS входят почти две сотни сервисов, позволяющих развернуть облачные инфраструктуры любых масштабов и функциональности, обеспечить их доступность и отказоустойчивость, географическую распределенность и почти безграничную масштабируемость. Услуги предоставляются по моделям IaaS, PaaS и SaaS.

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

Не менее полезным может оказаться и сервис электронной почты и календарей Amazon WorkMail, поддерживающий множество почтовых клиентов, включая мобильные. WorkMail может быть интегрирован с существующим корпоративным каталогом, шифровать данные, управлять ключами и многое другое.

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

От 1С к платформам DevOps

Довольно легко объяснить оглушительный успех AWS, которые даже сейчас, на фоне появления многочисленных мощных конкурентов, продолжают быстро набирать популярность.

Главной причиной можно считать то, что сама ИТ-индустрия к моменту появления публичных облаков оказалась крайне заинтересована в том, чтобы быстро получать новые возможности, не делая капитальных вложений в строительство собственных дата-центров.

Основными преимуществами облака перед решениями on-premise можно считать:

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

·       Быстрота запуска сервисов, по сравнению с локальной инфраструктурой

·       Модель оплаты только за реально использованные ресурсы

·       Возможность динамического масштабирования ресурсов по мере необходимости

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

Если говорить конкретно об AWS, то основными сценариями использования этих сервисов в России еще в 2016 году были внешнее хранилище (файловые папки, бэкапы, архивные данные) и виртуальные машины с базовыми инфраструктурными сервисами (Active Directory, СУБД и пр.). Понятные и простые базовые нужды бизнеса. Начиная с 2018 года и далее все большую популярность AWS в России обеспечивала возможность развертывания в облаке полноценной среды разработки.

Сейчас AWS предлагают как гибко конфигурируемые наборы инструментов разработчика, так и возможность полного переноса платформы DevOps в облако. Это позволяет создавать и тестировать ПО в полностью настраиваемой среде, не зависящей от локальной инфраструктуры.

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

Деньги за ресурсы

Итак, строить с нуля или капитально модернизировать собственную локальную ИТ-инфраструктуру в современных условиях почти наверняка нерентабельно. Но и AWS не являются бесплатными. За что же приходится платить? Схем несколько, но основных среди них четыре:

• Повременная оплата за использование сервисов;

• За количество пользователей;

• За объем загружаемых, скачиваемых, хранящихся и обрабатываемых данных;

• За объем вычислительных ресурсов (виртуальных ядер, ОЗУ).

Оплата услуг напрямую AWS осуществляется обычной банковской картой по итогам месяца и напрямую зависит от объема потребленных услуг. Впрочем, компаниям зачастую нужен набор документов о расходах, который удовлетворил бы бухгалтерию и налоговую службу. В этом случае можно обратиться к партнеру AWS, каковым является и компания «Системный софт». Тогда оплата сервисов будет происходить на основе договора, в рублях, методом ежемесячной постоплаты.

Три правила использования AWS

Для перевода или создания инфраструктуры в облаке важно отдавать себе отчет в том, кто и за что несет ответственность. Вне зависимости от того, использует ли клиент сервисы AWS в формате IaaS, PaaS или SaaS, ответственность за свои данные несет сама компания. Будь то содержимое БД, рабочие файлы или история сообщений в мессенджерах. 

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

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

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