Cenário 1 – Arquitetar o dimensionamento global e o acesso seguro
Nas duas unidades seguintes, irá rever dois cenários empresariais. As descrições, os objetivos do projeto e as restrições da empresa já foram definidos para si. Pode trabalhar nisto de forma autónoma, mas pode ser interessante trocar ideias com outras pessoas, se possível.
Processo de desenvolvimento de soluções
O seu objetivo, nesses cenários e provavelmente no mundo real, é compreender:
- O problema que a empresa precisa de resolver.
- Quaisquer requisitos e restrições associados a uma solução.
Este objetivo 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 pretendidos para uma solução. Neste momento, quer evitar explorar como resolver o problema e focar-se no que quer resolver.
Depois de concordar (e provavelmente a sua equipa e os intervenientes) com uma declaração de problema, deve retirar o máximo de requisitos (objetivos) para o projeto que consiga encontrar. Em seguida, concentre-se em quaisquer restrições que a solução tenha.
Neste momento, é aceitável que haja restrições irrealistas. Mais tarde, pode retirá-las depois de mostrar uma relação custo/benefício em 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 início.
- Descoberta: A declaração original do problema do cliente.
- Imaginação: Uma descrição "céu azul" de como seria o sucesso no projeto. Muitas vezes expressa com declarações "Posso...".
- Sessão de projeto de arquitetura: Um layout inicial das opções e escolhas de tecnologia para uma solução preliminar.
- Prova de conceito (POC): Depois que as tecnologias e processos ideais são selecionados para a solução, um POC é configurado com um pequeno exemplo representativo de como uma solução pode parecer. Se uma solução atualmente em execução num exemplo paralelo estiver disponível, pode utilizá-la.
- Implementação: Implementação de uma implementação faseada da solução concluída com base nos resultados das fases anteriores.
- Handoff: Um post mortem sobre o projeto com uma discussão de melhorias futuras.
Ao longo deste módulo, pode tirar partido de modelos de projeto e dos ícones mais recentes. Também pode utilizar estes recursos nas cargas de trabalho de produção.
Para os cenários neste módulo, irá passar algum tempo a determinar a declaração do problema (deteção). No entanto, o foco principal estará na sessão de design de arquitetura. Se quiser desenvolver uma solução mais adiante, após o módulo, poderá utilizar os recursos do módulo para o fazer.
Detalhes do cenário
O seu cliente é um fornecedor de serviços e entrega de conteúdos em todo o mundo. Pediu-lhe ajuda para criar um sistema que consiga processar milhares de escritas por segundo para o que é essencialmente um data mart operacional.
O cliente também precisa da capacidade de executar análises nos dados em tempo real, para determinar tendências e identificar anomalias. Atualmente, está a fazê-lo com aplicações CLR (Common Language Runtime). O cliente não procura um armazém de dados nem utilizar grandes porções da área de superfície SQL, mas precisa de conseguir dimensionar nas regiões onde os utilizadores vivem.
O cliente também está a tentar determinar quais os métodos de autenticação a utilizar no seu ambiente híbrido. Embora a principal solução e aplicação residam no Azure, o cliente também precisa de acomodar o seguinte:
- Uma aplicação numa máquina virtual não pertencente ao Azure que esteja associada ao domínio.
- Uma aplicação mais antiga que não permita alterar o controlador ou a cadeia de ligação numa máquina virtual não pertencente ao Azure.
- Múltiplos utilizadores que executam relatórios a partir de ferramentas de administração SQL (SQL Server Management Studio, Azure Data Studio, PowerShell) em máquinas virtuais não pertencentes ao Azure que não estejam associadas ao domínio.
Sempre que possível, o cliente quer eliminar palavras-passe de hard-coding ou segredos nas cadeias de ligação e nos ficheiros de configuração das aplicações. Também quer eliminar a utilização de palavras-passe em ferramentas SQL ou encontrar uma maneira de melhorar essa autenticação.
Orientações do cenário
- Comece pela opção de implementação do Azure SQL mais compatível com a solução atual e disponível neste momento.
- Como pode o cliente dimensionar em múltiplas regiões com múltiplas consultas em simultâneo, enquanto isola as cargas de trabalho de leitura das cargas de trabalho de escrita?
- Como pode o cliente aceder aos dados através das várias implementações?
- Que métodos de autenticação recomendaria para os caminhos de interação descritos no cenário?
Tarefas
Depois de rever o cenário e as orientações fornecidas, retire o máximo de requisitos para o projeto que consiga encontrar.
Enumere as possíveis tecnologias e processos que poderiam ser potencialmente utilizados numa solução. Não hesite em adaptar o cenário para ter mais informações quando quiser clareza. Pode fazer suposições neste caso.
Gorjeta
Para os desafios de segurança, pode considerar utilizar o manual de procedimentos de segurança do Azure SQL.
Ao utilizar uma matriz de decisão ou qualquer outro processo de decisão, selecione as tecnologias e os processos que irão compor a solução preliminar.
Tome algumas notas que apresentem os objetivos e restrições do projeto, bem como o design de solução recomendado.
Depois de ter uma solução preliminar em mente, o próximo passo é, muitas vezes, apresentá-la à equipa maior (ou cliente, liderança, etc., consoante o cenário). Terá de reunir e apresentar a solução de forma a partilhar os objetivos e as restrições do projeto, bem como a forma como a solução aborda esses fatores.
Quando estiver pronto, responda às perguntas seguintes para avaliar como a solução se compara a uma solução de exemplo. Pode haver múltiplas respostas certas, por isso, mesmo que a solução não esteja apresentada, poderá ser viável.