Создание бизнес-потребностей

Каждое решение по разработке должно соответствовать бизнес-требованиям. Этот принцип проектирования может показаться очевидным, но имеет решающее значение, чтобы помнить при разработке приложений Azure.

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

Следующие рекомендации помогут вам разработать и создать решения для удовлетворения бизнес-требований.

  • Определите бизнес-цели , такие как целевое время восстановления (RTO), целевая точка восстановления (RPO) и максимальный допустимый сбой (MTO). Эти значения и станут критериями при выборе архитектуры. Например, если для бизнеса требуется низкий RTO, можно реализовать автоматическую отработку отказа в дополнительный регион. Но если ваш бизнес может терпеть более высокий RTO, возможно, вам не потребуется эта степень избыточности.

  • Документирование соглашений об уровне обслуживания (SLA) и целей уровня обслуживания (SLO), включая метрики доступности и производительности. Например, предлагаемое решение может обеспечить доступность 99,95 %. Соответствует ли это соглашение об уровне обслуживания бизнес-решением.

  • Моделиируйте приложения для вашего бизнес-домена. Проанализируйте бизнес-требования и используйте эти требования для моделирования решения. Рассмотрите возможность использования подхода к проектированию на основе домена (DDD) для создания моделей предметных областей, которые отражают бизнес-процессы и варианты использования.

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

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

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

  • Управление затратами. В традиционном локальном приложении вы платите за оборудование в качестве капитальных расходов. В облачном приложении вы платите за используемые ресурсы. Убедитесь, что вы понимаете модель ценообразования служб. Общие затраты могут включать использование пропускной способности сети, хранилище, IP-адреса и потребление служб.

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

Дальнейшие действия