AWS может сбить с толку: Где я должен запускать свою фигню?

AWS имеет более 180 различных сервисов с огромным количеством различных названий, и разобраться в том, где следует запускать свои приложения, может быть невероятно сложно. В этой статье я хочу немного облегчить вам работу с AWS и рассказать о том, какие сервисы вам следует изучить.

Основные сервисы

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

• Amazon EC2 — основа и, пожалуй, один из самых известных сервисов AWS. EC2 — это виртуальные машины AWS. Вы выбираете, сколько процессора, оперативной памяти и дискового пространства вам нужно, а затем какую операционную систему запустить. Вы можете выбрать из огромного количества дистрибутивов Linux, Windows Server и Desktop и даже macOS (действуют специальные тарифы и ограничения). Счет выставляется за секунду работы виртуальной машины.
• Simple Storage Service (S3) — неограниченное объектное хранилище Amazons, позволяющее легко хранить файлы для доступа к ним других служб AWS или для передачи их в Интернет (хотя при выборе последней службы вам, возможно, потребуется установить кэш, например, Amazon CloudFront).
• Amazon Elastic Cloud Service (ECS) — Вы контейнеризировали свои приложения и нуждаетесь в месте для их запуска, но не хотите разбираться со сложностью Kubernetes? ECS — это то, что вам нужно. Служба Amazon ECS — это полностью управляемая служба оркестровки контейнеров, которая упрощает вашу задачу, абстрагируясь от большинства сложностей, связанных с оркестровкой контейнеров.
• Amazon Elastic Kubernetes Service (EKS) — управляемый контейнерный сервис для запуска и масштабирования приложений Kubernetes в облаке или на месте с помощью EKS в любом месте!
• AWS App Runner — Хотите запустить простой контейнер и не беспокоиться об этом? Попробуйте App Runner. Он подключается непосредственно к репозиторию кода или к реестру контейнеров и создает приложение на лету для вас. Когда вы вносите изменения, App Runner реагирует, перестраивает и повторно публикует приложение.
• Служба реляционных баз данных Amazon (RDS) — Базы данных сложно поддерживать самостоятельно, так зачем делать это самому, если Amazon может позаботиться об этом за вас? Выберите движок базы данных, MySQL, PostgreSQL, Oracle или даже SQL Server, выберите количество процессора, памяти и способ хранения данных, а Amazon позаботится обо всем остальном за вас.
• AWS Lambda — бессерверные вычисления! Lambda — это бессерверный, управляемый событиями вычислительный сервис, который позволяет запускать код практически для любого типа приложений или бэкенд-сервисов без предоставления или управления серверами. Совсем. Функции Lambda можно запускать из большинства служб AWS или из собственного кода.
• Amazon CloudWatch — сбор, доступ и корреляция данных на единой платформе из всех ваших ресурсов, приложений и служб AWS.

Диаграмма потоков

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

Что вы пытаетесь запустить?

После того, как службы созданы, возникает вопрос: «Что вы на самом деле хотите запустить?» и «Как вы хотите это сделать»?

• Если вы переносите рабочую нагрузку непосредственно с локальной виртуальной машины, без возможности контейнеризации или рефакторинга приложения, Amazon EC2, вероятно, будет правильным выбором для вас. Вы сами выбираете количество ядер процессора и объем памяти, и можете использовать Amazon Application Migration Service (AWS MGN) для автоматизации миграции!
• У вас есть совершенно новое приложение, которое вы создаете, с ограниченным количеством зависимостей? Рассмотрите возможность пойти в совершенно новом направлении, где вам не придется беспокоиться о серверах или инфраструктуре. Бессерверные вычисления с использованием таких сервисов, как AWS Lambda и Amazon API Gateway, позволяют создавать приложения и запускать их только тогда, когда они вам нужны, и платить только за выполнение функций — и это очень дешево. В разы дешевле, чем если бы вы запускали код на любом другом сервисе. Я рекомендую посмотреть, как компания, например, «A Cloud Guru», использует всю свою платформу видео-обучения на AWS Lambda и Serverless. Эта архитектура требует от вас переосмысления того, как вы создаете свое приложение, но она не очень сложна, и вы можете сэкономить значительное количество энергии и денег.

