Привет, с вами Станислав Тибекин, CEO компании Nixys. Перед тем, как начать, советую подписаться на наш блог Хабр, TG‑канал DevOps FM и познакомиться с YouTube. Там выходит много интересного и полезного контента.

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

Приятного чтения!

Создание нового приложения требует тщательного проектирования. Да, это нормально пробовать, терпеть неудачи и исправлять ошибки в процессе. Но детально проработать план разработки всё равно нужно.

Поскольку технологии постоянно развиваются, новые сервисы появляются каждый день. Многие компании начинают использовать несколько облачных провайдеров, — и здесь очень важно избегать необъективных решений. На этапе проектирования приложения не привязывайтесь к конкретному облачному провайдеру. Вместо этого полностью изучите требования и ограничения и только после этого приступайте к выбору технологий и сервисов, которые вы будете использовать для архитектуры вашего приложения.

Разрабатываем бизнес-требования

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

Ниже приведены некоторые из распространенных бизнес‑требований:

• Доступность сервиса. Если приложение должно быть доступно для клиентов по всему миру — разработайте мультирегиональную архитектуру.

• Суверенитет данных. Если существует нормативное требование хранить данные клиентов в определённой стране, то нужно убедиться, что все компоненты инфраструктуры можно развернуть в облачном регионе, расположенном в этой стране. Примеры сервисов суверенитета данных: AWS Digital Sovereignment, Microsoft Cloud for Sovereignment и Google Digital Sovereignment.

• Время реакции. Если важно обеспечить быстрое реагирование на запросы клиентов, то вы можете рассмотреть возможность использования API или механизмов кэширования.

• Масштабируемость. Если необходимо предоставить клиентам высокомасштабируемое приложение, которое способно справляться с непредсказуемыми нагрузками, то можно подумать над использованием событийно‑ориентированной архитектуры (англ. event‑driven architecture, EDA) (например, использование очередей сообщений, потоковых сервисов и многого другого).

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

Возможно, вычисления — самый важный элемент любого современного приложения, и сегодня существует множество альтернатив для запуска внешнего интерфейса и реализации бизнес‑логики вашего приложения:

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

• Контейнеры и Kubernetes. Большинство современных приложений упаковываются в контейнеры и очень часто управляются с помощью оркестратора Kubernetes. Миграция контейнеров между разными облачными сервисами как процесс сам по себе не очень сложный, но нужно учитывать интеграцию с другими управляемыми сервисами в экосистеме CSP. Примеры сервисов Kubernetes: Amazon EKS, Azure AKS и Google GKE.

• Serverless / Functions‑as‑a-Service. Современный способ запуска различных частей приложений. Базовая инфраструктура полностью управляется облачным провайдером (нет необходимости заниматься масштабированием или обслуживанием инфраструктуры). Считается вендорлок‑вариантом, поскольку нет возможности мигрировать между CSP из‑за уникальных характеристик предложений каждого CSP. Примеры FaaS: AWS Lambda, Azure Functions и Google Cloud Functions.

Выбираем хранилище данных

Большинству приложений требуется постоянное хранилище для хранения и извлечения данных. Сloud‑native приложения (в особенности микросервисная архитектура) позволяют выбрать наиболее подходящее внутреннее хранилище данных для ваших приложений. В случае микросервисной архитектуры вы можете выбрать разные хранилища данных для каждого микросервиса.

Варианты для хранения данных:

• Объектное хранилище. Это наиболее распространённый управляемый сервис хранения, который используется большинством облачных приложений для хранения данных (из журналов, архивов, озера данных и т. д.). Примеры сервисов: Amazon S3, Azure Blob Storage и Google Cloud Storage.

• Файловое хранилище. Большинство CSP поддерживают управляемые службы NFS (для рабочих нагрузок Unix) или SMB/CIFS (для рабочих нагрузок Windows). Примеры служб хранения файлов: Amazon EFS, Azure Files и Google Filestore.

При проектировании архитектуры учтите такие требования приложений, как:

• Требования к быстрому получению данных (требования к быстрому чтению/записи). Измеряется в IOPS.

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

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

• Репликация данных (возможность репликации данных на нескольких AZ или даже в нескольких регионах).

Выбираем базу данных

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

• Реляционная база данных используется для хранения структурированных данных, хранящихся в таблицах, строках и столбцах. Подходит для выполнения сложных запросов. При выборе смотрите в сторону тех СУБД, которые поддерживают движки с открытым исходным кодом, такие как MySQL или PostgreSQL, чтобы снизить вероятность привязки к поставщику. Примеры сервисов реляционных баз данных: Amazon RDS, Azure SQL и Google Cloud SQL.

• Key‑value хранилище — это БД, предназначенная для хранения больших объёмов структурированных или неструктурированных данных с быстрым доступом. Такими базами данных являются, например, Amazon DynamoDB, Azure Cosmos DB и Google Bigtable.

• In‑memory база данных — БД, оптимизированная для доступа к данным за доли миллисекунды, например, на уровне кэширования. Amazon ElastiCache, Azure Cache для Redis и Google Memorystore для Redis.

• Документоориентированная база данных подходит для хранения документов в формате JSON. Примеры баз данных документов: Amazon DocumentDB, Azure Cosmos DB и Google Cloud Firestore.

• Графовая база данных — БД для хранения и навигации по связям между сущностями (например, в рекомендательной системе). Примером такой базы данных служит Amazon Neptune.

