Vários sites em um servidor da web vs usuários especificando organização

Question

Eu tenho um site que suporta várias organizações com vários usuários fazendo login. A maneira como a configuração funciona atualmente é que todos vão para o mesmo site e fornecem sua organização, nome de usuário e senha para efetuar login.

Ontem, tive a ideia de que seria mais fácil se fornecêssemos a cada organização seu próprio site no servidor. Assim, por exemplo, em vez de ir para www.example.com e colocar em org1, user1, pwd1, eles poderiam ir até org1.example.com e colocar user1 e pwd1.

Isso parece ter as seguintes vantagens:

• Interface mais fácil para o usuário. Eles podem marcar seu site em particular e só precisam digitar o nome de usuário e a senha
• Manutenção mais fácil. As alterações no web.config para uma organização ou a reinicialização do site podem ser feitas sem afetar os usuários de outras organizações.
• Mais versátil. As configurações podem ser diferentes para diferentes organizações

No entanto, estou imaginando quais desvantagens, se houver, haveriam?

    

Answer 1

Não precisa haver nenhuma desvantagem se os sites estiverem programados corretamente.

Por favor, note que você realmente não precisa mudar nada na configuração atual, exceto fornecer esta página de login. Todos os sub-sites podem, após o usuário & senha são inseridos, convergem para o mesmo corpo de código que hoje, sem necessidade de separação. O sub-site logado pode ser especificado e propagado através de cookies ou um parâmetro adicional em todas as URLs ou algum outro mecanismo para dados globais.

Se você decidir em bases de código separadas, você encontrará a necessidade para propagar melhorias e desenvolvimentos de um para o outro, e isso vai se tornar mais e mais complicado à medida que o tempo passa e o código continua divergindo.

A partir da experiência difícil, posso dizer que a decisão sobre códigos separados pode dar origem a websites que se tornam progressivamente mais complicados de manter à medida que continuam a se multiplicar, de modo que, no final, considerações de manutenção e ressincronização podem causar desenvolvimento a ser adiado ou mesmo bloqueado, até que alguma alma corajosa decida junte tudo e reinicie do zero.