Arquitetura de aplicativos - menos sistemas grandes versus sistemas menores


8

re: Arquitetura de Aplicativos , ou seja, " a ciência e a arte de garantir que o conjunto de aplicativos sendo usado por uma organização para criar o aplicativo composto seja escalável, confiável, disponível e gerenciável " .

Ao analisar vários aplicativos em uma organização, vejo vários motivos para mesclar aplicativos, mas às vezes também bons motivos para mantê-los separados.

Em geral , quais são os prós e os contras de ter menos sistemas grandes versus sistemas menores (tendo em mente que muitos dos sistemas trocam informações).

Estou pensando em coisas como: menos aplicativos maiores significa menos encanamento entre aplicativos, mas aplicativos menores significam mais flexibilidade para departamentos individuais.

Existe alguma literatura sobre isso, ou alguém tem uma lista de prós e contras que eles descobriram?

editar: no meu cenário, muitos aplicativos podem ser personalizados prontos para uso em vez de desenvolvidos internamente, mas fique à vontade para considerar cenários mais gerais.


1
Observe que aplicativos maiores não significam nenhum encanamento, apenas significa que o encanamento ocorrerá dentro do aplicativo.
deadalnix

@deadalnix: concordou. Estou assumindo que vincular dados em um aplicativo é menos esforço do que vincular dados entre aplicativos.
codeulike

Respostas:


3

Apenas fora do topo da minha cabeça

Sistemas menores

  • Pro - Amplie o hardware comum ou ambientes virtualizados mais baratos.
  • Pro - Pode implementar o dimensionamento sob demanda em uma nuvem.
  • Pro - Menos dependências intra-sistema, ie. 1 serviço por servidor.
  • Pro - HA / DR (alta disponibilidade / recuperação de desastres) é geralmente mais fácil de implementar
  • Con - Tem que ser escalável horizontalmente
  • Con - Quanto mais sistemas, mais interconecta o gerenciamento mais complicado é

Sistemas Maiores

  • Pro - Menos interconexões, o que geralmente significa que é menos complicado
  • Pro - responde mais rapidamente ao uso de pico alto, se estiver dentro da tolerância.
  • Pro - Menos recursos para gerenciar
  • Pro - uso mais eficiente de recursos (assumindo um uso relativamente constante)
  • Con - Dependências intra-sistema mais complicadas, ie. N serviços por servidor
  • Con - HA / DR é tipicamente mais difícil / mais complicado

Obrigado, isso é ótimo. Como você vê o gerenciamento de mudanças - talvez as mudanças locais sejam mais fáceis em sistemas menores, as mudanças em todo o domínio mais fáceis em sistemas maiores?
codeulike

O gerenciamento de alterações pode ser manual em menos sistemas, mas pode sair rapidamente do controle de muitos sistemas e deve ser automatizado.
dietbuddha

1

Em um sistema maior, é muito mais fácil:

  • Compartilhe recursos e códigos. Você reinventará a roda um pouco menos. Por exemplo, se você tiver dez aplicativos que devem ter acesso ao banco de dados, precisará especificar a cadeia de conexão em todos eles , ou seja, dez vezes. Ou você deve criar uma biblioteca separada e referenciá-la dez vezes novamente.

  • Consolide os fluxos de trabalho , incluindo o processo de implantação.

  • Gerenciar o sistema: menos aplicativos para gerenciar geralmente são mais fáceis .

  • Unifique a experiência do usuário . Quando um funcionário precisa lidar com dez aplicativos diferentes, ele pode se perder facilmente: qual aplicativo executar para executar A? Em qual aplicativo está disponível a opção B? Mas não exagere . Ninguém apreciará o Word, PowerPoint, Outlook, Publisher, Visio, Project e Groove como um único aplicativo monolítico.

Em vários sistemas pequenos, por outro lado, você encontrará que:

  • Você pode abandonar um sistema inteiro se não precisar mais dele. Ou comece do zero se a base de código se tornar inutilizável ao longo do tempo. Obviamente, isso só é verdade se outros sistemas não confiarem nesse sistema ou se a interface for leve o suficiente para ser facilmente reescrita em uma nova versão.

  • Você pode formar uma equipe de desenvolvedores novos e esperar que eles entendam a base de código existente em menos tempo . Se fizer parte de um projeto grande, é provável que exijam mais tempo, a menos que a grande base de código geral seja feita de maneira extremamente profissional e refatorada muito bem (eu nunca vi essas bases de código na minha vida).

  • Os administradores do sistema poderão realocar os aplicativos mais facilmente . O sistema maior, por outro lado, pode ser escalado bem em vários servidores ou não.

  • Os desenvolvedores podem migrar a base de código para novos padrões com mais facilidade . Migrar uma grande base de código é sempre assustador. Em vez disso, quando você precisa lidar com uma pequena base de código, depois outra, depois outra, e assim por diante, isso se torna menos assustador.

Dito isto, essas comparações funcionam apenas em casos gerais, mas sua decisão deve ser tomada não a partir de pools, mas dos ativos da sua empresa. Como é organizado? Existem muitas equipes pequenas de desenvolvedores ou algumas grandes? Existem diretrizes estritas sobre o estilo de codificação e coisas semelhantes?

Também depende da própria aplicação. Por exemplo, seria absurdo enviar todos os aplicativos do Microsoft Office como um único aplicativo. Mas também prejudicaria a produtividade, por exemplo, separar o Adobe Photoshop em um aplicativo para desenho e outro em retoque de fotos. Na IMO, a decisão de unificar ou separar um produto deve ser uma decisão comercial, não puramente técnica.

Por fim, também quero responder ao segundo comentário da pergunta original:

Estou assumindo que vincular dados em um aplicativo é menos esforço do que vincular dados entre aplicativos

Nem sempre é verdade. Se você está lidando, por exemplo, com o .NET, não é incomum enviar um único aplicativo no qual diferentes componentes estão sendo trocados pelo WCF. Nesse caso, isso é comparável a um conjunto de aplicativos separados que se comunicam através do WCF.

Obviamente, quando você precisa lidar com vários aplicativos, precisa estabelecer uma maneira de eles se comunicarem, enquanto ter um único aplicativo monolítico não o força a fazer isso. Mas você realmente seria capaz de escrever um grande aplicativo monolítico?


0

Leia isso. É a filosofia de "muitos pequenos programas" do Unix. O Linux também usa. A imensa resistência dessa filosofia (do final da década de 1960 até hoje) sugere que é a coisa certa a se fazer.

http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond

http://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosophy

http://159.93.17.14/usoft/WWW/LJ/Articles/unixtenets.html

http://www.linuxjournal.com/article/2877


OK, isso funciona para um conjunto de componentes dentro de um sistema operacional, mas funciona para um conjunto de aplicativos de banco de dados dentro de uma organização? Esse é um cenário bem diferente.
codeulike

Não é um cenário diferente. Você pode fornecer algumas diferenças específicas?
S.Lott

@ codeulike: essa foi sua pergunta? "Existe alguma literatura sobre isso"? Se sim, aqui está a literatura. Não recebo seu comentário no contexto de sua pergunta.
S.Lott
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.