Контейнеры

• Когда у вас есть контейнеры для запуска, у вас есть несколько вариантов в зависимости от того, насколько вы хотите контролировать оркестровку самих контейнеров.
  • Если вам нужен простой контейнер с минимальными зависимостями, то AWS App Runner — отличный способ запустить контейнер.
  • В качестве альтернативы, если вы не ожидаете большого трафика для приложения, Amazon Lightsail также является недорогим способом запуска контейнеров, только не ожидайте слишком большой интеграции с другими службами AWS.
  • Хотите оркестровку контейнеров с автоматическим масштабированием, с использованием решений с балансировкой нагрузки, но не хотите ее поддерживать? Amazon Elastic Container Service (Amazon ECS) на Fargate — идеальный вариант! Работая на Fargate, вам не нужно обслуживать серверы или беспокоиться о выделении мощностей, AWS позаботится обо всем за вас, включая масштабирование, балансировку нагрузки и поддержку плоскости управления. Он прост в настройке и очень хорошо интегрируется с другими инструментами, такими как CodePipeline, CodeBuild и CodeCommit.
  • Kubernetes — удивительная технология, обеспечивающая невероятное масштабирование и расширение благодаря своему открытому исходному коду, но она может быть сложной в настройке и особенно в долгосрочной поддержке. Amazon EKS решает многие сложные вопросы, связанные с управлением кластером Kubernetes, предоставляя управляемую плоскость управления в нескольких центрах обработки данных для обеспечения высокой доступности, заботясь о доступности и масштабировании, а также автоматически обнаруживая и заменяя неработающие узлы плоскости управления. EKS обеспечивает гибкость Kubernetes, не требуя при этом целой команды специалистов по инфраструктуре для управления кластером. Он также значительно упрощает интеграцию и аутентификацию с другими службами AWS.

Базы данных

• В большинстве случаев вам нужен не только вычислительный сервис, но и место для хранения данных. Amazon предоставляет несколько сервисов баз данных в зависимости от ваших потребностей:
  • После нескольких лет работы с базами данных в AWS я не могу не подчеркнуть, насколько сильно я рекомендую Amazon Aurora, если вы используете MySQL или PostgreSQL в производстве. Amazon Aurora выводит концепцию управляемой базы данных на новый уровень, автоматизирует репликацию в нескольких зонах доступности или регионах, распределенное хранение и обладает невероятной производительностью. Вам больше не нужно беспокоиться о масштабировании или увеличении хранилища базы данных — Aurora позаботится обо всем этом. Для производства мы бы выбрали Aurora в 10/10 случаев.
  • Для небольших проектов, разработки или если вам нужны OracleDB, MSSQL или даже некоторые пользовательские базы данных, Amazon RDS — это управляемая служба баз данных, абстрагирующая от необходимости поддерживать сам сервер баз данных и делающая обслуживание базы данных невероятно простым. Вам все еще нужно предоставлять емкость и следить за ней, но это все равно удивительная услуга, позволяющая избежать необходимости обслуживать сервер баз данных.
  • Последние полдесятилетия также стали свидетелями метеоритного взлета баз данных NoSQL. AWS предлагает фантастический управляемый сервис баз данных NoSQL с ключами-значениями, известный как DynamoDB. Она отличается однозначной миллисекундной производительностью при практически неограниченной пропускной способности и хранении данных. В ней есть шифрование данных в состоянии покоя, резервное копирование и восстановление, а также автоматическая многорегиональная репликация. Хранилище стоит недорого, и его стоит попробовать для проектов, которые хорошо работают с базами данных NoSQL.
  • Другой хорошей альтернативой для рабочих нагрузок NoSQL является Amazon DocumentDB с совместимостью с MongoDB. Построенная на базе Amazon Aurora и поддерживающая API MongoDB 3.6 и 4.0, DocumentDB позволяет управлять базой данных в JSON с невероятной производительностью и поддержкой инструментов AWS.

