Hoje vamos falar um pouco sobre as opções de implantação do SQL na Azure, saber alguns detalhes importantes sobre cada um deles, podendo assim tomar a decisão certa na hora da sua escolha.
Primeiramente, o ponto mais importante é conhecermos quais são os modelos disponíveis para implementação, e posterior, com os seus detalhes entendermos as suas limitações e cruzar assim com as necessidades do seu ambiente! Então quais são os modelos disponíveis? Veja abaixo as três opções que devemos conhecer:
A imagem acima, descreve de maneira muito simplificada, para qual cenário é melhor cada uma das opções, é claro que não é tão simples quanto parece, mas vamos lá explicar um pouco melhor cada uma delas:
Representam aqui um servidor virtual na Azure, onde você tem a opção de escolher a versão do sistema operacional (Vamos chamar de S.O, ok?) e também a versão do SQL Server, além disso você tem acesso ao S.O, permitindo assim você administrar e ter acesso a recursos que podem ser necessários para o pleno funcionamento do seu sistema. Vale lembrar que aqui você se torna o responsável pela aplicação das atualizações no S.O e no SQL SERVER.
Este cenário é conhecido e faz parte do grupo IaaS (Infrasctructure as a Service), em uma tradução livre "Infraestrutura como um serviço".
Abaixo vamos rever algumas opções que você pode tirar proveito neste modelo e deve lembrar durante sua criação:
Em um resumo, para realizar a movimentação do seu ambiente para nuvem e se você deseja continuar controlando o S.O/SQL Server em sua totalidade, ou você usa um software de terceiros que necessita ter acesso ao S.O? A opção mais simples é sem dúvida as VMs do Azure, você pode tem o controle total dos versionamentos e acesso completo ao SQL com essa opção, mas fique atento aos detalhes para ter o máximo de desempenho possível e redução de preço durante a criação/existência da VM.
A instância gerenciada, é um modelo denominado como PaaS (Platform as a Service), ou em uma tradução livre, plataforma como um serviço. Usando este modelo teremos uma instância do SQL Server e retiramos grande parte da carga da administração do sistema operacional/Máquina virtual, além disso a maioria dos recursos hoje existentes no SQL Server também está disponível para utilização dentro dos recursos de instância gerenciada.
Este modelo é ideal para empresas que precisam manter algumas funcionalidades com escopo da instância, como exemplo SQL Agent, CLR (Common Language Runtime) e o Service broker entre vários outros pequenos detalhes
Outro detalhe importante, é que neste modelo você passa a não ter mais acesso aos recursos do sistema operacional, e não precisa mais se preocupar com eles, pois neste caso a responsabilidade passa a ser da Azure.
Vamos dar uma olhada em algumas opções interessantes para escolher este modelo:
Em um resumo geral, este serviço é indicado para empresas que querem manter grande parte do seu sistema sem grandes alterações, ou afetar o funcionamento de itens já existentes no modelo atual, é uma boa para quem ainda está iniciando a mudança do conceito On-premise para Nuvem, pois consegue ter uma boa noção do funcionamento dos serviços na nuvem sem grandes mudanças.
E por fim, mas não menos importante, temos o Azure SQL Database, também estando dentro do modelo PaaS (Platform as a Service), em uma tradução livre Plataforma como um serviço, neste modelo removendo totalmente a necessidade de administração de instâncias ou maquinas virtuais, permitindo de forma rápida e bastante simplificada que você obtenha um novo banco de dados e possa desenvolver seus aplicativos.
Alguns benefícios desta escolha:
Em um resumo, a opção sobre o SQL Database, é a versão totalmente simplificada da utilização de um database, de forma rápida você tem a possibilidade de escalar e ou começar a criar um aplicativo do zero com um database totalmente seguro e pronto para ser utilizado!!
Após conhecermos os três modelos de implementação de ambientes na Azure, precisamos conhecer mais um novo conceito, que se refere ao modo elástico de se trabalhar com recursos. Com isso teremos uma nova opção que pode agregar valor às suas necessidades, pois bem, o que significa de fato essa elasticidade?
Ter um pool de banco de dados, nos representa uma área em que eu posso ter vários bancos de dados e compartilhar os recursos definidos no meu pool conforme a necessidade de cada um, sem eu já precisar alocar previamente uma quantidade grande de recursos para um único database e que não vai ser muito bem aproveitada!!
Da mesma forma, podemos trabalhar com um pool de instâncias, no caso do Managed Instances, ao qual podemos ter diversas instâncias sobre este pool e compartilharmos os recursos entre elas, você pode por exemplo, alocar uma instância dentro de um pool de recursos com valores menores do que é necessário para uma única instância isolada, te dando assim a possibilidade de gerenciar de forma mais assertiva seus recursos.
Estes conceitos são muito usados quando pensamos em grandes migrações que precisamos fazer em conjunto, ou quando você trabalhar com SaaS (Software as a Service), podendo monitorar por exemplo muitos databases de forma simplificada.
Em um resumo geral, e para ficar de uma forma bem simplificada, adicionei abaixo uma imagem retirada das documentações da Azure, onde explica de forma simplificada os pontos chaves de cada uma das opções de implantação atuais no modelo Azure:
Todos os itens citados nesta publicação, podem ser encontrados diretamente nas documentações oficiais da Azure e os devidos treinamentos que são disponibilizados por ela, para mais detalhes busquem sempre as fontes oficiais!
Caso tenha alguma dúvida, basta entrar em contato com a Horus Solutions.
Cookie | Duração | Descrição |
---|---|---|
cookielawinfo-checbox-analytics | 11 months | Este cookie é definido pelo plug-in GDPR Cookie Consent. O cookie é usado para armazenar o consentimento do usuário para os cookies na categoria "Analytics". |
cookielawinfo-checbox-functional | 11 months | O cookie é definido pelo consentimento do cookie GDPR para registrar o consentimento do usuário para os cookies na categoria "Funcional". |
cookielawinfo-checbox-others | 11 months | Este cookie é definido pelo plug-in GDPR Cookie Consent. O cookie é usado para armazenar o consentimento do usuário para os cookies na categoria "Outros. |
cookielawinfo-checkbox-necessary | 11 months | Este cookie é definido pelo plug-in GDPR Cookie Consent. Os cookies são usados para armazenar o consentimento do usuário para os cookies na categoria "Necessário". |
cookielawinfo-checkbox-performance | 11 months | Este cookie é definido pelo plug-in GDPR Cookie Consent. O cookie é usado para armazenar o consentimento do usuário para os cookies na categoria "Desempenho". |
viewed_cookie_policy | 11 months | O cookie é definido pelo plug-in GDPR Cookie Consent e é usado para armazenar se o usuário consentiu ou não com o uso de cookies. Ele não armazena nenhum dado pessoal. |