Cenário 1 – Arquitetar escala global e acesso seguro
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.
- Descoberta: a instrução original do problema do cliente.
- Perspectiva: uma descrição otimista de como seria o sucesso no projeto. Frequentemente é elaborada como sentenças do tipo "Eu posso...".
- Sessão de design de arquitetura: um layout inicial das escolhas e opções de tecnologia de uma solução preliminar.
- 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.
- Implementação: implementação de uma distribuição em fases da solução concluída com base nas descobertas das fases anteriores.
- 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
Depois de examinar o cenário e as diretrizes fornecidas, extraia o máximo de requisitos do projeto que você conseguir encontrar.
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.
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.
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.