O exame DP-300 testa repetidamente a capacidade de escolher o modelo de implantação do Azure SQL correto para cada cenário. Azure SQL Database, Azure SQL Managed Instance e SQL Server on Azure VM podem parecer variações do mesmo serviço, mas diferem fundamentalmente em responsabilidade de gerenciamento e suporte a recursos. É como a diferença entre reservar um quarto de hotel, alugar um andar inteiro de escritório e comprar um prédio. Uma vez escolhido um modelo, mudar implica um projeto completo de migração, por isso a decisão inicial é determinante.
Azure SQL Database — O modelo de quarto de hotel
Ao se hospedar em um hotel, você gerencia apenas o seu quarto. A estrutura do prédio, os elevadores e as instalações elétricas são responsabilidade do hotel. O Azure SQL Database funciona da mesma forma. A Microsoft cuida do SO, dos patches do mecanismo SQL Server, dos backups e da alta disponibilidade, enquanto a equipe foca no design do esquema, no desempenho das consultas e no controle de acesso.
Três camadas de serviço estão disponíveis: General Purpose para cargas de trabalho padrão, Business Critical com réplicas em memória e uma réplica secundária legível, e Hyperscale com armazenamento distribuído que escala até 100 TB. A camada Serverless pausa automaticamente durante períodos ociosos para reduzir custos. Para arquiteturas SaaS com múltiplos locatários, o Elastic Pool é a opção ideal. SQL Server Agent, consultas entre bancos de dados, assemblies CLR e Service Broker não são suportados.
Azure SQL Managed Instance — O modelo de andar alugado
Alugar um andar inteiro de um prédio de escritórios permite organizar o interior como desejar. A estrutura do prédio e os elevadores continuam sendo responsabilidade do proprietário. O Azure SQL Managed Instance segue esse padrão. A Microsoft gerencia o SO e a infraestrutura, mas no nível da instância você obtém compatibilidade de recursos quase completa com o SQL Server.
SQL Server Agent, consultas entre bancos de dados, assemblies CLR, Service Broker, Linked Servers e Database Mail funcionam todos no Managed Instance. A compatibilidade é aproximadamente equivalente ao SQL Server 2019, tornando-o o destino natural para migrações lift-and-shift do SQL Server local com alterações mínimas de código. O Managed Instance é implantado em uma sub-rede de VNet dedicada com integração nativa de VNet, permitindo conectividade direta de ambientes locais via ExpressRoute ou VPN Site-to-Site. O Instance Pool permite que várias instâncias menores compartilhem um pool de computação para reduzir custos.
SQL Server on Azure VM — O modelo do proprietário do prédio
Ser proprietário de um prédio significa que você pode derrubar paredes ou instalar uma sala de servidores no subsolo. Você tem controle total, mas cada reparo também é sua responsabilidade. O SQL Server on Azure VM oferece controle completo sobre o SO e a versão do SQL Server, mas patches, backups e monitoramento ficam inteiramente a cargo da equipe.
Este modelo é necessário quando é preciso acesso ao SO para uma ferramenta de terceiros, quando uma versão específica e mais antiga do SQL Server deve ser mantida, ou quando é necessário configurar um cluster de failover do Windows Server com Failover Cluster Instance ou um Always On Availability Group configurado manualmente. O Azure Hybrid Benefit permite reduzir custos usando licenças locais existentes.
Azure Arc-enabled SQL Server — Extensão híbrida
Imagine conectar os sistemas de inventário de armazéns remotos à sede em tempo real, independentemente de onde cada armazém esteja. O Azure Arc-enabled SQL Server desempenha um papel semelhante. Instâncias do SQL Server em execução on-premises ou em outras nuvens se conectam ao plano de controle do Azure, permitindo aplicar Azure Policy, Microsoft Defender for SQL e Azure Monitor de forma uniforme em todas elas.
A responsabilidade pela infraestrutura ainda recai sobre a equipe local ou remota. É IaaS por natureza, mas as ferramentas de gerenciamento e as políticas de segurança do Azure se estendem além dos limites do Azure. Quando um cenário do exame mencionar gerenciamento híbrido de SQL por meio do plano de controle do Azure, o Azure Arc-enabled SQL Server é a resposta.
Hyperscale e Serverless — Camadas especializadas
Uma biblioteca que ultrapassa 100.000 volumes eventualmente precisa de sistemas de armazenamento automatizados em vez de estantes comuns. O Azure SQL Database Hyperscale é projetado para uma situação semelhante. O armazenamento escala automaticamente até 100 TB, os backups baseados em snapshots são concluídos quase instantaneamente e o scale-out de leitura é suportado.
O Serverless aborda o cenário oposto: uma carga de trabalho que está ocupada pela manhã e completamente ociosa à noite, como um aplicativo interno usado apenas no horário comercial. A computação pausa automaticamente quando não há atividade, reduzindo os custos durante os períodos ociosos. Ambas as camadas existem dentro do Azure SQL Database, mas resolvem problemas muito diferentes.
Critérios de escolha do modelo
Ao decidir se deve comprar ou alugar um carro, a pergunta mais importante é como você vai usá-lo. Escolher um modelo de implantação do Azure SQL funciona da mesma forma.
SQL Server Agent, CLR ou consultas entre bancos de dados são necessários? Escolha Managed Instance, PaaS com recursos de nível de instância. Controle do SO ou versão específica do SQL Server é necessário? Escolha SQL Server on Azure VM. Minimizar a sobrecarga com um único banco de dados é suficiente? Escolha Azure SQL Database. Gerenciar SQL local ou multi-nuvem pelo Azure? Escolha Azure Arc-enabled SQL Server.
Ao decidir entre Managed Instance e Azure SQL Database, o SQL Server Agent é a pergunta decisiva. Se for necessário, escolha Managed Instance. Se não, o Azure SQL Database é mais simples. O Azure SQL Database e o Managed Instance incluem backups automáticos por padrão; o SQL Server on Azure VM não.
!Como escolher um modelo de implantação do Azure SQL
Armadilhas comuns no exame
Pedir comida apenas pela foto do cardápio às vezes traz surpresas. Os modelos de implantação do Azure SQL funcionam da mesma forma quando escolhidos pelo nome em vez das características.
A armadilha mais comum é assumir que PaaS significa compatibilidade completa de recursos. O SQL Server Agent e o CLR funcionam no Managed Instance, que é PaaS, mas não no Azure SQL Database, que também é PaaS. No momento em que o SQL Server Agent aparecer como requisito obrigatório, elimine o Azure SQL Database das opções.
A segunda armadilha é confundir Elastic Pool com Instance Pool. Elastic Pool agrupa vários Azure SQL Databases em um pool compartilhado. Instance Pool agrupa várias Managed Instances em um pool compartilhado. O recurso agrupado é diferente.
Resumo do Exame
"Minimizar sobrecarga operacional + banco de dados único" -- Azure SQL Database
"SQL Server Agent necessário + permanecer no PaaS" -- Azure SQL Managed Instance
"Acesso ao SO necessário / versão específica do SQL necessária" -- SQL Server on Azure VM
"SaaS com múltiplos locatários + otimização de custos" -- Azure SQL Database + Elastic Pool
"Mais de 100 TB + snapshots rápidos + escalabilidade de leitura" -- Azure SQL Database Hyperscale
"Carga de trabalho intermitente + pausa automática" -- Azure SQL Database Serverless
"Gerenciar SQL local a partir do plano de controle do Azure" -- Azure Arc-enabled SQL Server
"Consultas entre bancos de dados + migração lift-and-shift" -- Azure SQL Managed Instance
"Elastic Pool vs Instance Pool" -- pool de bancos de dados (Elastic Pool) vs pool de instâncias gerenciadas (Instance Pool)
"Backup automático sem configuração adicional" -- Azure SQL Database e Managed Instance sim, SQL Server on Azure VM não
Azure SQL Database = PaaS de BD único totalmente gerenciado, Azure SQL Managed Instance = PaaS compatível no nível de instância, SQL Server on Azure VM = IaaS de controle total