• База данных временных рядов предназначена для данных, которые изменяются с течением времени (например, метрики приложений, данные с IoT‑устройств и т. д.). Примеры таких БД: Amazon Timestream, Azure Time Series Insights и Google Bigtable.

При разработке высокомасштабируемых приложений одним из важных моментов является репликация данных, а именно возможность репликации данных между несколькими зонами доступности. Ещё более сложный аспект — возможность репликации данных в нескольких регионах. Лишь немногие СУБД поддерживают глобальные таблицы или репликацию в нескольких регионах, в то время как большинство БД требуют наличия особого механизма для репликации обновлений базы данных между регионами.

Автоматизируем и разрабатываем

Автоматизация позволяет нам выполнять повторяющиеся задачи быстрым и предсказуемым образом. В облачных приложениях благодаря автоматизации мы можем создать CI/CD конвейер для приёма разработанного программистами кода, интеграции различных компонентов приложения и базовой инфраструктуры, выполнения различных тестов (от QA до тестов безопасности) и, в конечном итоге, для развертывания новых версий нашего приложения.

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

• Репозитории кода. Выберите центральное место для хранения всего кода вашей команды. Это позволит вам использовать одно и то же хранилище как для текущей работы, так и для нескольких облачных сред. Примеры репозиториев кода: AWS CodeCommit, Azure Repos и Google Cloud Source Repositories.

• Репозитории образов контейнеров. Выберите центральное хранилище образов и синхронизируйте его между регионами и, если потребуется, между облачными провайдерами, чтобы сохранить один и тот же источник достоверности. В качестве примеров таких репозиториев можно назвать Amazon ECR, Azure ACR и Google Artifact Registry.

• CI/CD и процесс сборки. Выберите инструмент для управления конвейером CI/CD для всех развертываний, независимо от того, используете ли вы одного облачного провайдера или многооблачную среду. Примеры сервисов сборки CI/CD: AWS CodePipeline, Azure Pipelines и Google Cloud Build.

• Инфраструктура как код. Организации, которые хорошо разбираются в ПО, выбирают подход IaC для создания инфраструктуры как для одиночных, так и для мультиоблачных сценариев, снижая нагрузку на команды DevOps, ИТ и разработчиков. Примеры IaC: AWS CloudFormation, Azure Resource Manager, Google Cloud Deployment Manager и HashiCorp Terraform.

Обеспечиваем отказоустойчивость

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

Все уровни инфраструктуры должны быть устойчивыми. Всегда размещайте виртуалки или контейнеры в кластере за балансировщиком нагрузки, независимо от выбранного вами вычислительного сервиса. Лучше использовать управляемый сервис хранения, развёрнутый в нескольких зонах доступности. Для постоянной базы данных выберите управляемый сервис и разверните его в кластере, в нескольких AZ или, что ещё лучше, найдите бессерверную БД — тогда вам не нужно будет поддерживать её доступность.

Не оставляйте всё на волю случая. Включайте эксперименты с chaos engineering в тесты на отказоустойчивость рабочих нагрузок, чтобы лучше понимать, как ваша рабочая нагрузка переживёт сбой. Примеры управляемых сервисов хаос‑инженерии: AWS Fault Injection Service и Azure Chaos Studio.

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

Одно из важнейших требований к приложению — способность пережить сбой и продолжить работать должным образом. Поэтому очень важно заранее спроектировать непрерывность деятельности бизнеса.

• Для любой службы, поддерживающей резервное копирование или снапшоты (виртуалки, БД и службы хранения) включите бэкапирование по расписанию и выборочно тестируйте резервные копии, чтобы убедиться в их работоспособности.

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

• Для реестра контейнеров, также требующего отказоустойчивости, настройте репликацию образов по регионам.

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

Мониторим

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

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

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

Считаем затраты

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

Ответственность за финансовые аспекты может нести любой член команды (ИТ‑специалист, разработчик, DevOps‑инженер, архитектор, сотрудники службы безопасности и т. д.), как с точки зрения первоначальной стоимости обслуживания, так и с точки зрения эксплуатации. Мышление FinOps позволит нам быть уверенными в том, что мы выбираем правильный сервис для правильной цели — начиная от выбора вычислительного сервиса и заканчивая хранилищем данных и БД.

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

Думаем об экологии

Каждое архитектурное решение, которое мы принимаем, оказывает влияние на окружающую среду. Правильный выбор вычислительного сервиса позволит управлять рабочей нагрузкой с минимальным углеродным следом: использование контейнеров или бессерверных/FaaS‑систем приводит к меньшему расходу энергии в центрах обработки данных облачного провайдера. То же самое происходит при выборе хранилища данных в соответствии с моделями доступа к данным приложения (от горячего уровня или уровня реального времени до архивного уровня). Разработка приложений, управляемых событиями, добавление уровней кэширования, отключение незанятых ресурсов и постоянный мониторинг рабочей нагрузки позволят создать эффективную и устойчивую рабочую нагрузку.

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

Самое простое — это принять решение о создании нового приложения в облаке. Самое сложное — убедиться, что все команда едина в достижении бизнес‑целей и имеет нужный уровень знаний для разработки облачного приложения. Для этого компания должна инвестировать в обучение сотрудников, следя за тем, чтобы все члены команды обладали необходимыми знаниями для создания и поддержки современных cloud native приложений.

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

Ссылки на обучением: AWS Skill Builder, Microsoft Learn for Azure, and Google Cloud Training.

Подводим итог

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

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