Cenário 1 – Arquitetar escala global e acesso seguro

• 10 minutos

Nas duas unidades a seguir, você examinará dois cenários de negócios. As descrições da empresa, as metas do projeto e as restrições já foram disponibilizados para você. Você pode trabalhar nisso por conta própria, mas talvez seja interessante debater com outras pessoas, se possível.

Processo para o desenvolvimento de soluções

Sua meta, nesses cenários e provavelmente no mundo real, é entender:

• O problema que a empresa precisa resolver.
• Os requisitos e as restrições que acompanham uma solução.

Essa meta geralmente está na forma de uma declaração de problema. É um conjunto formal de parágrafos que definem claramente as circunstâncias, a condição atual e os resultados desejados para uma solução. Neste momento, evite explorar como resolver o problema e se concentre no que deseja resolver.

Depois que você (e provavelmente a sua equipe e stakeholders) concordarem em uma instrução de problema, você deverá extrair o máximo de requisitos (metas) que você puder encontrar para o projeto. Em seguida, separe as restrições que a solução tiver.

Neste momento, é aceitável ter restrições não realistas. Posteriormente, você pode retirá-las depois de mostrar uma razão custo/benefício de cada requisito e restrição.

Em produção, normalmente há seis fases para criar uma solução. O desenvolvimento da declaração do problema é apenas o começo.

1. Descoberta: a instrução original do problema do cliente.
2. Perspectiva: uma descrição otimista de como seria o sucesso no projeto. Frequentemente é elaborada como sentenças do tipo "Eu posso...".
3. Sessão de design de arquitetura: um layout inicial das escolhas e opções de tecnologia de uma solução preliminar.
4. POC (Prova de Conceito): depois que as tecnologias e os processos ideais são selecionados para a solução, uma POC é configurada com um pequeno exemplo de como seria a solução. Se disponível, uma solução atualmente em execução em um exemplo paralelo poderá ser usada.
5. Implementação: implementação de uma distribuição em fases da solução concluída com base nas descobertas das fases anteriores.
6. Entrega: uma análise posterior do projeto com uma discussão sobre melhorias futuras.

Ao longo deste módulo, você pode aproveitar modelos de projeto e os ícones mais recentes. Esses ativos também podem ser usados nas suas cargas de trabalho de produção.

Para os cenários deste módulo, você gastará algum tempo determinando a declaração do problema (descoberta). Mas o grande foco estará na sessão de design da arquitetura. Se você quiser desenvolver uma solução além do módulo, poderá usar os ativos no módulo para fazer isso.

Detalhes do cenário

O seu cliente é um provedor de serviços e de entrega de conteúdo em todo o mundo. Ele solicitou a sua ajuda para criar um sistema que possa lidar com milhares de gravações por segundo no que é essencialmente um data mart operacional.

O cliente também precisa da capacidade de executar análises em tempo real nos dados, para determinar tendências e identificar anomalias. Atualmente, ele está fazendo isso com aplicativos CLR (Common Language Runtime). O cliente não está procurando um data warehouse nem buscando utilizar grandes partes da área da superfície do SQL, mas é necessário que ele possa escalar o local em que os usuários residem.

O cliente também está tentando determinar quais métodos de autenticação usar no ambiente híbrido dele. Embora o aplicativo e a solução principal estejam no Azure, o cliente também precisa acomodar o seguinte:

• Um aplicativo em um computador não Azure conectado ao domínio.
• Um aplicativo mais antigo que não permitirá a alteração do driver nem da cadeia de conexão em um computador não Azure.
• Vários usuários que executam relatórios nas ferramentas de administração do SQL (SQL Server Management Studio, Azure Data Studio, PowerShell) em computadores não Azure não conectados ao domínio.

Sempre que possível, o cliente deseja eliminar senhas de hard-coding ou segredos nas cadeias de conexão e nos arquivos de configuração de aplicativo. Além disso, ele deseja eliminar o uso de senhas em ferramentas SQL ou encontrar uma forma de aprimorar essa autenticação.

Diretrizes de cenário

• Comece com a opção de implantação do SQL do Azure que é mais compatível com a solução atual e está disponível atualmente.
• Como o cliente escalará em várias regiões com várias consultas simultâneas e, ao mesmo tempo, isolará as cargas de trabalho de leitura das cargas de trabalho de gravação?
• Como o cliente pode acessar dados nas várias implantações?
• Quais métodos de autenticação você recomendaria para os caminhos de interação descritos no cenário?

Tarefas

1. Depois de examinar o cenário e as diretrizes fornecidas, extraia o máximo de requisitos do projeto que você conseguir encontrar.

2. Liste as possíveis tecnologias e os processos que podem potencialmente ser usados em uma solução. Fique à vontade para adaptar o cenário para ter mais informações quando você quiser clareza. Nesse caso, você pode fazer suposições.

   Dica

   Para os desafios de segurança, considere usar o guia estratégico de melhores práticas de segurança do SQL do Azure.

3. Usando uma matriz de decisão ou algum outro processo de decisão, selecione tecnologias e processos que criarão a sua solução preliminar.

4. Faça algumas observações que apresentam as metas e restrições do projeto, bem como o design de solução recomendado.

Depois de ter uma solução preliminar em mente, a próxima etapa costuma ser apresentá-la à equipe maior (ou ao cliente ou, ainda, à liderança, dependendo do cenário). Você precisará montar e apresentar a sua solução de uma forma que compartilhe as metas e as restrições do projeto, bem como mostre como a sua solução lida com esses itens.

Quando estiver pronto, responda às perguntas a seguir para avaliar como a sua solução se compara com uma solução de exemplo. Pode haver várias respostas certas, então mesmo que a sua solução não esteja listada, ela pode ser viável.

Verificação de conhecimentos