Sobre a integração de aplicações através do compartilhamento de banco de dados
Olá pessoal. Tudo certo?!
Considere alguns fatos:
- Processos de negócio precisam funcionar de forma integrada;
- Muitos desses processos demandam os mesmos conjuntos de dados;
- Raramente esses processos são suportados pelos mesmos programas (em um sistema global) – forçar o oposto implica que alguém (algum setor da empresa) não será bem atendido;
- Permitir que cada programa mantenha um banco de dados independente implica na definição de uma estratégia de sincronização – o que pode ser bem complicado.
Considerando tudo isso, por que, simplesmente, não fazer com que todas as aplicações utilizem um único banco. Pois bem, há quem pense e defenda essa estratégia. Eu, particularmente, não consigo ver essa alternativa como algo positivo (no longo prazo).
As vezes, sistemas sincronizados são fundamentais
Muitas corporações anseiam que suas aplicações funcionem com integração rápida e consistente. A resposta aparentemente natural para isso é fazer com que todas as aplicações compartilhem um mesmo banco de dados. Afinal, com mais de um banco, não importa com que frequência sejam realizadas rotinas de sincronização, em algum momento, alguma “desatualização” precisará ser tolerada.
Implementação básica
O modelo mais básico de “integração no banco” é óbvio.
Diferentes aplicações, com acesso direto a uma única base.
Usando banco de consolidação
Outra abordagem comum é adotar um banco centralizado apenas como artefato de consolidação.
Nesses casos, os bancos costumam compartilhar esquemas semelhantes e são “consolidados” em uma base central que é, posteriormente, total ou parcialmente replicada para as bases dos diversos aplicativos.
Esse modelo não evita o problema da sincronização. Entretanto, autoriza algum escalonamento horizontal e funcionamento desconectado.
Desacoplamento do banco
Por fim, há quem defenda que as aplicações devem ser implementadas totalmente desacopladas do banco, sendo ligadas mediante um “driver/adaptador”.
Embora atraente, tal estratégia revela-se difícil de implementar e manter.
A promessa inicial…
Fazer com que todas as aplicações funcionem com um único banco, centralizado, evita problemas de sincronização comuns em outras estratégias. Além disso, antecipa a análise de eventuais formatos diferentes para armazenar um mesmo dado.
Obviamente, tal decisão implica que seja definido um único esquema que atenda as demandas de todas as aplicações.
Sabendo que todas as aplicações persistem em um único banco, podemos ter certeza de que temos consistência. Afinal, até mesmo em casos de atualizações concorrentes podemos contar com a estratégia de orquestração (por exemplo, gerenciamento de transações) implementada no banco.
Por que, na prática, é tão difícil?
O principal problema dessa estratégia está na definição de um esquema que atenda, de forma próxima a ótima, as necessidades de aplicações diferentes. No dia-a-dia, é difícil manter o “esquema único”. Há a pressão constante por “favores” para um dos times.
O problema fica ainda mais evidente quando diferentes fornecedores são contratados para fornecer cada parte do sistema. Nesses casos, é comum que esses fornecedores já tenham sua parte desenvolvida, adaptada e integrada a um determinado esquema pré-definido de banco de dados.
Na prática, integrações usando banco de dados ocorrem, com frequência, em empresas que contratam grandes pacotes comerciais para entregar o “grosso” do sistema e desenvolvem soluções caseiras para especificidades.
Com o tempo, cada atualização do pacote comercial costuma vir com algumas atualizações de esquema que costumam quebrar a compatibilidade gerando muitas dores de cabeça e dificultando a gerência de configuração.
Além de tudo, é difícil de escalar
Bancos de dados centralizados, em grandes cenários corporativos, convertem-se rapidamente em gargalo. São difíceis de escalar horizontalmente e caros para atualizar verticalmente. Além disso, surge a tentação de transferir lógica de aplicação para o banco o que, pessoalmente, sou contra.
No fim, temos o crescimento de “locks” e DBAs loucos.
Concluindo
Para mim, cada aplicação um banco – esse é meu “norte técnico”.
Salvas situações extremas, onde há um “sistema dominante” e queremos construir um “puxadinho” (temporário), o custo de manter um “esquema global” é alto demais.
Era isso.
E você, o que acha?
Acho que você está certo em suas considerações.
Meu velho sistema legado usa somente um banco, e no decorrer dos anos
(esse legado já tem 20 anos), o banco ficou cada vez mais complicado.
Tal como o fonte desse sistema legado, o banco se tornou uma colcha de retalhos.
Hoje, na migração pra C#, estou empacada a uma semana justamente tentando decidir algo que tem tudo a ver com isso.
O primeiro dos módulos que fiz foi um programa de pesagem de veículos que sempre funciona sozinho e tem escopo muito reduzido. Então as escolhas não tinham muito impacto. Serviu como primeiro modulo, didaticamente.
Mas o que experimentei me fez me preocupar com sistema principal, de chão de fabrica de frigoríficos. O legado também tem a parte de escritório, mas o novo não
pretendemos que atenda o escritório (já tem 3 anos que só pegamos chão de fabrica). Mas mesmo assim, tem muitas classes a construir e consequentemente,
muitas tabelas.
Tenho estudado pra usar o EF, com WCF e com liberdade de varias UIs.
Mas o ponto que estou empacado: crio os módulos independentes, ajudando tanto
na manutenção quanto nas vendas (meu sócio pode vender por módulos), com
modelo EF (code first ou model first) independente pra cada modulo, ou
crio uma única solução, usando somente um modelo EF ?
Se criar módulos separados, com bancos separados, cada modulo se comportara,
em relação aos outros, como sistemas de fornecedores diferentes.
Tal como você ilustrou acima.
Dentre as vantagens dessa separação, uma delas seria a independência pra criar um modelo voltado apenas aquele modulo. Ou seja: o modulo da desossa não se preocupa com nada além do que a desossa precisa. Assim como o modulo de abate, e os outros.
Teríamos nesse caso um desacoplamento de modelos EF com desacoplamento de tabelas/bancos ?
Bem, num mundo ideal, com uma boa equipe dando conta do trabalho, não parece ruim essa separação não. Mas na pratica, acho que vou ter que manter um banco único, com um modulo único, mesmo que separe em módulos as outras camadas de arquitetura.
Bem, sou novato em .net e até no uso de bancos relacionais.
Mas é isso que pensei em escrever.
Saudações
Ops, “empacado”, hehe.
Parabéns pelo post, Elemar
Em uma situação recente, optamos por utilizar bancos diferentes por aplicação (uma, legado, webforms) e outra nova (asp.net mvc), mesmo que ambas sejam “módulos” de um produto maior.
Assim poderíamos seguir a vida no desenvolvimento da app nova, sem interferir e sermos interferidos pelo time de manutenção.
No entanto, não estou muito satisfeito com a forma de comunicação entre ambas: WCF, inclusive para sincronizar dados. Cheguei a cogitar o mais simples: consumir uma dll disponibilizada pela outra app.
O que você acha?
(Poderia continuar no tema, escrevendo posts sobre formas de sincronização de dados)
[]s
Robson,
Por favor, conte mais sobre o que não gosta do WCF. É que estou considerando usar WCF também. Tanto entre os módulos independentes (se assim os fizer), quando entre a UI e a BLL.
Grato desde já.
Saudações
Olá, Antônio.
Nada especificamente contra.
Apenas que o time tem pouca experiência com WCF e cheguei a considerar se não seria uma alternativa mais simples uma consumir DLL da outra, a qual continuaria servindo como uma fachada para a outra aplicação/banco. (É claro que teria outras preocupações, como uma política de release dessa(s) DLL(s) para atualização da mesma na outra app). Enfim, estou atualmente em outro projeto e deixei isso em “stand-by”.
Alguém com alguma experiência neste cenário?
Algo que pode te ajudar são conceitos de strategic design, do livro de DDD, onde há vários modelos de se trabalhar, os quais são influenciados diretamente pela distribuição de suas equipes, se a comunicações entre elas é próxima, distante ou impossível. Então você adota uma estratégia, como Cliente-Fornecedor, Shared Kernel (por ex, as equipes de módulos/app diferentes usam uma parte comum do domínio), etc. Claro que o assunto é bem teórico, não entra em detalhes técnicos muito profundos como separação de bancos, tecnologias adequadas, etc.. mas pode dar uma luz em como manter os modelos dos vários módulos.
[]s
Muito obrigado, Robson.
A “integração” via chamada de procedimentos remotos (WCF ou, em uma abordagem simplista) foi tema do post que escrevi ontem.
De forma geral, não sou favorável a esta abordagem, também. Considere soluções baseadas em mensageria.
Muito obrigado pela resposta. Vou ler mencionado post de ontem.
Saudações
Apesar de ainda sim aumentar a complexidade, uma boa ferramenta de sincronização de bancos **pode** manter os esquemas separados e permitir a evolução independente dos dados, mesmo com SGBDs diferentes. Vide http://www.symmetricds.org/
No entanto, eu prefiro mesmo mesmo ter tudo num mesmo banco nestes casos que o Elemar apresentou.
Muito bom o artigo, é um assunto sempre atual, e sempre aparecem abordagens para solucionar esses problemas.
Eu acho que tudo depende dos boundaries que a empresa tem e necessita respeitar. Se são aplicações distintas, devem ter bancos distintos. Agora se vc quer compartilhar algumas informações, eu acho melhor ser um banco somente com as informações compartilhadas e sendo entregue com o WCF, um exemplo seria o cadastro de clientes ou mesmo o mecanismo de segurança que pode e eu acho legal que seja compartilhadas entre todas as aplicações.
Agora sobre sincronia, se isto não for pensado desde o início, monitorado e muito controlado, tende a gerar inconsistência a longo prazo, e o que adianta vc ter 2, 3 bases de dados, sendo que vc não confia em nenhuma base para gerar um relatório, ou até mesmo uma mala direta.
Não tem receita de bolo, o legal e ver quais são os benefícios dessas abordagens e escolher a melhor te atende..
[]s
Eu não sou muito fã de colocar um monte de aplicativos em um banco de dados só. Uma porque pode acontecer o caso de sair do ar esse único banco, e derrubar todos os sistemas na empresa inteira. Outra porque a bagunça que vira depois de um tempo apavora qualquer um.
Concordo com esse princípio de “Cada aplicação um banco”, divide as responsabilidades e fica fácil manter.
Para integrar, dependendo da demanda, usa um middleware; ou integra os aplicativos com web-services por exemplo.
A diferença que se vc usa um middleware para integrações, vai facilitar quando você quer conectar aplicativos de parceiros comerciais, ficando uma arquitetura escalável.
Pingback: Sobre a integração de aplicações através da execução de “chamadas remotas” « Elemar DEV