Разработка с учетом бизнес-потребностей

Каждое решение в процессе разработки должно определяться бизнес-требованиями.

Этот принцип может показаться очевидным, но им не всегда руководствуются при разработке решений. У вас будут миллионы пользователей или всего несколько тысяч? Приемлем ли сбой приложения в один час? Планируется ли большой объем трафика или прогнозируемая рабочая нагрузка? Любое решение по разработке должно в конечном счете соответствовать бизнес-требованиям.

Рекомендации

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

Задокументируйте соглашения об уровне обслуживания (SLA) и цели уровня обслуживания (SLO), включив в них показатели доступности и производительности. Допустим, вы создали решение с гарантированным уровнем доступности 99,95 %. Это много или мало? Ответ зависит от принятых бизнес-решений.

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

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

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

Планируйте рост. Возможно, решение полностью соответствует текущим потребностями в плане количества пользователей, объема транзакций, хранилища данных и т. д. Но действительно надежное приложение должно выдерживать определенный рост без существенных изменений архитектуры. См. также статьи Design to scale out (Разработка с учетом горизонтального масштабирования) и Partition around limits (Разделение для обхода ограничений). Кроме того, не забывайте, что бизнес-модель и бизнес-требования могут со временем измениться. Если в приложении используются слишком жесткие модели службы и данных, его будет трудно развивать для использования новых сценариев и методов работы. См. статью Design for evolution (Разработка с учетом будущих изменений).

Управление затратами. В традиционном локальном приложении вы платите за оборудование в качестве капитальных расходов. Но в облачных приложениях вы платите только за используемые ресурсы. Хорошо изучите модель ценообразования для всех используемых служб. Общая стоимость определяется с учетом пропускной способности сети, объема хранилища, IP-адресов, используемых служб и других факторов. Дополнительные сведения см. на странице цен на приложения логики. Также учтите затраты на эксплуатацию. В облаке вам не нужно управлять оборудованием или другой инфраструктурой, но по-прежнему требуется выполнять обслуживание приложения: DevOps, реагирование на инциденты, аварийное восстановление и т. д.