Помимо всех традиционных типов баз данных, AWS также предлагает ряд других баз данных, таких как Amazon ElastiCache с поддержкой Redis и Memcached, графовые базы данных с Amazon Neptune, хранилища данных с AWS Redshift и многое другое. Все они хорошо документированы и часто требуют какого-то особого случая использования, поэтому я не буду тратить на них много времени.

Мысли о привязке к поставщику

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

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

• Пока вы работаете с поставщиком облака, у вас всегда будет множество функций, которые вы должны использовать, и которые являются собственностью облака. Примерами этого являются IAM и предоставление учетных записей, проектирование VPC, проектирование баз данных (если только вы не запускаете свою собственную базу данных как виртуальную машину — а если вы так делаете, то почему вы в облаке, а не просто в центре данных…) (также обратите внимание, что это не включает данные!) и многое другое.
• Убедившись, что вы декларируете всю свою облачную инфраструктуру на языке IaC, не зависящем от облака, вы смягчите многие из этих проблем.
• Ваши данные практически никогда не заблокированы, но то, как вы управляете этими данными, может быть в той или иной степени. Однако: независимо от того, какое «облако» вы используете и какой сервис вы используете в этом «облаке», миграция данных ВНЕ любого поставщика «облака» будет безумно дорогой, если у вас больше нескольких ТБ данных. Речь идет о десятках, а то и сотнях тысяч долларов в зависимости от объема данных. Большинство поставщиков облачных услуг, включая AWS, имеют инструменты миграции, которые вы можете использовать, чтобы очень легко перенести данные в их сервис, что означает, что ваши данные в безопасности. Есть некоторые предостережения: AWS Lambda нельзя напрямую перенести в Azure Cloud Functions без довольно большого рефакторинга. Переход с Google Kubernetes Engine на Amazon EKS потребует от вас рефакторинга того, как ваш кластер Kubernetes интегрируется с другими сервисами, но переход с базы данных MySQL, управляемой Azure, на базу данных MySQL, управляемую Google, совсем не сложен.
• Очень, ОЧЕНЬ мало компаний когда-либо переходят на другого поставщика облачных услуг. Я видел, как компании строят свою инфраструктуру, избегая использования собственных решений облачных поставщиков, а вместо этого управляя ею самостоятельно, чтобы быть облачными агностиками, но при этом никогда не рассматривают возможность миграции своей инфраструктуры. Вместо этого они платят за свою инфраструктуру во много-много раз больше, чем нужно. Управляемая инфраструктура часто дешевле, и она становится абсолютно дешевой, когда вы начинаете подсчитывать количество часов обслуживания, которое она требует.
• Очень важно иметь план действий на случай миграции. Это план Б на случай, если AWS обанкротится или Azure решит, что вы больше не нужны на их платформе. Потратив несколько часов на обдумывание и написание эскиза того, что вам нужно сделать в случае необходимости миграции, будет очень полезно. Кроме того, запись причин, по которым вы изначально выбрали своего поставщика облачных услуг, также поможет облегчить сомнения, которые могут возникнуть впоследствии, и уменьшить стресс, связанный с вопросом «а что, если мы захотим перейти».

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

Заключение

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

Кроме того, если вы хотите попробовать большинство из этих сервисов (EKS не входит), AWS предлагает очень щедрый бесплатный уровень, позволяющий вам попробовать большинство сервисов бесплатно, ничего не платя.

Если вы недавно начали использовать AWS и хотите знать, куда двигаться дальше, я настоятельно рекомендую изучить учебные материалы для некоторых сертификаций AWS. Вам не обязательно проходить сертификацию, если вы этого не хотите, но материалы для таких сертификаций, как AWS Certified Developer — Associate, позволят вам за короткое время познакомиться с огромным количеством сервисов.

И если вам когда-нибудь понадобится помощь в выборе сервиса или у вас возникнут вопросы о том, как вы должны управлять своим дерьмом — не стесняйтесь, обращайтесь ко мне!