Сценарий 1. Разработка архитектуры в глобальном масштабе и безопасный доступ

• 10 мин

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

Процесс разработки решений

Ваша цель в этих сценариях и, вероятно, в реальном мире заключается в том, чтобы определить:

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

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

После того как вы (и, вероятно, ваша команда и заинтересованные лица) сможете согласованно сформулировать задачу, необходимо определить максимально возможное число требований (целей) для проекта. Затем изложите все ограничения, которые есть у решения.

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

В рабочей среде для создания решения обычно используется шесть этапов. Разработка постановки задачи — это только начало.

1. Обнаружение: исходная инструкция проблемы от клиента.
2. Представление: "Синее небо" описание того, какой успех в проекте будет выглядеть. Часто формулируется в виде выражений Я могу....
3. Сеанс проектирования архитектуры: начальный макет вариантов технологий и вариантов предварительного решения.
4. Подтверждение концепции (POC): после выбора оптимальных технологий и процессов для решения, POC настраивается с небольшим примером того, как может выглядеть решение. Если доступно текущее используемое решение в аналогичном примере, можно использовать его.
5. Реализация: реализация поэтапного развертывания завершенного решения на основе результатов предыдущих этапов.
6. Передача: посмертный обзор проекта с обсуждением будущих улучшений.

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

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

Подробности сценария

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

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

Клиент также пытается определить методы проверки подлинности, которые лучше использовать в его гибридной среде. Хотя основное решение и приложение будут работать в Azure, они также должны работать:

• с приложениями, которые находятся на присоединенных к домену компьютерах, не относящихся к Azure;
• устаревшими приложениями, которые не позволяют изменить драйвер или строку подключения, на компьютерах, не относящихся к Azure;
• несколькими пользователями, которые запускают отчеты из средств администрирования SQL (SQL Server Management Studio, Azure Data Studio, PowerShell) на компьютерах, не относящихся к Azure и не присоединенных к домену.

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

Рекомендации по сценарию

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

Задачи

1. После рассмотрения сценария и предоставленных рекомендаций сформулируйте столько требований для проекта, сколько возможно.

2. Перечислите возможные технологии и процессы, которые потенциально могут использоваться в решении. Адаптируйте сценарий, если это нужно для прояснения определенных вопросов. В этом случае можно делать предположения.

   Совет

   Для решения задач, связанных с безопасностью, можно использовать Сборник схем по рекомендациям безопасности для SQL Azure.

3. Используя матрицу принятия решений или какой-либо другой процесс принятия решений, выберите технологии и процессы, которые будут лежать в основе предварительного решения.

4. Кратко сформулируйте цели и ограничения своего проекта, а также рекомендуемый проект решения.

После формулировки предварительного решения его можно представить большей группе людей (а также клиенту, руководству и т. д. в зависимости от сценария). Вам потребуется скомпоновать и представить свое решение таким образом, чтобы были понятны цели и ограничения проекта и то, как они реализуются в вашем решении.

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

Проверка знаний