Implementação do aplicativo da Web: uma versão para todos os clientes ou para cada um deles

Question

Eu tenho uma pergunta geral sobre a implantação de software. No trabalho, criamos um CRM que é usado pelos navegadores da web. Recentemente me disseram que cada cliente específico tem seu próprio servidor (embora os servidores sejam de propriedade da minha empresa, eles não são deles nem estão localizados em seus escritórios).

Isso me incomoda um pouco. Para meu ponto de vista, quando se está projetando um aplicativo da Web, ele deve ter em mente que será capaz de manter uma execução "soft" para todos os seus clientes (sem falar sobre replicação ou balanceamento de carga), com bancos de dados possivelmente diferentes. cada um, mas um aplicativo ... Ele ajuda especialmente a manter e manter todos atualizados com correções e atualizações. Estou errado ?? Que você me ajude a entender melhor essa questão com recursos (devo estar sem as palavras corretas ou então para encontrá-las eu mesmo). Na verdade, não entendo por que eles passaram pela "terceira via" entre "um aplicativo da web centralizado para todos" e "um aplicativo de desktop distribuído para cada um".

Obrigado!

    

Answer 1

Depende da abordagem. É muito mais fácil manter milhares de servidores que são os mesmos com as tecnologias atuais (ferramentas para automação de trabalho, como docker, puppet, chef, ansible, etc - centenas delas).

Ter um único servidor para cada cliente permite planejar recursos para cada cliente com mais precisão e deixá-los pagar pelo que realmente usam. Também diminui o seu problema, o que também traz algumas vantagens.

Imagine que você teria 1000 clientes em um banco de dados com 2 TB de dados no total. Seus desenvolvedores teriam que escrever consultas SQL perfeitamente para ter esse banco de dados rápido o suficiente. Esse problema é muito menor com um banco de dados pequeno para cada cliente.

Outra questão para pensar pode ser a segurança. Se você tiver que separar seus clientes no nível do aplicativo, seus desenvolvedores devem ter muito cuidado com os dados que selecionam. Se você tiver um banco de dados por cliente, haverá menor chance de vazar outros dados de clientes.

Por outro lado, ter uma única instância para todos os clientes permite que você compartilhe recursos entre seus clientes e economize dinheiro em hardware.

Portanto, essa decisão deve ser tomada no início do projeto, depois de fazer uma lista de vantagens e desvantagens. Eu também sugeriria criar alguns protótipos, então você sabe, por exemplo, processo de implantação, migrações de banco de dados, etc. não será um problema para você.

De minha experiência, eu pessoalmente sugiro ter uma instância para cada cliente se você puder lidar com o gerenciamento de muitas instâncias.

    

Answer 2

Ter servidores separados para cada cliente traz benefícios do isolamento de dados de clientes e permite que você tenha várias versões de aplicativos. Mas existem algumas desvantagens. Você gastará mais dinheiro em servidores (porque você não pode compartilhar recursos entre clientes facilmente) e você terá que gerenciar muito bem. Além disso, se você tiver apenas um banco de dados em todos os clientes, precisará garantir que não haverá alterações significativas na estrutura de dados ou nos requisitos das bibliotecas. Você precisa ter algum cliente de mapa - a versão do aplicativo para gerenciar também.

Eu tenho a mesma versão de software para cada cliente no meu ambiente, o que nos ajuda a manter e dimensionar servidores (posso apenas implantar um novo servidor que é idêntico a outros e apenas adicioná-lo ao loadbalancer). Além disso, não preciso trabalhar com endpoints diferentes para cada cliente.

    

Answer 3

Acho que essa é uma configuração de estágio inicial e aqui estão algumas razões pelas quais acredito que é uma má ideia manter servidores separados sobre a sobrecarga de recursos:

• há um risco significativo de que as extensões estejam sendo desenvolvidas para um e outro cliente, o que causa conflitos mais adiante. Por razões comerciais de curto prazo, isso pode manifestar uma dívida técnica da qual você nunca conseguirá se livrar. Pode ser muito difícil mesclar esses recursos conflitantes no futuro e você pode acabar escolhendo abandonar esses clientes de personalização em uma versão antiga ou ficar preso a eles quando não quiser.

• um cliente multinacional ou de vários estados ou até mesmo uma série de aquisições em um setor pode exigir um sistema em que os dados são separados, mas podem ser relatados em toda a matriz. Isso obrigaria você a ter uma versão multilocatária em qualquer caso, negando os benefícios da separação de bancos de dados.

• todas as empresas bem-sucedidas da Saas utilizam os dados agregados para recursos anônimos combinados, como estatísticas do setor, oportunidades de aprendizado etc. Vi isso ser usado com sucesso pelo Xero e Mailchimp e imagino que esses dados sejam muito valiosos.