Создание бизнес-потребностей
Каждое решение по разработке должно соответствовать бизнес-требованиям. Этот принцип проектирования может показаться очевидным, но важно учитывать при разработке приложений Azure.
Должно ли ваше приложение поддерживать миллионы пользователей или несколько тысяч? Существуют ли большие всплески трафика или устойчивая рабочая нагрузка? Какой уровень сбоя приложения является допустимым? В конечном счете, бизнес-требования управляют этими рекомендациями по проектированию.
Следующие рекомендации помогут вам разработать и создать решения для удовлетворения бизнес-требований:
Определите бизнес-цели , такие как цель времени восстановления (RTO), цель точки восстановления (RPO) и максимальный допустимый сбой (MTO). Эти значения и станут критериями при выборе архитектуры.
Например, предположим, что для вашего бизнеса требуется очень низкий RTO и очень низкий RPO. Вы можете использовать архитектуру с избыточностью между зонами для удовлетворения этих требований. Если ваш бизнес может терпеть более высокий RTO и RPO, добавление избыточности может добавить дополнительные затраты для без использования бизнеса.
Рассмотрите риски сбоя, которые необходимо устранить. Следуйте рекомендациям по самостоятельному восстановлению, чтобы разработать решение, чтобы быть устойчивым ко многим типам распространенных режимов сбоев. Рассмотрим, следует ли учитывать менее вероятные ситуации, например географическое пространство, в котором возникает серьезная стихийная катастрофа, которая может повлиять на все зоны доступности в регионе. Устранение этих редких рисков, как правило, является более дорогим и включает значительные компромиссы, поэтому имеют четкое представление о терпимости бизнеса к риску.
Соглашения об уровне обслуживания документов (соглашения об уровне обслуживания) и цели уровня обслуживания (SLOS), включая метрики доступности и производительности. Например, предлагаемое решение может обеспечить доступность 99,95 %. Соответствует ли SLO соглашение об уровне обслуживания бизнес-решением.
Моделировать приложения для вашего бизнес-домена. Анализ бизнес-требований и использование этих требований для моделирования решения. Рекомендуется использовать подход на основе домена (DDD) для создания моделей предметных областей, которые отражают бизнес-процессы и варианты использования.
Определите функциональные и нефункциональные требования. Функциональные требования определяют, выполняет ли приложение свою задачу. Нефункциональные требования определяют, насколько хорошо работает приложение. Убедитесь, что вы понимаете нефункциональные требования, такие как масштабируемость, доступность и задержка. Эти требования влияют на принятие решений по проектированию и выбор технологий.
Разложим рабочие нагрузки на дискретные функциональные возможности. Рабочая нагрузка — это коллекция ресурсов приложений, данных и вспомогательной инфраструктуры, которые работают вместе для достижения определенных бизнес-результатов. Рабочая нагрузка состоит из компонентов, а также процедур разработки и эксплуатации. Рабочие нагрузки часто можно разложить на дискретные функциональные возможности, которые соответствуют пользовательским, данным или системным потокам, а эти потоки могут быть связаны со значением и иметь нефункциональное требование.
Разные потоки пользователей, данных или систем часто имеют разные требования к доступности, масштабируемости, согласованности данных и аварийному восстановлению. Хорошо разработанные системы позволяют оптимизировать дизайн на поток. Для этого необходимо разбить рабочие нагрузки на настраиваемые компоненты. Типичная стратегия включает классификацию компонентов на основе их значения. Например, компоненты уровня 1 являются важными и должны быть оптимизированы без учета расходов. Компоненты уровня 2 являются значительными, но могут быть временно сокращены с минимальными последствиями. Компоненты уровня 3 являются необязательными; держите их экономически эффективным и легко управляемым. Создание общего понимания ценности потоков помогает всем разрабатывать и развивать рабочую нагрузку баланс между затратами и другими нефункциональными требованиями.
Учитывайте темпы роста. Решение может поддерживать текущие потребности в количестве пользователей, тома транзакций и хранилища данных, но он также должен обрабатывать рост без серьезных изменений архитектуры. Кроме того, учитывайте, что бизнес-модель и бизнес-требования могут меняться со временем. Трудно разработать решение для новых вариантов использования и сценариев, если модель службы приложения и модели данных слишком жесткие.
Выравнивание бизнес-модели и затрат. Долголетие системы зависит от того, насколько эффективно ее затраты соответствуют бизнес-модели. В качестве архитектора необходимо учитывать драйверы ценности и использовать эти аналитические сведения, чтобы руководствоваться вашими решениями. Необходимо определить измерение, в котором ваше решение будет предоставлять значение (например, прибыльность), а затем убедиться, что архитектура следует потоку значений. Таким образом, архитектура может максимизировать ценность инвестиций, что дает рентабельность инвестиций (ROI), которая соответствует бизнес-ожиданиям.
Контролируйте затраты. В традиционном локальном приложении вы оплачиваете оборудование как капитальные расходы. В облачном приложении вы оплачиваете используемые ресурсы. Убедитесь, что вы понимаете модель ценообразования служб. Общие затраты могут включать использование пропускной способности сети, хранилище, IP-адреса и потребление служб.
Кроме того, рассмотрите расходы на операции. В облаке вам не нужно управлять оборудованием или инфраструктурой, но вам по-прежнему необходимо управлять приложениями DevOps, реагированием на инциденты и аварийное восстановление.