SQL Server Data Services – O fim do DBAssauro que conhecemos?
(Artigo em PDF para download)
Estou aproveitando um problema no joelho e a chegada do fim do nosso ano fiscal para parar um pouco, estudar e repensar algumas coisas... Como recebo diversos e-mails, estava conversando com o Deyvid William e tocamos no assunto do futuro do DBA. Achei interessante ele ter mencionado sobre o SQL Server Data Services (SSDS) e questionado sobre o impacto que isso terá na vida de um DBA (prova de que existem pessoas ligadas no futuro), então resolvi elucubrar um pouco sobre o assunto e escrever algumas palavras.
Antes de continuarmos, para quem não sabe o que é o SQL Server Data Services, acesse:
https://www.microsoft.com/sql/dataservices/default.mspx (aconselho ler o FAQ também)
Uau... Colocar nosso banco de dados lá com a Microsoft e acessá-lo através de serviços. Chique no último! Agora vou pagar a Microsoft por mês, de acordo com os recursos de máquina, disco e rede que minha aplicação utiliza, além de ter um SLA para garantir a disponibilidade dos dados. PS: A maneira como será cobrado e os preços ainda não foram definidos, estou fazendo uma suposição.
Mas espera um minuto, esse anúncio faz a cabeça do pessoal ir a mil (segundo o Deyvid, “vai dar uma sacudida no mercado, não é...”) e começam a surgir as perguntas. Como é que o SSDS funciona? Vou mandar meu esquema para a Microsoft e eles cuidam do meu banco? O que isso impacta na minha vida? Será que alguém vai realmente usar isso? Quem? Quais as vantagens e desvantagens? Desafios?
O que vou escrever agora é puramente minha visão sobre o SSDS, que ainda está amadurecendo, então que tal debatermos sobre o assunto?
Entendendo o SSDS
Em primeiro lugar, existe um erro conceitual quando eu falo “colocar nosso banco de dados lá com a Microsoft”. Fiz questão de colocar dessa forma porque é assim que muitas pessoas recebem a notícia, mas não é assim que o SSDS funciona, então a Microsoft não vai colocar o seu tradicional banco de dados com ela. Isso é diferente de um serviço de hosting fornecido por empresas especializadas.
A idéia é que você trabalhe com entidades, que ficarão organizadas em containeres específicos, agrupados por autoridade (modelo ACE). Então quando você assina o serviço, deve criar uma autoridade (representada por um nome DNS), como luti.data.beta.mssds.com. Com a autoridade criada, você passa a definir containeres, como Livros, Vendas2008 ou Vendas2007. Os containeres por sua vez são repositórios de entidades, que possuem propriedades fixas (metadata – definidas pelo SSDS: ID, versão e tipo) e propriedades flexíveis (flex – definidas pelo usuário: nome, autor, data publicação, ISBN, ImagemCapa, etc.).
Como você cria e manipula tudo isso? Através de requisições WEB utilizando interfaces REST ou SOAP, sempre utilizando verbos específicos para consultar, criar, apagar e atualizar suas entidades. Então se o SSDS recebe uma requisição para a URL https://luti.data.beta.mssds.com/v1/Livros/Livro38947382, será retornado uma entidade de acordo com o id especificado no último elemento da URL, por exemplo.
Internamente, a Microsoft possui um (ou mais) data Center com milhares de máquinas trabalhando em conjunto, para armazenar e atender as requisições. Então você nem fica sabendo como isso funciona, pois a arquitetura é diferente do modelo tradicional de servidor de banco de dados que conhecemos, mas seu dado está lá e você pode acessá-lo.
Com essa breve descrição eu espero que você possa ver claramente como a minha frase introduz um tremendo erro conceitual. Além disso, o SSDS não é para todo tipo de solução que nós conhecemos, existem aplicações específicas que poderão se beneficiar desse modelo, outras não.
Vantagens do SSDS
- Não tenho custo de compra hardware, software e equipe técnica para manter meus bancos de dados, só pago pelo o que eu utilizar. O TCO disso deve ser bom... Qual será o ponto onde essa vantagem ser reverte? Será que reverte?
- Garantia de altíssima disponibilidade do serviço. Serviço fora do ar? A chance de acontecer deve ser bem pequena e a garantia de disponibilidade não é problema seu, o Service Level Agreement (SLA) do seu contrato com a Microsoft vai garantir 99,9% (é um exemplo, não sei a quantidades de casas decimais após a vírgula). Se não atingir esse número, processe! Credo...J
- Nada melhor do que colocar meus dados nas mãos de quem sabe tudo sobre o produto (DBAs Microsoft dentro dos DataCenters). Tenho certeza que a Microsoft vai garantir as melhores práticas em seu ambiente.
* Nota 1: já cansei de ver ambientes mal configurados, impactando a performance por simples problemas de configuração. E depois o problema é do produto.
* Nota 2: a estrutura é baseada em SQL Server, mas a organização/partição/distribuição de dados é diferenciada, então pare de pensar no modelo tradicional!
- Garantia dos dados, com backups sempre disponíveis e confiáveis, além de existir dados replicados (possivelmente, outro palpite) pelos nós dentro do Data Center – não conheço os detalhes internos.
- Maior facilidade para escalar sua aplicação, pois a estrutura já está montada para isso. Se precisar de novos containeres e entidades, vá criando que a malha de computadores vai dar conta do recado.
Desafios do SSDS
- Confidencialidade. Entregar os dados para outra organização sempre foi um problema, como as empresas vão se sentir com o SSDS?
- Alta latência para o acesso aos dados, pois querendo ou não, estamos falando de um servidor na América do Norte. Existem planos de expansão, mas deve incluir Europa e Ásia primeiramente, não sei como ficamos.
- Como arquitetar das aplicações. Esse ponto é complexo, a mudança do paradigma e a maneira como vamos utilizar a nuvem, requer que sejamos conscientes na hora de tomar decisões sobre nossa solução. Não vejo, por exemplo, empresas pegando aplicações atuais e simplesmente atualizando-as para utilizar o SSDS, pois o modelo de conversa “chatty” (muitas idas e vindas) entre a aplicação e o banco de dados (freqüentemente usada), não se adéqua ao SSDS.
- Como vamos interagir com a Microsoft na mudança dos nossos esquemas e serviços disponíveis? A Microsoft vai me ajudar a indexar minhas entidades? Tenho controle sobre isso?
- O time do SSDS está conhecendo o perfil das empresas e como seus serviços serão utilizados, então existem muitas perguntas e algumas “apostas” de respostas. Então arrisco a dizer que o SSDS está sendo moldado de acordo com nossa demanda, e isso é excelente para o consumidor. Faça sua parte e participe do Beta!
Respondendo ao título do blog: não, não é o fim dos DBAs. Da mesma forma que alguns disseram que o T-SQL iria sumir com a nova programação em CLR, os DBAs vão continuar firme e forte, atendendo às diversas soluções OLTP/OLAP tradicionais e que exigem um tempo de resposta muito pequeno, que não se aplicam à latência do SSDS.
Por outro lado, fica cada vez mais evidente o surgimento de um novo perfil de profissional, que sabe utilizar a nuvem e compor os serviços de forma eficiente, entendo qual aplicação se aplica nesse cenário. No que toca o SSDS, o que eu espero desse profissional:
- Saber como modelar os containeres e entidades de forma eficiente, otimizando o espaço necessário para armazenamento (afinal, você está pagando por mês) e o desempenho das consultas (é eficiente criar entidades menores com chaves de entidades? Esse profissional vai saber!).
- Saber como manipular os dados e o cache local para diminuir o tempo de resposta do sistema, além do número de roundtrips entre minha aplicação e o SSDS. Exemplo: vale a pena utilizarmos um mecanismo de prefetching e armazenamento dos dados localmente? Como vou invalidar os dados na cache?
* Padrões de arquitetura vão surgir (será que já não estão aí?), indicando como utilizar combinar essas peças.
- Conhecer como gerenciar eficientemente as versões das entidades e serviços, garantindo compatibilidade de aplicações.
- Entender o que está acontecendo por debaixo dos panos, sabendo dimensionar corretamente os recursos necessários (latência de rede será crucial) para as soluções. O conhecimento de todos esses componentes será essencial no troubleshooting e performance tuning.
Interessante também com vemos as tecnologias sendo criadas com um incrível potencial quando combinadas: LINQ, Entity Framework, ADO.NET Data Services (Astoria), Sync Framework, SQL Server Data Services e Velocity (não acabei de falar sobre cache? Esse acabou de sair do forno - https://blogs.msdn.com/velocity/).
O impacto do SSDS e do mundo S+S é algo que estamos vivenciando (e aprendendo), então pense, por exemplo, no profissional que trabalha no setor de vendas de um parceiro da Microsoft. O que vai acontecer com suas métricas de venda? Ele vai poder vender o SSDS? Isso eu não sei responder, então por enquanto vamos pensar no DBA e nas especialidades que podemos conseguir para estarmos preparados para quando o mercado demandar...
[]s
Luciano Caixeta Moreira
=============================================================
This posting is provided "AS IS" with no warranties, and confers no rights
=============================================================
20080605 - SQL Server Data Services - o fim do DBAssauro que conhecemos.pdf
Comments
Anonymous
June 05, 2008
PingBack from http://www.basketballs-sports.info/basketball-chat/?p=1596Anonymous
June 06, 2008
Luciano, muito bom o artigo, conseguiu fazer um bom resumo do que é o SSDS. Eu acrescentaria apenas uma comparação entre o acesso a dados do SSDS e um Webservice normal. Parabéns e obrigado pela força à comunidade aqui no DF.